KRACK Angriff auf WPA2

Was ist KRACK?

Das Synonym KRACK steht für "key reinstallation attacks" (KRACKs). Dabei handelt es sich um eine Reihe an Angriffen, die sich Design- und Implementierungsfehler in den kryptografischen Protokollen für Neuinstallation von bereits verwendeten Schlüsseln zu Nutzen machen. Zum Zeitpunkt der Veröffentlichung des Papers nutzten alle Wi-Fi-Netzwerke zur Absicherung eine Umsetzung des 4-Wege-Handshakes, der wiederum bereits 14 Jahre alt war aber bis dahin noch als sicher galt.

Der KRACK Angriffmacht sich damit zu Nutzen, dass der Client noch immer Neuversand der Nachricht 3 durch den AP akzeptiert, trotz der Tatsache, dass er sich im PTK-DONE Zustand befindet. So wird die erneute Installation des Schlüssels erzwungen. Dafür agiert der Angreifer aus der Man-in-the-Middle Position zwischen dem Client und dem AP. Wenn die vierte Nachricht den AP nicht erreicht, wird die Nachricht 3 erneut geschickt. Das führt dazu, dass die Nonce des Datenvertraulichkeitsprotokols zurückgesetzt wird. Das hat zufolge, dass der gleiche Schlüssel einen Counter zweimal verwendet.

Das Problem im Detail

Das Problem bei dem Verfahren ist, dass man beim AES Counter Mode durch das Zurücksetzen der Nonce mit dem gleichen Schlüssel erneut andere Daten verschlüsseln. Der so entstandene Keytream ist damit identisch und wird dadurch mehrfach verwendet. Der Client verschlüsselt demzufolge zwei Nachrichten dem gleichen Keystream. Außerdem liegen dem Angreifer zwei im Grunde identische Nachrichten (siehe Handshake) vor:

• die erste ist unverschlüsselt: $Msg4(r+1)$
• und die zweite ist verschlüsselt: $Enc^1_{ptk}{Msg4(r+2)}$

Diese beiden kann der Angreifer per XOR verknüpfen und bekommt den Keystream.

Außerdem ist der Angreifer im Besitz einer weiteren verschlüsselten Nachricht mit Daten $Enc^1_{ptk}{ Data(...)}$, die er mittels XOR mit dem Keystream verarbeitet und so den Plaintext erhält.

Dieses Verhalten soll die Abbildung 1 verdeutlichen. In die Verschlüsselung fließt die Nonce als auch der Counter ein. Der Counter wird wie bereits erwähnt, immer weiter inkrementiert. Die Nonce ist zu Beginn einmal zufällig ausgewählt worden.

Abbildung 1: AES Counter Mode Blockdiagramm (Quelle: Wikipedia)

Dies stellt den generellen Aufbau der Angriffe dar.

Einschränkungen:

Es gibt durch unterschiedliche Implementierungen auch Einschränkungen und Besonderheiten.

• Windows und iOS akzeptierten keinen Neuversand der Nachricht 3, wodurch die Implementierung nicht verwundbar ist für diesen Angriff. Beide sind jedoch wegen der Implementierung im Group Key Handshake verwundbar.
• Erreichung einer Man-in-Middle-Position muss gegeben sein. Ein Rogue AP ist ein vom Angreifer aufgesetzter AP. Dieser kann mit anderer MAC-Adresse nicht verwendet werden, weil die Keys vom echten AP abweichen. In diesem Fall nutzt man stattdessen einen Klon des AP mit gleicher MAC-Adresse auf anderem Kanal.
• Manche Implementierungen setzen nach Installation des PTK auf verschlüsselte Frames. Dann wird die unverschlüsselte, neugesendete Nachricht 3 vom Client nicht mehr akzeptiert. Die Forscher konnten es dennoch umgehen, da auch hier ein Angriff möglich war.

Angriff auf den Group Key Handshake

Der GTK wird periodisch ausgewechselt und das passiert unter anderem, wenn ein Client das Netzwerk verlässt. Der neue GTK wird dann per Group Key Handshake ausgetauscht. Der Handshake wird von dem Access Point initiiert und erneut versendet, wenn eine entsprechende Antwort nicht erhalten wird. In dem Prozess wird der EAPOL Replay Counter wie gehabt auch beim erneuten Senden inkrementiert.

Idee des Angriff

Das Ziel des Angriffs besteht darin,

• die erneut verschickte Group Nachricht 1 abzufangen,
• die Zustellung dieser an den Client zu verhindern
• und stattdessen, diese zu einem späteren Zeitpunkt an den Client zu versenden.

Dies führt dazu, dass der Replay Counter des GTK zurückgesetzt wird, wie es auch beim 4-Wege-Handshake der Fall ist. Den Forschern ist es gelungen nachzuweisen, dass zum Zeitpunkt der Veröffentlichung, alle Wi-Fi-Clients den Replay Counter bei Neuinstallation eines bereits verwendeten GTK zurücksetzten.

Angriffsdurchführung

Eine Voraussetzung für diesen Angriff ist außerdem, dass der GTK vom Access Point so früh wie möglich installiert wird. Der IEEE 802.11 Standard von 2016 sieht es vor, dass der GTK erst installiert wird, wenn alle Clients auf mit Group Nachricht 2 geantwortet haben.

Wenn der AP den GTK vorzeitig installiert, dann gestaltet sich der Angriff einfacher, als wenn er nach Protokoll bis zur letzten Antwort wartet.

Im ersten Fall, bei dem der GTK direkt nach Versand der Group Nachricht 1 geschieht, verläuft der Angriff folgendermaßen:

1. Der Angreifer greift nicht beim 4-Wege-Handshake ein, sondern nachdem der Refresh GTK Vorgang iniziiert wird.

2. Dabei gibt der Angreifer die Group Nachricht 1 $Enc^{x}_{ptk}{Group1(r;GTK)}$ direkt weiter an das Opfer (den Client).

3. Dieser installiert den GTK und antwortet mit einem verschlüsselten Group Nachricht 2 $Enc^{y}_{ptk}{Group2(r)} $, die der Angreifer abfängt, aber nicht an den AP weiterleitet.

4. Der Access Point erhält diese Nachricht nicht und schickt daraufhin die Group Nachricht 1 $Enc^{x+1}_{ptk}{Group1(r+1;GTK)}$ erneut mit inkrementiertem Replay Counter und verschlüsselt mit dem PTK.

5. Der Angreifer gibt diese noch nicht weiter und wartet darauf, dass der AP einen Broadcastdataframe $Enc^1_{gtk}{GroupData(... )}$, den er dann direkt weitergibt an den Client. Hier ist zu beachten, dass dieser Frame erst geschickt wird, da dieser den Replay Counter

6. Danach schickt er die zurückgehaltene Group Nachricht 1 $Enc^{x+1}_{ptk}{Group1(r+1;GTK)}$ an den Client.

7. Der Client installiert den GTK erneut und setzt den Replay Counter zurück.

8. Dann schickt der Angreifer $Enc^1_{gtk}{GroupData(... )}$ erneut und der Client akzeptiert diese Nachricht, weil der Replay Counter zurück gesetzt worden ist und dadurch übereinstimmt mit dem erwarteten Wert.

Abbildung 2: Ablauf des Angriffs auf Group Key Handshake

Der Impact dieses Angriffs ist jedoch niedrig, weil der Client seine Broadcast Pakete in der Regel an den AP als Unicast Pakete schickt und der AP verteilt diese dann weiter per Broadcast.

Angriff auf Fast BSS Transition (FT) Handshake

Die Forscher haben außerdem gezeigt, dass der Fast Fast Basic Service Set (BSS) Transition (FT) Handshake von diesen Angriffen ebenfalls betroffen ist. Der FT Handshake ist im IEEE 802.11r ratifiziert und soll schnelles Roaming zwischen Access Points des gleichen, geschützten Netzes ermöglichen. Bei der vorgestellten Attacke muss der Angreifer sich nicht in eine Man-in-the-Middle Position begeben und kann das Zurücksetzen der Nonce beim AP dennoch erreichen. Das hat zu Folge, dass der Angreifer Nachrichten entschlüsseln und diese auch manipulieren kann.

Bei dem FT Handshake wird vorausgesetzt, dass der Client bereits die notwendigen Master Schlüssel aus einer vorherigen Verbindung besitzt. Auch wenn der 4-Wege-Handshake hier zugrunde liegt, initiiert beim FT Handshake der Client diesen Vorgang.

• Bei dem FT Handshake werden, wie beim 4-Wege-Handshake, im ersten Schritt Message 1 und Message 2 ausgetauscht. Diese heißen hier jedoch Authentication Request (AuthReq) und Authentication Response (AuthResp).
• Der Client schickt danach die Reassociation Request (ReassoReq) und der AP antwortet mit der Reassociaton Response (ReassoResp). Hier hält es sich weiterhin so wie mit der Message 3 und Message 4 im 4-Wege-Handshake. Diese beiden Nachrichten sind mit einer MIC versehen.
• Beendet wird dieser Prozess mit der Übergabe des GTK an den Client (1).

Bei dem FT Handshake wird bei den Nachrichten auf einen Replay Counter verzichtet, stattdessen soll der Schutz vor Replay Angriffen über die zufällige SNonce und ANonce sichergestellt werden. Außerdem soll der PTK nach Versand oder Erhalt der Antwort der Authentification Responses neuinstalliert werden.

Abbildung 3: Ablauf des Angriffs auf den Fast BSS Transition Handshake

Die meisten Implementierungen des Protokolls installieren den PTK und GTK erst nach Vollendung des Reassociation Prozesses, was den FT Handshake verwundbar gegen Key Reinstallment Angriffe macht.

Bei dem Angriff muss der Angreifer nur mitlauschen, anstatt die Man-in-the-Middle Position zu beziehen. Es ist wichtig, dass vor dem Versand der $ReassoResp(A/Snonce,MIC;GTK)$ Nachricht, mindestens ein verschlüsseltes Paket (2) mitgeschnitten wird. Danach sendet der Angreifer einfach erneut das Reassociation Paket an den AP (3). Weil hier kein Repaly Counter mitgeschickt wird und der MIC valide ist, akzeptiert der AP diese Nachricht. Das führt dazu, dass der AP den PTK erneut installiert und die Nonce sowie den Replay Counter zurücksetzt (3). Die danach folgenden Pakete vom AP nutzen dadurch eine bereits benutzt Nonce (4). Die Folgen dessen sind beim 4-Wege-Handshake bereits beschrieben worden. Diese Attacke kann außerdem beliebig oft ausgeführt werden, weil die Reassociation Pakete keinen Replay Counter beinhalten.

Wenn kein weiterer AP in der Nähe ist, kann ein Angreifer eine Wormhole Attacke vollziehen, in dem zwei APs strategisch durch den Angreifer positioniert werde und Pakete tunneln. Dann kann der Angreifer über den Rouge AP eine BSS Transition Management Request an den Client schicken lassen, die zu Load Balancing Zwecken verwendet wird. Dieses Paket ist nicht authentifiziert und kann vom Angreifer entsprechend geformt werden.

Betroffene Systeme

Die Abbildung 4 fasst Systeme zusammen, die von den Forschern auf Verwundbarkeit durch die beschriebenen Angriffe geprüft wurden.

Darunter befinden sich Betriebsysteme, die entsprechende Client-Implementierungen von Hause aus mitliefern, darunter OS X 10.9.5, macOS Sierra 10.12, Android 6.0.1, OpenBSD 6.1, Windows 7 und 10. In der Liste findet man wpa_supplicant in mehreren Versionen. Dabei handelt es sich um Software, die unter den Betriebssystemen BSD, Linux und Windows zum Einsatz kommt und die Rolle Clients (Supplicant) übernimmt. Dadurch hat die Verwundbarkeit des wpa_supplicant gegen Angriffe sehr weitreichende Konsequenzen und betrifft so viele Systeme.

Abbildung 4: Tabelle der Schwachstellen gegen erprobte Angriffe auf Implementierungen

Die im Abbildung 4 aufgeführten Spalten spiegeln die Anfälligkeit gegen die bestimmten Angriffe, die hier belechet wurden.

• Die zweite Spalte (Re.Msg3) zeigt, welche Systeme den Neuversand der Nachricht 3 zulassen.
• Die dritte Spalte (Pt.EAPOL) listet Systeme, die den Versand von EAPOL Nachrichten (siehe Kapitel Der 4-Wege-handshake) im Klartext zulässt, falls ein PTK bereits vorliegt.
• Die vierte Spalte (Quick Pt.) gibt wieder, ob diese Plaintext-EAPOL-Nachrichen akzeptiert werden, wenn sie sofort nach der Nachricht 3 verschickt werden.
• In der fünften Spalte (Quick Ct.) wird gezeigt, welche Systeme vom Angriff mit Versand einer verschlüsselten Nachricht 3 betroffen sind.
• Spalte sechs (4-way) zeigt die Key Reinstallation Verwundbarkeit der Systeme im 4-Wege-Handshake.
• Und die letzte Spalte gibt an, ob die einzelnen Systeme durch einen Group Key Renstalaltion Angriff verwundbar sind.

Impact des Angriffs

Der KRACK Angriff setzt darauf, dass als Datenvertraulichkeitsproktokolle die Stream Cipher TKIP, CCMP und GCMP zum Verschlüsseln der Frames benutzt werden. Bei der Wiederverwendung von Nonces entstehen gleiche Streamschlüssel, was für die besagten Protokolle ein großes Problem darstellt, weil Pakete entschlüsselt werden können.

TKIP:

Bei TKIP kann der Angreifer den Message Integrity Check (MIC) Schlüssel ermitteln. Dazu kann über die Wiederverwendung der Nonce das ganze TKIP Paket inklusive des MIC entschlüsseln. Dazu kann der als schwach geltende Michael Algorithmus (Practical verification of {WPA}-{TKIP} vulnerabilities, Practical attacks against {WEP} and {WPA}) angegriffen werden, wodurch der ganze MIC Schlüssel erbeutet wird.

CCMP:

Replay und Entschlüsselung von Paketen ist hier möglich. In der Theorie soll man auch Forging bis zu einem Grad möglich sein(Wired Equivalent Privacy(WEP)).

GCMP:

Im GCMP sind die Auswirkungen gravierend, da man Replay Attacken ausführen und Pakete entschlüsseln kann. Hinzu kommt, dass der Authentification Key ermittelt werden kann (Authentication Failures in NIST version of GCM. Das liegt daran, dass die Wiederverwendung einer Nonce beim Galois/Counter Mode dazu führt, dass man die “forbidden attack” ausführen kann und so den Authentification Key erlangen kann. Das erlaubt es dem Angreifer die Pakete in beide Richtungen zu fälschen (Forging).

Abbildung 5: Wirkungsgrad der KRACK Attacke auf Handshakes

Generell gilt, dass man je nach Handshake eine bestimmte Richtung der Kommunikation angreift. Wie man der Abbildung 5 erkennen kann, ist diese Richtung durch den Handshake vorgegeben. Bei dem Angriff auf den FT Handshake nutzt man Replay vom Client zu AP, kann dadurch Entschlüsselung von Nachrichten vom AP zum Client erreichen und ggf. eine Nachrichtenfälschung in eine, keine oder beide Richtungen durchsetzen.

All-Zero-Encryption Key in Linux und Android 6.0

Bei dem 4-Wege-Handshake ist den Forschern ein besonders schwerwiegender Fehler in wpa_supplicant aufgefallen. Bei den Implementierungen in Version 2.3 und darunter funktionierte der Angriff wie bei anderen Systemen. Im Falle von wpa_supplicant in den Versionen 2.4 und 2.5 führe die Übermittlung der Mitteilung 3 zur Installation eines all-zero encryption key (TK). Die Vermutung der Autoren des Paper lag auf einer Bemerkung im 802.11 Standard, die darauf hinwies, dass man den TK aus dem Arbeitsspeicher löschen sollte, sobald dieser installiert wurde. Dies wird zwar in der Version 2.6 wieder behoben, stellt dennoch ein gravierendes Problem für die anderen Versionen dar, da sie nicht gepatcht wurden.

Dieses Problem betrifft auch Android 6.0 sowie Android Wear 2.0 Geräte, wie die Autoren festgestellt haben. Der Grund dafür liegt darin, dass wpa_supplicant in Android und verwendet wird. Das gleiche Problem hatte auch Chromium, bei dem ebenfalls ein All-Zero Encryption Key installiert wurde.

Geräte noch immer betroffen?

Wie viele Geräte noch immer betroffen sind, ist leider nicht genau zu erkennen. Die Android Distribution Seite auf der Entwicklerseite von Google ist 2020 abgeschaltet worden. April 2020 lag die Verbreitung von Android 6.0 (Marshmellow) noch bei 11,2% (Google kills Android distribution numbers on the web, but we've got you covered). Laut der "KRACK: Hersteller-Updates und Stellungnahmen" Recherche des Heise Verlags, die alle Stellungsnamen von Herstellern von Geräten und Software zusammengetragen haben, sind viele der betroffenen Systeme entsprechend gepatcht worden.