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).

Voraussetzungen

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.

Vor jeder Verwendung

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.

Testen von Clients

Ä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: .

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):
- Verwenden Sie eine zusätzliche WLAN-NIC im Monitor-Modus, um zu bestätigen, dass unser Skript (der AP) Frames mit den richtigen Paketnummern (IVs) sendet. Prüfen Sie insbesondere, ob erneut gesendete Broadcast-Frames tatsächlich mit einer bereits verwendeten Paketnummer (IV) gesendet werden.
- Verwenden Sie eine zusätzliche WLAN-NIC im Monitor-Modus, um Neuinstallationen des paarweisen Schlüssels zu überprüfen, indem Sie die IVs der vom Client gesendeten Frames überwachen.
- Erfassen Sie den Datenverkehr auf dem Client, um zu sehen, ob die erneut gesendeten Broadcast-ARP-Anfragen akzeptiert werden oder nicht.
Wenn der Client mehrere WLAN-Funkmodule/NICs verwenden kann, führen Sie den Test mit mehreren WLAN-NICs durch.
Sie können den Parameter --debug hinzufügen, um mehr Debug-Ausgabe zu erhalten.
Alle nicht erkannten Parameter werden an hostapd weitergereicht, sodass Sie beispielsweise -dd -K hinzufügen können, um hostapd alle Debug-Informationen auszugeben.

Entsprechung zu den Wi-Fi-Alliance-Tests

Die Wi-Fi Alliance hat ein benutzerdefiniertes Schwachstellenerkennungstool entwickelt, das auf unseren Skripten basiert. Zum Zeitpunkt der Erstellung dieses Dokuments ist dieses Tool nur für Mitglieder der Wi-Fi Alliance zugänglich. Das Tool unterstützt mehrere verschiedene Tests, und diese Tests entsprechen den Funktionen unseres Skripts wie folgt:

4.1.1 (Klartext-Neuübertragung von EAPOL Message 3). Wir unterstützen diesen Test derzeit nicht. Dieser Test ist sowieso nicht notwendig. Stellen Sie sicher, dass das getestete Gerät Test 4.1.3 besteht, dann wird es auch diesen Test bestehen.
4.1.2 (Sofortige Neuübertragung von EAPOL M3 im Klartext). Wir unterstützen diesen Test derzeit nicht. Stellen Sie erneut sicher, dass das getestete Gerät Test 4.1.3 besteht, dann wird es auch diesen Test bestehen.
4.1.3 (Sofortige Neuübertragung von verschlüsseltem EAPOL M3 während des paarweisen Rekey-Handshakes). Dies entspricht ./krack-test-client.py, außer dass verschlüsselte EAPOL M3 periodisch statt sofort gesendet werden.
4.1.5 (PTK-Neuinstallation im 4-Wege-Handshake, wenn die STA eine temporäre PTK-Konstruktion verwendet, gleiches ANonce). Führen Sie diesen Test mit ./krack-test-client.py --tptk aus.
4.1.6 (PTK-Neuinstallation im 4-Wege-Handshake, wenn die STA eine temporäre PTK-Konstruktion verwendet, zufälliges ANonce). Führen Sie diesen Test mit ./krack-test-client.py --tptk-rand aus.
4.2.1 (Schwachstellentest für den Gruppenschlüssel-Handshake an der STA). Führen Sie diesen Test mit ./krack-test-client.py --group aus.
4.3.1 (Neuinstallation von GTK und IGTK auf einer STA, die den WNM-Schlafmodus unterstützt). Wir unterstützen diesen Test derzeit nicht (und die Wi-Fi Alliance eigentlich auch nicht!).

Testen von Zugriffspunkten: Erkennen eines anfälligen FT-Handshakes (802.11r)

Erstellen Sie eine wpa_supplicant-Konfigurationsdatei, mit der eine Verbindung zum Netzwerk hergestellt werden kann. Ein grundlegendes Beispiel ist:
```
 ctrl_interface=/var/run/wpa_supplicant
 network={
   ssid="testnet"
   key_mgmt=FT-PSK
   psk="password"
 }
```
Beachten Sie die Verwendung von „FT-PSK". Speichern Sie die Datei als network.conf oder ähnlich. Weitere Informationen finden Sie unter wpa_supplicant.conf.
Versuchen Sie, mit dem wpa_supplicant Ihrer Plattform eine Verbindung zum Netzwerk herzustellen. Dies erfordert wahrscheinlich einen Befehl wie:
```
 sudo wpa_supplicant -D nl80211 -i wlan0 -c network.conf
```
Wenn dies fehlschlägt, unterstützt der AP entweder kein FT, oder Sie haben in Schritt 1 die falschen Netzwerkkonfigurationsoptionen angegeben. Beachten Sie, dass der AP nicht von dieser Schwachstelle betroffen ist, wenn er kein FT unterstützt.
Verwenden Sie dieses Skript als Wrapper für den vorherigen wpa_supplicant-Befehl:
```
 sudo su
 source venv/bin/activate
 ./krack-ft-test.py wpa_supplicant -D nl80211 -i wlan0 -c network.conf
```
Dadurch wird der wpa_supplicant-Befehl mit den angegebenen Parametern ausgeführt und eine virtuelle Monitor-Schnittstelle hinzugefügt, die Angriffstests durchführt. Es ist wichtig, zuerst root zu werden und dann die virtuelle Python-Umgebung zu laden (siehe oben, wie Sie diese virtuelle Umgebung erstellen).

Verwenden Sie wpa_cli, um zu einem anderen AP desselben Netzwerks zu wechseln. Zum Beispiel:

 wpa_cli -i wlan0
 > status
 bssid=c4:e9:84:db:fb:7b
 ssid=testnet
 ...
 > scan_results 
 bssid / frequency / signal level / flags / ssid
 c4:e9:84:db:fb:7b	2412  -21  [WPA2-PSK+FT/PSK-CCMP][ESS] testnet
 c4:e9:84:1d:a5:bc	2412  -31  [WPA2-PSK+FT/PSK-CCMP][ESS] testnet
 ...
 > roam c4:e9:84:1d:a5:bc
 ...

Extra: Hardware-Entschlüsselung

Um zu bestätigen, dass die Hardware-Entschlüsselung deaktiviert ist, führen Sie nach dem Anschließen Ihrer WLAN-NIC systool -vm ath9k_htc oder Ähnliches aus, um zu bestätigen, dass der Parameter nohwcript/swcrypto/hwcrypto gesetzt wurde. Beachten Sie, dass Sie ath9k_htc durch das Kernelmodul für Ihre WLAN-Netzwerkkarte ersetzen müssen.

Extra: 5 GHz wird nicht unterstützt

Es gibt keine offizielle Unterstützung für das Testen von Geräten im 5-GHz-Band.

Wenn Sie das Tool dennoch auf 5-GHz-Kanälen verwenden möchten, muss die verwendete Netzwerkkarte das Injizieren von Frames im 5-GHz-Kanal erlauben. Leider ist dies aufgrund regulatorischer Einschränkungen nicht immer möglich. Um zu sehen, auf welchen Kanälen Sie Frames injizieren können, führen Sie iw list aus und schauen Sie unter Frequencies nach Kanälen, die nicht als disabled, no IR oder radar detection markiert sind. Beachten Sie, dass diese Bedingungen von Ihrer Netzwerkkarte, dem aktuell konfigurierten Land und dem AP, mit dem Sie verbunden sind, abhängen können. Weitere Informationen finden Sie beispielsweise in der Arch-Linux-Dokumentation.

Beachten Sie, dass der Linux-Kernel das Injizieren von Frames möglicherweise nicht erlaubt, obwohl das Senden normaler Frames erlaubt ist. Dies liegt daran, dass der Kernel in der Funktion ieee80211_monitor_start_xmit die Injektion von Frames verweigert, wenn cfg80211_reg_can_beacon false zurückgibt. Daher verweigert Linux möglicherweise das Injizieren von Frames, obwohl dies eigentlich erlaubt ist. Das lässt sich verhindern, indem cfg80211_reg_can_beacon unter den richtigen (oder allen) Bedingungen true zurückgibt. Sie müssen also die Linux-Treiber so patchen, dass cfg80211_reg_can_beacon immer true zurückgibt, zum Beispiel indem Sie den Code des packport driver manuell patchen.

Extra: Manuelle Tests

Es ist auch möglich, manuell (detailliertere) Tests durchzuführen, indem Sie das hostap-Git-Repository klonen:

git clone git://w1.fi/srv/git/hostap.git

Und den Anweisungen in tests/cipher-and-key-mgmt-testing.txt folgen.

krackattacks-scripts

Beliebteste