Skip to content

WLAN-Sicherheit 7 - Angriffe auf die WPA-Verschlüsselung, Teil 2

Der ursprüngliche Standard-Verschlüsselungsalgorithmus für drahtlose Netze nach dem Standard IEEE 802.11 (WLAN), Wired Equivalent Privacy (WEP) enthält einige Schwachstellen und kann kinderleicht geknackt werden. Aber auch das als vorübergehender Ersatz entwickelte Wi-Fi Protected Access (WPA) ist nicht absolut sicher. Zum einen besteht die Gefahr von DoS-Angriffen (auch wenn sich anscheinend niemand die Mühe gemacht hat, die wirklich zu starten), zum anderen ist auch das Brechen der Verschlüsselung möglich.

Dass sich unsichere Schlüssel für das Pre-Shared-Key-Verfahren über Brute-Force- und Wörterbuchangriffe ermitteln lassen ist weiter kein Problem. Bzw. keins, dass man WPA anlasten kann. Wer ein zu einfaches Passwort verwendet, hat verloren. Und ist selbst Schuld. Dagegen kann man auch ganz einfach etwas machen: Man verwendet einfach ein sicheres Passwort. Also keins, dass in einem Wörterbuch steht. Und auch keins, dass sich leicht erraten lässt.

Brechen der Verschlüsselung unabhängig vom Schlüssel

Schlechter sieht es da schon beim 2008 von Martin Beck und Erik Tews entwickelten Angriff aus. Der richtet sich nicht gegen schwache Schlüssel, sondern die Verschlüsselung an sich. Und hebelt die vorhandenen Schutzfunktionen aus. Der Angriff bricht die WPA-Verschlüsselung zwar nicht komplett, da nur die vom AP an den Client geschickten Daten entschlüsselt werden können, und auch das nur unter bestimmten Bedingungen, aber er ist ein Warnsignal. Und das wurde 2009 noch einmal verdeutlicht, denn da wurde der Angriff verbessert.

Entwickelt wurde der verbesserte Angriff von Toshihiro Ohigashi und Masakatu Morii (Whitepaper als PDF). Die beiden haben den Angriff von Martin Beck und Erik Tews um einen MitM-Angriff erweitert. Der Client erhält dadurch gar keine direkte Verbindung mehr zum AP. Stattdessen agiert der Rechner des Angreifers als Repeater und leitet die Pakete je nach Bedarf unverändert weiter oder präpariert sie für den Angriff auf den AP. Da dadurch der Replay-Teil des Angriffs von Martin Beck und Erik Tews weg fällt kommt der Schutz davor durch den TSC nicht zum Zuge: Die an den AP gesendeten präparierten Pakete enthalten den originalen Counter-Wert.

Die 60-Sekunden-Limitierung von 'Michael' umgehen Toshihiro Ohigashi und Masakatu Morii, indem sie durch Änderungen an der Prüfsummen-Berechnung das Entstehen von MIC-Fehlern verhindern. Ohne Fehler gibt es auch keinen Timeout, wodurch der Angriff deutlich beschleunigt wird. Dauerte er bei Martin Beck und Erik Tews noch 12-15 Minuten, gelangten Toshihiro Ohigashi und Masakatu Morii im günstigsten Fall innerhalb einer Minute ans Ziel, im ungünstigsten Fall benötigen sie 4 Minuten.

Aber auch dieser Angriff hat einen Nachteil: Da die Pakete des Clients an den AP für den Angriff manipuliert und die Original-Pakete verworfen werden kann der Benutzer (und auch eine entsprechend angepasste Sicherheitssoftware) den Angriff an der "gestörten" Verbindung erkennen und den Angriff abwehren.

Aber eigentlich ist das inzwischen auch egal, denn WPA hat inzwischen ein viel größeres Problem:

RC4 wurde gebrochen

WPA verwendet für die Verschlüsselung RC4. Das war eigentlich schon bei der Entwicklung von WPA keine wirklich gute Wahl mehr, es gab sicherere Alternativen. Da damals aber die vorhandenen WEP-fähigen Geräte leicht an WPA anzupassen sein sollten konnte man keinen anderen Algorithmus als das schon von WEP verwendete RC4 verwenden. Und das hat ja dann doch noch einige Zeit gute Dienste geleistet.

Inzwischen ist es damit aber vorbei. 2013 wurde von Nadhem AlFardan, Dan Bernstein, Kenny Paterson, Bertram Poettering und Jacob Schuldt gezeigt, dass sich Teile des RC4-Schlüsseltexts sowohl einer TLS-Verbindung als auch einer WPA-Verbindung entschlüsseln lassen. Schon zuvor waren Schwachstellen in der RC4-Verschlüsselung bekannt geworden, aber mit diesem Angriff wurde die Sache gefährlich. So gefährlich, dass Microsoft im November 2013 empfohlen hat, möglichst bald auf den Einsatz von RC4 für SSL/TLS (und auch alle anderen Einsatzzwecke) zu verzichten. Parallel wurde bekannt, dass die NSA SSL/TLS-Verbindungen mit RC4 mit ziemlicher Sicherheit in Echtzeit entschlüsseln kann. Und was die NSA kann, können vermutlich auch noch andere Geheimdienste.

Im Juli 2015 wurde dann von Mathy Vanhoef und Frank Piessens ein praktischer Angriff auf RC4 in SSL/TLS und WPA-TKIP vorgestellt: RC4 NOMORE (Numerous Occurrence MOnitoring & Recovery Exploit). Sie konnten den Cookie einer HTTPS-Verbindung eines realen Geräts in 52 Stunden ermitteln. Für den Angriff auf WPA-TKIP reicht sogar eine Stunde, danach kennt der Angreifer den MIC-Schlüssel und kann beliebige an den Client gesendete Pakete entschlüsseln und einschleusen.

Damit ist RC4 endgültig in der Praxis gebrochen (in der Theorie war es das schon länger), und damit auch WPA. Aber das ist kein größeres Problem. Zur Erinnerung: WPA war ja nur für eine Übergangszeit gedacht, als WEP unsicher, WPA2 aber noch nicht fertig war. Inzwischen ist WPA2 schon seit einiger Zeit fertig und auch im Einsatz. Es gibt also keinen Grund, noch das inzwischen unsichere WPA zu verwenden. Außer, dass ein Gerät nichts anderes unterstützt. Aber dann gehört es ins Museum oder in den Elektroschrott, aber nicht in ein aktiv genutztes Netzwerk.

Wie WPA2 funktioniert wird ab der nächsten Folge beschrieben.

Carsten Eilers

Trackbacks

Dipl.-Inform. Carsten Eilers am : WLAN-Sicherheit 8 - Der aktuelle Standard-Verschlüsselungsalgorithmus: WPA2

Vorschau anzeigen
Wi-Fi Protected Access 2 (WPA2) implementiert die grundlegenden Funktionen des aktuellen Sicherheitsstandards IEEE 802.11i für drahtlose Netze nach dem IEEE 802.11 Standard (WLAN). Im Gegensatz zum ursprünglichen Verschlüs

Dipl.-Inform. Carsten Eilers am : WLAN-Sicherheit 14 - Angriffe aufs WLAN, Teil 1

Vorschau anzeigen
Wi-Fi Protected Access 2 (WPA2) ist ziemlich sicher. Wie sicher, erfahren Sie ab dieser Folge. Aber erst mal wollen wir uns ansehen, wie ein Angriff auf ein WLAN generell abläuft. Denn das Aufbrechen der Verschlüsselung, wie ich es f&uum

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Noch keine Kommentare

Kommentar schreiben

Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
BBCode-Formatierung erlaubt
Formular-Optionen

Kommentare werden erst nach redaktioneller Prüfung freigeschaltet!