Der Sicherheitsforscher Mathy Vanhoef hat mehrere Schwachstellen im 4-Way-Handshake des WPA-/WPA2-Protokolls festgestellt. Diese Schwachstellen können im schlimmsten Fall dazu führen, dass Verbindungen gehackt werden und Schadcode injiziert wird. Was Abhilfe schafft, ist das schnellstmögliche Patchen der WLAN-Infrastruktur und, viel wichtiger noch, der WLAN-Clients. Und genau hier zeigt sich wieder einmal das Dilemma, in das die hochvernetzte IT führt.
In den meisten Unternehmen ist eine ganze Flut unterschiedlicher WLAN-Geräte im Einsatz. Insbesondere in der Produktion und Logistik geht ohne Handscanner gar nichts. Aber auch das mobile Telefonieren, die Kassensysteme, die über WLAN kommunizieren, oder die diversen Smartphones, Tablets und Laptops sind längst fundamentaler Bestandteil der Unternehmensprozesse. Für viele dieser Geräte wird es nie mehr Updates geben und Abschalten ist auch keine Option.
Wir müssen uns darauf einstellen, dass zukünftig in immer kürzeren Abständen relevante Schwachstellen veröffentlicht werden, die auf Grund der hohen Integration und Diversität der betroffenen Produkte nicht zeitnah und umfänglich geschlossen werden können. Also brauchen wir dringend neue Konzepte und Techniken, um mit dieser Bedrohungslage umzugehen.
Doch nun zu den relevanten Fragestellungen, die sich konkret aus der WPA-/WPA2 Sicherheitslücke ergeben.
Welche Produkte/Geräte sind betroffen?
Da die Sicherheitslücken die Funktionsweise des 4-Way-Handshakes des WPA-/WPA2-Protokolls ausnutzen sind alle WLAN-fähigen Geräte, unabhängig vom Hersteller, grundsätzlich betroffen. Einzige Voraussetzung ist, dass WPA-/WPA2 als Sicherheitsstandard für ein Funknetz verwendet wird.
Wie können die Sicherheitslücken ausgenutzt werden?
Um einen Angriff durchführen zu können, müssen die folgenden Voraussetzungen erfüllt sein:
- Man-In-The-Middle-Device muss zwischen Client und Access-Point positioniert werden
- Man-In-The-Middle-Device muss die selbe MAC-Adresse haben wie der anzugreifende Access-Point
- Man-In-The-Middle-Device muss die selbe SSID ausstrahlen wie der anzugreifende Access-Point
- Man-In-The-Middle-Device muss auf einem anderen Kanal funken als der anzugreifende Access-Point
Schafft es ein Angreifer alle Voraussetzungen unbemerkt – heutige WLAN-Infrastrukturen erkennen derartige Angriffe als „Rogue-APs“ und/oder „SSID-Spoofing“ – zu erfüllen, kann er die Zustellung des vierten Pakets des 4-Way-Handshakes zum Access-Point verhindern und löst somit die erneute Übertragung des dritten Pakets durch den Access-Point aus. Dies bringt den Client dazu, den bereits zuvor genutzten PTK (Pairwise Transient Key) erneut zu installieren. Weiterhin wird hierdurch die „Nonce“ (der Zufallswert für die Verschlüsselung) zurückgesetzt, was letztlich die Entschlüsselung der gesendeten Pakete ermöglicht.
Warum muss meine Infrastruktur gepatcht werden, obwohl die Sicherheitslücken v.a. Clients betreffen?
Ein Update der Infrastruktur ist aufgrund zweier Hintergründe notwendig:
- Mesh-APs: Mesh-APs stellen technisch nichts anderes dar als Clients
- FT: Im Fast BSS Transition Prozess wird ebenfalls der angreifbare 4-Way-Handshake verwendet
Sollte WPA2 daher nicht mehr genutzt werden?
Definitiv nein, da die Sicherheitslücken nicht direkt das Protokoll betreffen, sondern eher auf die nicht definierte Implementierung zurückzuführen sind. Das heißt konkret, dass die Sicherheitslücken durch Software-Updates behebbar sind.
Sollte ich nun die Zugangsdaten zum WLAN ändern?
Der Angreifer hat durch diese Sicherheitslücke zu keinem Zeitpunkt die Möglichkeit, die WLAN-Zugangsdaten, weder den Preshared-Key noch AD-Passwörter, abzugreifen. Eine Änderung der WLAN-Zugangsdaten aufgrund der Sicherheitslücken ist also nicht notwendig.
Was kann ich tun, um die Sicherheitslücken zu schließen?
Es gilt schnellstmöglich die WLAN-Infrastruktur, viel wichtiger jedoch die WLAN-Clients mit Patches der jeweiligen Hersteller zu versorgen.
Microsoft hat die Sicherheitslücken (für Windows 7, Windows 8 und Windows 10) beispielsweise bereits am Patchday (10.10.2017), unter Wahrung der Veröffentlichungsfrist (16.10.2017), stillschweigend geschlossen. Auch Apple hat schon nachgezogen.
Prinzipiell kann aber davon ausgegangen werden, dass ältere Geräte wohl eher schlechtere Karten haben.
Reicht es, wenn ich eine Seite (Infrastruktur oder Clients) patche?
Nein. Um die Sicherheitslücken vollumfänglich zu schließen, sind sowohl die Clients als auch die Infrastruktur zu patchen.
Was kann ich tun, wenn noch keine Patches vorhanden sind?
Bis Patches verfügbar sind, sollte Fast BSS Transition zwingend deaktiviert werden. Weiterhin sollte auf Mesh-Verbindungen verzichtet werden – soweit dies möglich ist.
Die professionellen Hersteller von WLAN-Infrastrukturen stehen zwar vor dem gleichen Problem wie alle anderen, verfügen aber im Normalfall über Erkennungsmechanismen von Man-In-The-Middle-Attacken. Diese werden bspw. als „Rogue APs“ oder „SSID-Spoofing“ gemeldet. Um zumindest auf Vorfälle reagieren zu können, sollten diese Alarmmeldungen zwingend aktiviert und v.a. auch mit Nachdruck bearbeitet werden.
Welche Schwachstellen gibt es genau?
Genauere Informationen zu den Schwachstellen können dem Bericht „Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2“ von Mathy Vanhoef entnommen werden:
Außerdem hat die CERT eine Übersicht der Sicherheitslücken erstellt und diesen CVE-IDs (Common Vulnerabilities and Exposures) zugeordnet:
CVE ID | CVE Description |
---|---|
CVE-2017-13077 | Reinstallation of the pairwise key in the Four-way handshake |
CVE-2017-13078 | Reinstallation of the group key in the Four-way handshake |
CVE-2017-13079 | Reinstallation of the integrity group key in the Four-way handshake |
CVE-2017-13080 | Reinstallation of the group key in the Group Key handshake |
CVE-2017-13081 | Reinstallation of the integrity group key in the Group Key handshake |
CVE-2017-13082 | Accepting a retransmitted Fast BSS Transition Reassociation Request and reinstalling the pairwise key while processing it |
CVE-2017-13084 | Reinstallation of the STK key in the PeerKey handshake |
CVE-2017-13086 | Reinstallation of the Tunneled Direct-Link Setup (TDLS) PeerKey (TPK) key in the TDLS handshake |
CVE-2017-13087 | Reinstallation of the group key (GTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame |
CVE-2017-13088 | Reinstallation of the integrity group key (IGTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame |