Dipl.-Inform. Carsten Eilers

Namen für Schwachstellen sind nicht gerade üblich, wenn man mal von den einheitlichen Bezeichnern der CVE-Liste (Common Vulnerabilities and Exposures) absieht. Und dann gleich "Hole196" - das klingt ja, als gäbe es in WPA2 mindestens noch 195 andere Löcher, dabei gilt das Protokoll doch eigentlich als sicher. Oder war es der 196. Versuch, eine Lücke zu finden, der endlich erfolgreich war? Die Erklärung für den Namen ist deutlich harmloser als er klingt, wie die FAQ verrät:

"AirTight Networks uncovered a weakness in the WPA2 protocol, which was documented but buried on the last line on page 196 of the 1232-page IEEE 802.11 Standard (Revision, 2007). Thus, the moniker "Hole196"."

Das ist das schöne an langen Spezifikationen: Sie sind immer für eine Überraschung gut. Gerade, wenn man denkt, man hat alle Sonderfälle und Ausnahmen berücksichtigt, taucht völlig unerwartet ein neues Problem auf.

Kern des Problems: Der Group Temporal Key GTK

Werfen wir einen Blick in den Standard IEEE 802.11 (2007):

"8.5 Keys and key distribution
8.5.1 Key hierarchy
RSNA defines two key hierarchies:
a)     Pairwise key hierarchy, to protect unicast traffic
b)     GTK, a hierarchy consisting of a single key to protect multicast and broadcast traffic NOTE—Pairwise key support with TKIP or CCMP allows a receiving STA to detect MAC address spoofing and data forgery. The RSNA architecture binds the transmit and receive addresses to the pairwise key. If an attacker creates an MPDU with the spoofed TA, then the decapsulation procedure at the receiver will generate an error. GTKs do not have this property."

Die rot hervorgehobenen Sätze, bzw. im Grunde nur der zweite, sind die Ursache des Problems: Beim für Unicast-Verbindungen, d.h. Verbindungen zwischen dem Access Point und einem speziellen Client, verwendeten Pairwise Transient Key (PTK) werden Fälschungen der MAC-Adresse und Manipulationen an den übertragenen Daten erkannt, beim für Broadcasts, d.h. vom Access Point an alle Clients versendete Nachrichten, verwendeten Group Temporal Key (GTK) fehlen diese Schutzfunktionen. Anscheinend hat beim Entwurf des Standards niemand damit gerechnet, das irgend jemand ein Interesse daran haben könnte, Broadcasting-Pakete zu fälschen.

Was bedeutet das genau?

WPA2 verwendet 2 Schlüssel: Den für jeden Client individuellen Pairwise Transient Key (PTK) für die Verschlüsselung der zwischen dem Access Point und dem jeweiligen Client ausgetauschten Daten, und den für alle Clients gleichen Group Temporal Key (GTK), mit dem die an alle Clients parallel verschickten Daten verschlüsselt werden. Da es sich um symmetrische Schlüssel handelt, kann jeder, der den Schlüssel kennt, Daten sowohl ver- als auch entschlüsseln. Eigentlich sollte nur der Access Point mit dem GTK verschlüsselte Daten senden, die dann von allen Clients entschlüsselt werden können. Wie man unten auf Seite 196 der Spezifikation aber lesen kann, gibt es keine Möglichkeit, gefälschte Adressen oder manipulierte Daten zu erkennen. Daher kann jeder Client den ihm zwangsweise bekannten GTK missbrauchen, um selbst gefälschte Broadcast-Nachrichten zu senden.

Was kann ein Angreifer erreichen?

Erst mal können Angriffe nur von authentifizierte Benutzern durchgeführt werden, da nur die den GTK kennen. Diesen stehen dann im wesentlichen drei Möglichkeiten offen:

1. Sie können ARP-Poisoning- und Man-in-the-Middle-Angriffe starten (Das Adress Resolution Protocol ARP dient der Zuordnung von IP-Adressen zur entsprechenden Adresse im physikalischen Netzwerk, im Fall von Ethernet der MAC-Adresse (Media Access Control) der Ethernetkarte des entsprechenden Rechners),
2. Schadcode in vorhandene WiFi-Geräte einschleusen oder
3. DoS-Angriffe ohne den Einsatz von Disconnection-Frames durchführen.

Der Angreifer fälscht dazu Broadcast-Pakete und sendet sie direkt an sein beabsichtigtes Opfer. Ein ARP-Poisoning-Angriff läuft z.B. folgendermaßen ab (siehe auch Abb. 1):

1. Der Angreifer sendet dem Opfer einen ARP-Request mit der IP-Adresse des aktuellen Gateways und der MAC-Adresse des Angreifers, verschlüsselt mit dem GTK:
   GTK(IP_Gateway,MAC_Angreifer) -> Opfer
2. Das Opfer fügt diese Daten in seine ARP-Tabelle ein und verknüpft dabei die MAC-Adresse des Angreifers mit der IP-Adresse des Gateways:
   IP-Adresse_Gateway = MAC-Adresse_Angreifer
3. Will das Opfer Daten über das Gateway senden, verschlüsselt es sie mit seinem individuellen PTK, versieht sie mit der MAC-Adresse des Angreifers (die es ja für die Adresse des Gateways hält) als Empfänger und schickt sie an den Access Point:
   PTK_Opfer(an MAC_Angreifer; Daten für das Gateway) -> Access Point
4. Der Access Point entschlüsselt die Daten, verschlüsselt sie mit dem PTK des Angreifers und sendet sie an dessen MAC-Adresse:
   PTK_Angreifer(Daten für das Gateway) -> Angreifer
5. Der Angreifer kann diese Daten dann entschlüsseln, Inhalte ausspähen oder Manipulieren und die Daten je nach Wunsch an das eigentliche Gateway weiterleiten oder löschen.

Abb. 1: Ein ARP-Poisoning-Angriff

Der Vorteil dieses ARP-Poisoning-Angriffs gegenüber der herkömmlichen, drahtgebundenen Variante: Während ein herkömmlicher ARP-Poisoning-Angriff im drahtgebundenen Netz unverschlüsselte und daher von Intrusion-Detection- oder -Prevention-Systemen erkennbare Spuren hinterlässt, werden die Daten bei der drahtlosen Variante verschlüsselt übertragen und sind für ein drahtgebundenes IDS/IPS nicht erkennbar. Lediglich ein Wireless Intrusion Prevention System (WIPS) ist in der Lage, die Angriffe zu erkennen.

Was kann ein Angreifer nicht erreichen?

Ein Angreifer kann weder von außen in das WPA2-geschützte Netzwerk eindringen noch die PTK der Teilnehmer ausspähen.

Wie kann man "Hole196"-Angriffe verhindern?

Zur Zeit im Prinzip gar nicht, sofern man sich an den Standard halten will. Es gibt keine im Standard spezifizierte Funktion, die als "Fallback-Lösung" oder Workaround eingesetzt werden kann. Und da sich die Schwachstelle im Standard und nicht in einer spezifischen Implementierung befindet, ist jede Standardkonforme Architektur davon betroffen.

Die Access-Point-Hersteller können die Schwachstelle umgehen, indem sie auf die Verwendung von Broadcast-Nachrichten und des GTK verzichten und alle Daten mit den individuellen PTKs der Clients verschlüsseln. Das widerspricht aber dem Standard, der beim Verbindungsaufbau über den 4-Wege-Handshake die Verteilung eines GTK verlangt. Alternativ könnte für jeden Client auch ein individueller GTK erzeugt werden.

Architekturen, die die nicht standardisierte Client Isolation oder Public Secure Packet Forwarding (PSPF) implementieren, können verhindern, dass zwei Clients direkt miteinander kommunizieren. Der Angreifer kann zwar weiter gefälschte Broadcast-Pakete an alle Clients schicken, deren Antworten erreichen ihn aber nicht. Ein Angreifer kann diese Isolierung aber durchbrechen, indem er ein Fake-Gateway installiert, über das die Antworten dann umgeleitet werden. Außerdem sind natürlich alle Angriffe möglich, bei denen keine Antwort erwartet wird oder notwendig ist.

Software zur Erkennung von ARP-Poisoning kann damit geschützte Clients vor den Folgen eines ARP-Poisoning-Angriffs bewahren, alle anderen Angriffe über gefälschte Broadcast-Pakete sind aber weiter möglich. Am einfachsten kann der Access Point einen Angriff erkennen: Wenn er Pakete von sich selbst empfängt, läuft ein Angriff. Da dieser Fall bisher aber nicht vorgekommen ist, sind die Access Points schlicht nicht darauf eingerichtet, solche Pakete zu erkennen.

Langfristig und endgültig kann die Schwachstelle nur dort behoben werden, wo sie sich befindet: Im Standard.

Ich fürchte, von "Hole196"-Angriffen werden wir in Zukunft öfter hören. In der nächsten Folge geht es um einen weiteren neuen Angriff, der eigentlich eine Kombination mehrerer alter ist: Craig Heffner hat auf der Konferenz "Black Hat USA 2010" gezeigt, wie ein entfernter Angreifer über DNS-Rebinding auf das interne, Web-basierte Administrations-Interface von Customer-Routern zugreifen kann.

Carsten Eilers

Weiterführende Links:

• About Security #108: Mobile Security - Wi-Fi Protected Access (WPA)
• About Security #109: Mobile Security - IEEE 802.11i Schlüsselhierarchien
• About Security #110: Mobile Security - IEEE 802.11i Pairwise Master Key
• About Security #111: Mobile Security - IEEE 802.11i Gruppenschlüssel
• About Security #112: Mobile Security - IEEE 802.11i Verschlüsselung
• About Security #113: Mobile Security - IEEE 802.11i Authentifizierung
• About Security #114: Mobile Security - IEEE 802.11i Pairwise Master Key
• About Security #115: Mobile Security - Sicherheit von WEP, WPA und IEEE 802.11i
• About Security #116: Mobile Security - Sicherheit von WEP, WPA und IEEE 802.11i, Teil 2
• About Security #117: Mobile Security - WLAN-Hotspots

Übersicht über alle Artikel zum Thema

WEP, WPA, WPA2 - WLAN-Schutz, aber richtig!

"Hole196" - Eine neue Schwachstelle in WPA2

DNS-Rebinding - Ein altbekannter Angriff kompromittiert Router

Von außen durch den Client in den Router

Ciscos "WPA Migration Mode" öffnet den Weg ins WLAN

NAT-Pinning, Angriffe auf Cisco-WLANs und ein Tool

Angriffe auf den WLAN-Client

BEAST - Ein neuer Angriff auf SSL und TLS 1.0

Konfigurationsänderungen am Router per UPnP - aus dem Internet

WLAN-Sicherheit - Stand der Dinge

WPS-Schwachstelle gefährdet WLANs