vanhoefm/krackattacks-scriptsSkripte zur Überprüfung von WPA2-Clients und APs auf Schwachstellen der KRACK-Schlüsselreinstallation mithilfe von modifiziertem hostapd und Frame-Replay im Monitor-Modus.
Dieses Projekt enthält Skripte, um zu testen, ob Clients oder Zugriffspunkte (APs) vom KRACK-Angriff gegen WPA2 betroffen sind. Weitere Details zu diesem Angriff finden Sie auf unserer Website und in der Forschungsarbeit.
Denken Sie daran, dass unsere Skripte keine Angriffsskripte sind! Sie benötigen die entsprechenden Netzwerkzugangsdaten, um zu testen, ob ein Zugriffspunkt oder Client vom KRACK-Angriff betroffen ist.
Dezember 2024: Ein Fehler im 7. Test ./krack-test-client.py --gtkinit wurde behoben. Vor diesem Bugfix wurde erwähnt, dass (die Ausgabe) dieses Tests unzuverlässig sei, aber jetzt sollte die Ausgabe vertrauenswürdig sein, wenn die neuen Anweisungen befolgt werden. Das heißt, wenn dieser Test nun anzeigt, dass das Gerät angreifbar ist, ist es tatsächlich wahrscheinlich angreifbar.
Januar 2021: Die Skripte wurden mit Python3 kompatibel gemacht und aktualisiert, um neuere Linux-Distributionen besser zu unterstützen. Wenn Sie zur alten Version zurückwechseln möchten, führen Sie nach dem Klonen des Repositorys git fetch --tags && git checkout v1 aus (und wechseln Sie mit git checkout research zurück zur neuesten Version).
Unsere Skripte wurden unter Kali Linux getestet. Führen Sie zum Installieren der erforderlichen Abhängigkeiten unter Kali Folgendes aus:
sudo apt update
sudo apt install libnl-3-dev libnl-genl-3-dev pkg-config libssl-dev net-tools git sysfsutils python3-venv iw
Kompilieren Sie nun unsere modifizierte hostapd-Instanz und erstellen Sie eine virtuelle Python-Umgebung. Dadurch wird sichergestellt, dass Sie kompatible Python-Bibliotheken verwenden (die in krackattack/requirements.txt aufgeführten):
git clone https://github.com/vanhoefm/krackattacks-scripts.git
cd krackattacks-scripts/krackattack
./build.sh
./pysetup.sh
Deaktivieren Sie dann die Hardwareverschlüsselung für optimale Ergebnisse:
cd krackattack
sudo ./disable-hwcrypto.sh
Beachten Sie, dass Sie die Hardwareverschlüsselung bei Bedarf später mit dem Skript sudo ./reenable-hwcrypto.sh wieder aktivieren können. Es wird empfohlen, nach dem Deaktivieren der Hardwareverschlüsselung neu zu starten. Wir haben unsere Skripte mit einer Intel Dual Band Wireless-AC 7260 und einem TP-Link TL-WN722N v1 unter Kali Linux getestet.
Jedes Mal, bevor Sie die Skripte verwenden, müssen Sie WLAN in Ihrem Netzwerkmanager deaktivieren. Führen Sie dann Folgendes aus:
sudo rfkill unblock wifi
cd krackattack
sudo su
source venv/bin/activate
Danach können Sie die Skripte mehrmals ausführen, solange Sie das Terminal nicht schließen.
Wenn Sie die Auswirkungen von disable-hwcrypto.sh rückgängig machen möchten, löschen Sie die Datei /etc/modprobe.d/nohwcrypt.conf.
Ändern Sie zuerst hostapd/hostapd.conf und bearbeiten Sie die Zeile interface=, um die WLAN-Schnittstelle anzugeben, die für die Ausführung der Tests verwendet wird. Beachten Sie, dass Sie bei allen Tests, sobald das Skript läuft, das zu testende Gerät eine Verbindung zur SSID testnetwork mit dem Passwort abcdefgh herstellen lassen müssen. Sie können die Einstellungen des AP ändern, indem Sie hostapd/hostapd.conf bearbeiten. Bei allen Tests muss der Client DHCP verwenden, um eine IP zu erhalten, nachdem er eine Verbindung zum WLAN hergestellt hat. Der Grund dafür ist, dass einige Tests erst starten, nachdem der Client mithilfe von DHCP eine IP angefordert hat!
Sie sollten nun die folgenden Tests im Verzeichnis krackattacks/ ausführen:
./krack-test-client.py --replay-broadcast. Dieser Test prüft, ob der Client erneut gesendete Broadcast-Frames akzeptiert. Wenn der Client erneut gesendete Broadcast-Frames akzeptiert, muss dies zuerst gepatcht werden. Wenn Sie den Client nicht patchen, kann unser Skript nicht feststellen, ob der Gruppenschlüssel neu installiert wird (da das Skript dann immer angibt, dass der Gruppenschlüssel neu installiert wird).
./krack-test-client.py --group --gtkinit. Dieser Test prüft, ob der Client den Gruppenschlüssel im Gruppenschlüssel-Handshake mit dem angegebenen Empfangssequenzzähler (RSC) installiert. Siehe Abschnitt 6.4 unserer weiterführenden Forschungsarbeit für die Details zu dieser Schwachstelle.
./krack-test-client.py --group. Dieser Test prüft, ob der Client den Gruppenschlüssel im Gruppenschlüssel-Handshake neu installiert. Mit anderen Worten: Er testet, ob der Client anfällig für CVE-2017-13080 ist. Das Skript testet Neuinstallationen des Gruppenschlüssels, indem es Broadcast-ARP-Anfragen an den Client sendet, die eine bereits verwendete (erneut gesendete) Paketnummer verwenden (hier Paketnummer = Nonce = IV). Beachten Sie, dass dieser Test fälschlicherweise zu dem Schluss kommen könnte, dass der Gruppenschlüssel neu installiert wird, wenn der Client immer erneut gesendete Broadcast-Frames akzeptiert (siehe --replay-broadcast).
./krack-test-client.py. Dieser Test prüft auf Schlüsselneuinstallationen im 4-Wege-Handshake, indem wiederholt verschlüsselte Nachricht-3-Frames an den Client gesendet werden. Mit anderen Worten: Dieser Test prüft auf CVE-2017-13077 (die Schwachstelle mit der größten Auswirkung) und auf CVE-2017-13078. Das Skript überwacht den vom Client gesendeten Datenverkehr, um festzustellen, ob der paarweise Schlüssel neu installiert wird. Beachten Sie, dass dies effektiv zwei Tests durchführt: ob der paarweise Schlüssel neu installiert wird und ob der Gruppenschlüssel neu installiert wird. Stellen Sie sicher, dass der Client mithilfe von DHCP eine IP anfordert, damit der Test auf Neuinstallation des Gruppenschlüssels startet. Um sicherzustellen, dass der Client genügend Unicast-Frames sendet, können Sie optional den AP anpingen: ping 192.168.100.254.
./krack-test-client.py --tptk. Identisch zu Test 4, außer dass vor dem Senden der verschlüsselten Nachricht 3 eine gefälschte Nachricht 1 eingefügt wird. Diese Testvariante ist wichtig, da einige Clients (z. B. wpa_supplicant v2.6) nur dann anfällig für Neuinstallationen des paarweisen Schlüssels im 4-Wege-Handshake sind, wenn vor dem Senden einer erneut übertragenen Nachricht 3 eine gefälschte Nachricht 1 eingefügt wird.
./krack-test-client.py --tptk-rand. Dasselbe wie der obige Test, außer dass die gefälschte Nachricht 1 ein zufälliges ANonce enthält.
./krack-test-client.py --gtkinit. Dieser Test prüft, ob der Client den Gruppenschlüssel im 4-Wege-Handshake mit dem angegebenen Empfangssequenzzähler (RSC) installiert. Dies geschieht durch erneutes Übertragen von Msg3/4 des 4-Wege-Handshakes, jeweils mit einem neuen Gruppenschlüssel und einem sehr hohen Replay-Zähler. Wir wissen, dass es anfällig ist, wenn der getestete Client danach Broadcast-Frames mit einem niedrigeren Replay-Zähler akzeptiert. Leider akzeptieren einige Clients erneut übertragene Msg3/4 überhaupt nicht, sodass solche Clients mit diesem Befehl nicht getestet werden können. Clients, die erneut übertragene Msg3/4 akzeptieren und daher mit diesem Befehl getestet werden können, antworten mit einer Msg4/4, die anhand der folgenden Ausgabe erkannt werden kann:
[09:24:11] 02:20:2a:22:a8:30: received a new message 4
Wir empfehlen außerdem, diesen Test in Umgebungen mit wenig Hintergrundrauschen auszuführen und ihn mehrmals auszuführen.
Einige zusätzliche Anmerkungen:
Der wichtigste Test ist ./krack-test-client, der auf gewöhnliche Schlüsselneuinstallationen im 4-Wege-Handshake prüft.
Führen Sie diese Tests in einem Raum mit geringer Interferenz durch. Ein hohes Maß an Paketverlust macht dieses Skript weniger zuverlässig!
Optional können Sie den Netzwerkverkehr manuell untersuchen, um die Ausgabe des Skripts zu bestätigen (einige WLAN-NICs können unsere Skripte stören):