FragAttacks: Fragmentierungs- und Aggregationsangriffe

1. Einleitung

Dieses Repository enthält das FragAttacks-Werkzeug. Es kann WLAN-Clients und Access Points auf Fragmentierungs- und Aggregationsangriffe testen. Diese Schwachstellen betreffen alle geschützten WLAN-Netze. Weitere Informationen zu diesen Schwachstellen findest du unter fragattacks.com.

Die folgenden zusätzlichen Ressourcen sind verfügbar:

• Der USENIX-Sicherheitsvortrag fasst die entdeckten Schwachstellen zusammen.
• Eine Übersicht aller zugewiesenen CVEs ist verfügbar.
• Folien, die die Grundursache und Auswirkung jeder Schwachstelle zusammenfassen.
• Eine zweiseitige Zusammenfassung der resultierenden Angriffe und Voraussetzungen.
• Handouts, die zusätzlichen Hintergrund liefern und die Schwachstellen detaillierter erklären.
• Eine Demonstration von drei Beispielangriffen.
• Das Forschungspapier, veröffentlicht auf der USENIX Security.
• Beispielhafte Netzwerk-Mitschnitte, die einige der Schwachstellen veranschaulichen.
• Ein Live-USB-Image mit diesem Werkzeug und vorinstallierten modifizierten Treibern.
• Eine Liste bekannter Sicherheitshinweise von Unternehmen

Eine detaillierte Übersicht der Änderungen am Werkzeug seit dem 11. August 2020 findest du im Änderungsprotokoll. Dieses Änderungsprotokoll enthält auch Informationen darüber, auf welcher hostap-Version das FragAttacks-Werkzeug basiert.

Beachte, dass die Angriffe gegen WPA2 und WPA3 identisch sind, da deren CCMP- und GCMP-Verschlüsselungsverfahren identisch sind. Ältere WPA-Netze verwenden standardmäßig TKIP zur Verschlüsselung, und die Anwendbarkeit der Angriffe gegen TKIP wird im Papier und auf der Website diskutiert. Um zu veranschaulichen, dass WLAN seit seiner Einführung verwundbar ist, werden im Papier und auf der Website auch kurz die Anwendbarkeit der Angriffe gegen WEP diskutiert.

2. Unterstützte Netzwerkkarten

Es werden nur bestimmte WLAN-Netzwerkkarten unterstützt. Dies liegt daran, dass einige Netzwerkkarten die Sequenz- oder Fragmentnummern injizierter Frames überschreiben oder Frames unterschiedlicher Priorität neu anordnen können, und dies interferiert mit dem Testwerkzeug (d.h. das Werkzeug könnte ein Gerät als sicher einstufen, obwohl es das nicht ist). Ich habe bestätigt, dass die folgenden Netzwerkkarten ordnungsgemäß funktionieren:

Die letzten beiden Spalten bedeuten:

1. Gemischter Modus: ob die Netzwerkkarte im empfohlenen gemischten Modus verwendet werden kann.

2. Injektionsmodus: ob die Netzwerkkarte als zweite Schnittstelle zum Injizieren von Frames im Injektionsmodus verwendet werden kann.

Ja bedeutet, dass die Karte ohne weitere Anpassungen im jeweiligen Modus funktioniert. Gepatchter Treiber/Firmware bedeutet, dass die Karte kompatibel ist, wenn sie mit gepatchten Treibern und/oder Firmware verwendet wird. Nein bedeutet, dass dieser Modus von der Netzwerkkarte nicht unterstützt wird. Ich empfehle, das Testwerkzeug im gemischten Modus zu verwenden.

Beachte, dass USB-Geräte in einer virtuellen Maschine verwendet werden können und die modifizierten Treiber und/oder Firmware in dieser virtuellen Maschine installiert werden können. Allerdings habe ich festgestellt, dass die Verwendung virtueller Maschinen Netzwerkkarten weniger zuverlässig machen kann; ich empfehle stattdessen die Verwendung eines Live-USB-Images, falls du die modifizierten Treiber/Firmware nicht nativ installieren kannst.

Meine Erfahrungen mit den oben genannten Netzwerkkarten findest du hier. Zusammenfassend:

• Der AWUS036ACM erscheint im gemischten Modus mit unseren neuesten Treibern zuverlässig und ist derjenige, den ich empfehle. Ein günstigeres, aber nahezu identisches Gerät ist eines mit einem MT7612U-Chipsatz. Weitere Informationen findest du hier.

• Zuvor habe ich den Technoethical N150 HGA im gemischten Modus empfohlen. Dieser Dongle ist identisch mit dem TP-Link TL-WN722N v1.x und erfordert die Verwendung gepatchter Treiber und Firmware. Dies ist einer der am besten getesteten Dongles, aber er ist schwer zu bekommen. Deshalb empfehle ich jetzt stattdessen den AWUS036ACM.

• Die Intel 3160 und 8265 werden unterstützt und umfassend getestet. Manchmal stürzte ihre Firmware ab, aber ein Neustart macht die Netzwerkkarte wieder verwendbar. Der Intel AX200 ist nicht mit dem Testwerkzeug kompatibel.

• Der WN111v2 scheint gut zu funktionieren, auch wenn ich ihn nicht umfassend getestet habe.

• Der Treiber für den AWUS036ACH ist nicht Teil des Linux-Kernels und erfordert die Installation eines separaten Treibers. Auf Kali kannst du diesen Treiber über den Paketmanager installieren. Diese Karte wurde nicht umfassend getestet.

Falls du keine der oben genannten Netzwerkkarten findest, kannst du nach alternativen Netzwerkkarten suchen, bei denen die Wahrscheinlichkeit hoch ist, dass sie ebenfalls funktionieren. Wenn du eine nicht ausdrücklich unterstützte Netzwerkkarte verwendest, empfehle ich dringend, zuerst die Injektionstests auszuführen, bevor du sie verwendest, und das Werkzeug gegen eine bekanntermaßen verwundbare Implementierung zu testen, um sicherzustellen, dass das Werkzeug ordnungsgemäß funktioniert.

3. Voraussetzungen

Das Testwerkzeug wurde auf Ubuntu 20.04 mit Kernel 5.8 getestet. Wenn du eine andere Linux-Distribution verwendest, beachte bitte, dass nur Kernelversionen bis einschließlich 5.12 unterstützt werden.

Ubuntu 20.04 spezifisch

Wenn du Ubuntu 20.04 verwendest, musst du zuerst Kernel 5.8 wie folgt installieren. Beachte, dass dein vorhandener Kernel installiert bleibt und standardmäßig weiterhin verwendet wird:

sudo apt install linux-image-5.8.0-63-generic linux-headers-5.8.0-63-generic linux-hwe-5.8-headers-5.8.0-63 \
	linux-modules-5.8.0-63-generic linux-modules-extra-5.8.0-63-generic

Starte nun Ubuntu neu, halte beim Booten die Umschalttaste gedrückt, wähle „Erweiterte Optionen für Ubuntu" und starte dann Kernel 5.8, indem du „Ubuntu, with Linux 5.8.0-63-generic" auswählst. Du kannst deine GRUB-Konfiguration bearbeiten, damit Ubuntu diese Kernelversion standardmäßig verwendet. Fahre mit den nächsten Anweisungen unter diesem nun laufenden Kernel fort.

Allgemeine Anweisungen

Installiere die erforderlichen Abhängigkeiten:

sudo apt-get update
sudo apt-get install libnl-3-dev libnl-genl-3-dev libnl-route-3-dev libssl-dev \
	libdbus-1-dev git pkg-config build-essential macchanger net-tools python3-venv \
	aircrack-ng rfkill firmware-ath9k-htc
# Note: on Kali linux use the package firmware-atheros instead of firmware-ath9k-htc

Klone nun dieses Repository, baue die Werkzeuge und konfiguriere eine virtuelle Python3-Umgebung:

git clone https://github.com/vanhoefm/fragattacks.git fragattacks
cd fragattacks/research
./build.sh
./pysetup.sh

Die obigen Anweisungen müssen nur einmal ausgeführt werden. Nachdem du mit git neuen Code gezogen hast, musst du ./build.sh und ./pysetup.sh erneut ausführen.

4. Gepatchte Treiber

Installiere die gepatchten Treiber mit:

sudo apt-get install bison flex linux-headers-$(uname -r)
git clone https://github.com/vanhoefm/fragattacks-drivers58.git fragattacks-drivers58
cd fragattacks-drivers58
make defconfig-wifi
make -j 4
sudo make install

Dies kompiliert die Treiber für die meisten von Linux unterstützten Netzwerkkarten. Wenn du nur die Treiber für die von mir ausdrücklich getesteten Netzwerkkarten kompilieren möchtest, verwende stattdessen make defconfig-experiments. Möglicherweise erhältst du die folgenden Warnungen:

• Wenn du make defconfig-wifi ausführst, erhältst du möglicherweise Warnungen bezüglich -Wyacc und -Wformat-overflow. Du kannst diese Warnungen ignorieren, solange die Treiber erfolgreich kompiliert werden.
• Während des Installationsbefehls erhältst du möglicherweise auch die folgenden Warnungen:
  • Mehrere Warnungen mit .. needs unknown symbol ... Du kannst diese Warnungen ignorieren, solange sie nicht das Verzeichnis /lib/modules/*/updates/ enthalten und die kompilierten Treiber funktionieren.
  • Wiederholte Warnungen mit SSL error und dem sign-file-Befehl. Dies bedeutet, dass das digitale Signieren der Kernelmodule fehlgeschlagen ist. Dies kannst du normalerweise ignorieren.
• Du kannst überprüfen, ob die modifizierten Treiber gefunden wurden, indem du nach einem Neustart cat /sys/module/mac80211/parameters/fragattack_version ausführst. Wenn diese Datei existiert, wurden die modifizierten Treiber erfolgreich installiert.

Installiere nun die gepatchte ath9k_htc-Firmware:

cd research/ath9k-firmware/
./install.sh
# Now reboot

Das Skript ./install.sh geht davon aus, dass sich die ath9k_htc-Firmware-Images im Verzeichnis /lib/firmware/ath9k_htc befinden. Wenn dies auf deinem System nicht der Fall ist, musst du htc_7010.fw und htc_9271.fw manuell in das entsprechende Verzeichnis kopieren.

Nach der Installation der gepatchten Treiber und Firmware musst du deine WLAN-Dongles abziehen und dein System neu starten. Die obigen Anweisungen müssen erneut ausgeführt werden, wenn dein Linux-Kernel aktualisiert wird oder wenn die gepatchten Treiber aktualisiert werden.

Beachte, dass ich auch dann, wenn dein Gerät ohne weitere Anpassungen funktioniert, empfehle, die modifizierten Treiber zu installieren, da dies sicherstellt, dass es keine unerwarteten Regressionen im Kernel- und Treibercode gibt.

Falls du die modifizierten Treiber/Firmware nicht nativ installieren kannst, kannst du ein Live-USB-Image herunterladen, das die modifizierten Treiber/Firmware zusammen mit unserem Testwerkzeug enthält. Alternativ kannst du eine virtuelle Maschine mit USB-Netzwerkkarten verwenden, wobei ich festgestellt habe, dass die Verwendung einer virtuellen Maschine in der Praxis weniger zuverlässig ist.

5. Vor jeder Verwendung

Jedes Mal, wenn du das Testwerkzeug verwenden möchtest, musst du zuerst die virtuelle Python-Umgebung als root laden. Dies kannst du mit folgendem Befehl tun:

cd research
sudo su
source venv/bin/activate

Du solltest jetzt WLAN in deinem Netzwerkmanager deaktivieren, damit es nicht mit dem Testwerkzeug interferiert. Stelle außerdem sicher, dass keine anderen Netzwerkdienste ausgehenden Datenverkehr verursachen. Du kannst dies sicherstellen, indem du mit iptables den Datenverkehr blockierst, indem du ./droptraffic.sh ausführst (du kannst dies durch einen Neustart rückgängig machen). Optional kannst du mit sudo airmon-ng check überprüfen, welche anderen Prozesse die WLAN-Netzwerkkarte möglicherweise verwenden und mit unserem Werkzeug interferieren könnten.

Das Testwerkzeug kann sowohl Clients als auch APs testen:

• APs testen: Konfiguriere den AP, den du testen möchtest, indem du research/client.conf bearbeitest. Dies ist eine Standard-wpa_supplicant-Konfigurationsdatei; eine Übersicht aller unterstützten Optionen findest du in der hostap-Dokumentation.

• Clients testen: Du musst das Testwerkzeug mit dem Parameter --ap ausführen (siehe unten). Dies veranlasst das Werkzeug, einen AP mit dem Namen testnetwork und dem Passwort abcdefgh zu erstellen. Verbinde dich mit diesem Netzwerk mit dem Client, den du testen möchtest. Standardmäßig muss der Client eine IP-Adresse über DHCP anfordern. Um Eigenschaften des erstellten APs zu bearbeiten, z. B. den Kanal, auf dem er erstellt wird, kannst du research/hostapd.conf bearbeiten.

6. Schnittstellenmodi

6.1. Gemischter Modus

Dieser Modus erfordert nur eine WLAN-Netzwerkkarte, benötigt aber in der Regel einen gepatchten Treiber und/oder eine gepatchte Firmware. Informationen zur Installation gepatchter Treiber/Firmware findest du unter Gepatchte Treiber und unter Unterstützte Netzwerkkarten für kompatible Netzwerkkarten. Führe das Testwerkzeug in diesem Modus mit folgendem Befehl aus:

./fragattack.py wlan0 [--ap] $COMMAND

Mögliche Werte für $COMMAND sind in Test auf Schwachstellen und Erweiterte Schwachstellentests aufgelistet.

Ein Vorteil dieses Modus ist, dass er recht gut funktioniert, wenn Clients getestet werden, die möglicherweise in einen Schlafzustand wechseln. Dennoch empfehle ich, wenn möglich, die Schlaffunktionalität des getesteten Clients zu deaktivieren; siehe Umgang mit dem Schlafmodus.

6.2. Injektionsmodus

Dieser Modus erfordert zwei WLAN-Netzwerkkarten: Eine fungiert als AP oder Client, und die andere wird zum Injizieren von Frames verwendet. Der Vorteil ist, dass dieser Modus möglicherweise ohne gepatchte Treiber funktioniert. Führe das Testwerkzeug in diesem Modus mit folgendem Befehl aus:

./fragattack.py wlan0 --inject wlan1 [--ap] $COMMAND

Hier fungiert die Schnittstelle wlan0 als legitimer Client oder AP, und wlan1 wird zum Injizieren von Frames verwendet. Für wlan0 kann jede Karte verwendet werden, die den normalen Client- oder AP-Modus unter Linux unterstützt. Für wlan1 muss eine Karte verwendet werden, die gemäß Unterstützte Netzwerkkarten den Injektionsmodus unterstützt.

Beim Testen von Clients in diesem Modus können injizierte Frames gesendet werden, wenn sich der Client in einem Schlafzustand befindet. Dies führt dazu, dass Angriffe fehlschlagen; du musst also sicherstellen, dass der Client nicht in einen Schlafzustand wechselt.

6.3. Hwsim-Modus

Dieser Modus ist experimentell und nur für Forschungszwecke bestimmt. Weitere Informationen findest du unter Details zum Hwsim-Modus.

7. Test auf Schwachstellen

Du kannst Geräte testen, indem du das Testwerkzeug wie unter Schnittstellenmodi beschrieben ausführst und $COMMAND durch einen der Befehle in der folgenden Tabelle ersetzt. Wir gehen davon aus, dass Clients eine IP-Adresse über DHCP anfordern (falls dies nicht der Fall ist, siehe Statische IP-Konfiguration). Alle Befehle funktionieren, sofern nicht anders angegeben, sowohl gegen Clients als auch gegen APs.

Das Werkzeug gibt TEST COMPLETED SUCCESSFULLY aus, wenn das Gerät gegen den dem jeweiligen $COMMAND entsprechenden Angriff verwundbar ist, und Test timed out! Retry to be sure, or manually check result aus, wenn das Gerät nicht verwundbar ist. Nach Abschluss des Tests kannst du das Testwerkzeug mit CTRL+C schließen. Die meisten Angriffe haben mehrere leicht abweichende Varianten, die durch verschiedene $COMMAND-Werte dargestellt werden.

Die Überprüfung des Ergebnisses einiger Tests erfordert die Ausführung von tcpdump oder Wireshark auf dem getesteten Gerät (die folgende Tabelle gibt an, ob tcpdump verwendet werden muss). Dieser tcpdump-Paketmitschnitt darf nur Pakete enthalten, die die PHY- und MAC-Schichtverarbeitung passiert haben. Unter Linux sollte dieser Mitschnitt beispielsweise erstellt werden, während sich die WLAN-Schnittstelle im Modus „managed" oder „ap" befindet, nicht im Monitor-Modus. Das bedeutet, der Mitschnitt wird nur Pakete enthalten, die die Verarbeitung auf der WLAN-Ebene passiert haben. Siehe tcpdump auf APs vermeiden für eine Diskussion darüber, wie einige Tests dennoch ohne tcpdump auf APs durchgeführt werden können.

Um dein Testsetup zu überprüfen, führt der erste Befehl in der folgenden Tabelle einen normalen Ping aus, der erfolgreich sein muss. Der zweite Befehl sendet den Ping als zwei fragmentierte WLAN-Frames und sollte nur in dem seltenen Fall fehlschlagen, dass das getestete Gerät keine Fragmentierung unterstützt. Falls einer dieser Tests nicht funktioniert, befolge die Anweisungen unter Netzwerkkarten-Injektionstest, um sicherzustellen, dass deine Netzwerkkarte Frames ordnungsgemäß injiziert. Falls der getestete Client in den Schlafmodus wechseln könnte, siehe Umgang mit dem Schlafmodus.

Der dritte, vierte und fünfte Befehl sind keine Angriffe, sondern überprüfen das grundlegende Defragmentierungsverhalten eines Geräts und werden unterhalb der Tabelle weiter erläutert.

Wie Befehle CVEs zugeordnet werden, ist unten aufgeführt. Beachte, dass wir für Implementierungsfehler eine Referenz- CVE-Identifikationsnummer angeben; Anbieter können jedoch andere CVEs verwenden, da eine Implementierungsschwachstelle normalerweise eine eindeutige CVE für jede betroffene Codebasis erhält. Wir empfehlen dennoch, sich immer auf diese Referenz-CVEs zu beziehen, um einfach auf jede Art von entdecktem Implementierungsfehler verweisen zu können.

7.1. Plausibilitätsprüfungen

• ping: Dieser Test muss immer erfolgreich sein. Wenn er fehlschlägt, stimmt etwas mit dem Testsetup nicht.- ping I,E,E: Dieser Test sollte bei allen modernen Laptops, Smartphones und APs erfolgreich sein. Wenn er fehlschlägt, stimmt wahrscheinlich etwas mit dem Testaufbau nicht. Versuchen Sie, den Parameter --icmp-size 100 als Lösung hinzuzufügen. Wenn es mit diesem zusätzlichen Parameter funktioniert, müssen Sie auch alle anderen Tests mit diesem zusätzlichen Parameter ausführen. Der einzige Fall, in dem ich festgestellt habe, dass dieser Test aus berechtigten Gründen fehlschlägt, ist, wenn das getestete Gerät den Empfang fragmentierter Frames nicht unterstützt, was bei leichten IoT-Geräten und beispielsweise OpenBSD der Fall sein kann.

7.2. Grundlegendes Geräteverhalten

• ping I,E,E --delay 5: Dieser Test wird verwendet, um die maximal akzeptierte Verzögerung zwischen zwei Fragmenten zu prüfen. Wenn dieser Test nicht funktioniert, versuchen Sie es erneut mit --delay 1.5 oder weniger. Beispielsweise entfernt Linux Fragmente nach 2 Sekunden aus dem Speicher, d. h. eine Verzögerung von 1,8 funktioniert, während 2,2 zu keiner Antwort führt. Falls die maximal akzeptierte Verzögerung gering ist, müssen alle Fragmente, die in anderen Tests gesendet werden, innerhalb dieser maximal akzeptierten Verzögerung gesendet werden. Andernfalls schlagen Tests trivial fehl, und Sie könnten zu dem Schluss kommen, dass ein Gerät nicht anfällig für einen Angriff ist, obwohl es das tatsächlich ist.

• ping-frag-sep: Dieser Test sendet einen fragmentierten Wi-Fi-Frame, der durch einen nicht zusammenhängenden Frame getrennt ist. Das heißt, er sendet das erste Fragment, dann einen (normalen) nicht zusammenhängenden Wi-Fi-Frame und schließlich das zweite Fragment. Falls dieser Test fehlschlägt, werden wahrscheinlich auch der (standardmäßige) Mixed-Key-Angriff und der Cache-Angriff fehlschlagen (da sie das Senden anderer Frames zwischen zwei Fragmenten erfordern). Dieser Test schlägt auch fehl, wenn der Empfänger prüft, ob Fragmente aufeinanderfolgende Paketnummern haben (siehe nächsten Test ping-frag-sep --pn-per-qos).

• ping-frag-sep --pn-per-qos: Wie oben, aber das Hinzufügen des Parameters --pn-per-qos stellt sicher, dass beide Fragmente der Ping-Anfrage eine aufeinanderfolgende Paketnummer (PN) haben. Dies ist etwas, das ein Empfänger überprüfen sollte, um sicher zu sein. Leider überprüfen viele Implementierungen vor der Offenlegung unserer Ergebnisse nicht, ob PNs aufeinanderfolgend sind. Dieser Test könnte fehlschlagen, wenn der Empfänger den zuletzt empfangenen Paketzähler pro QoS-TID nicht verfolgt. In diesem Fall können Sie andere Tests ignorieren, die den Parameter enthalten.

7.3. A-MSDU-Angriffstests (§3 -- CVE-2020-24588)

Der Test ping I,E --amsdu prüft, ob eine Implementierung Nicht-SPP-A-MSDUs unterstützt (er prüft nicht, ob das Gerät anfällig für CVE-2020-24588 ist). Um Angriffe zu verhindern, muss das Netzwerk idealerweise die Verwendung von SPP-A-MSDUs vorschreiben und alle Nicht-SPP-A-MSDUs verwerfen. Allerdings implementieren die meisten Hersteller derzeit stattdessen Ad-hoc-Maßnahmen (siehe Abschnitt 7.2 des Papers). Aus diesem Grund müssen Sie die folgenden zwei Tests verwenden, um zu prüfen, ob ein Gerät anfällig für Aggregations- (A-MSDU-) Angriffe (CVE-2020-24588) ist:

• amsdu-inject: Dieser Test simuliert den in Abschnitt 3.2 des Papers beschriebenen A-MSDU-Injektionsangriff. Insbesondere sendet er einen A-MSDU-Frame, dessen Anfang auch ein gültiger LLC/SNAP-Header ist (da dies auch bei unserem Referenzangriff der Fall ist). Wenn dieser Test erfolgreich ist, ist das Gerät anfällig für CVE-2020-24588.

• amsdu-inject-bad: Einige Geräte analysieren A-MSDU-Frames, die mit einem gültigen LLC/SNAP-Header beginnen, nicht korrekt, wodurch der obige Test fehlschlägt. Versuchen Sie in diesem Fall stattdessen amsdu-inject-bad (siehe Abschnitt 3.6 im Paper). Beachten Sie, dass die Auswirkung des Angriffs, wenn dieser Test erfolgreich ist, praktisch identisch mit Implementierungen ist, die solche Frames korrekt analysieren, d. h. das Gerät ist anfällig für CVE-2020-24588.

7.4. Mixed-Key-Angriffstests (§4 -- CVE-2020-24587)

• Wenn der Mixed-Key-Test gegen einen AP ausgeführt wird, muss der AP so konfiguriert sein, dass er regelmäßig (z. B. jede Minute) den Sitzungsschlüssel (PTK) durch die Ausführung eines neuen 4-Way-Handshakes erneuert. Das Tool zeigt Client cannot force rekey. Waiting on AP to start PTK rekey an, während es auf diesen PTK-Rekey-Handshake wartet. Bei einer geringen Anzahl von APs kann das Testtool die Erneuerung des PTK auch durch Hinzufügen des Parameters --rekey-req anfordern, d. h. es besteht keine Notwendigkeit, den AP so zu konfigurieren, dass er den Schlüssel regelmäßig erneuert.

• Einige APs können nicht so konfiguriert werden, dass sie den Sitzungsschlüssel (PTK) regelmäßig erneuern. Bei diesen APs können Sie stattdessen einen Cache-Angriffstest versuchen. Falls der AP anfällig für Cache-Angriffe ist, ist er wahrscheinlich auch anfällig für Mixed-Key-Angriffe (sofern es keine starken Beweise gibt, die dem widersprechen, z. B. wenn eine Code-Überprüfung darauf hindeutet, dass Mixed-Key-Angriffe verhindert werden). Wenn der AP nicht anfällig für Cache-Angriffe ist, können wir nichts über seine Anfälligkeit für Mixed-Key-Angriffe aussagen, und in diesem Fall empfehle ich stattdessen eine Code-Überprüfung.

• ping I,F,BE,AE --pn-per-qos: Der zusätzliche Parameter --pn-per-qos stellt sicher, dass beide injizierten Fragmente aufeinanderfolgende Paketnummern haben, was erforderlich ist, damit der Mixed-Key-Angriff gegen bestimmte Geräte (z. B. gegen Linux) gelingt.

• Mehrere Geräte implementieren den 4-Way-Handshake unterschiedlich, und dies beeinflusst, ob diese Tests erfolgreich sind oder nicht. Falls die Tests fehlschlagen, wird empfohlen, auch die Mixed-Key-Angriffstests durchzuführen, die in Erweiterte Schwachstellentests aufgeführt sind.

7.5. Cache-Angriffstests (§5 -- CVE-2020-24586)

• Beim Testen eines AP sendet das Tool ein erstes Fragment, versucht dann, sich mit dem AP zu reassoziieren, und sendet schließlich das zweite Fragment. Allerdings unterstützen nicht alle APs den Reassoziationsprozess ordnungsgemäß. Fügen Sie in diesem Fall die Option --full-reconnect hinzu, wie in der Tabelle gezeigt, die das Testtool dazu veranlasst, nach dem Senden des ersten Fragments zu deauthentifizieren.

• Beim Testen eines Clients sendet das Tool ein erstes Fragment, dissoziiert den Client und sendet, sobald der Client wieder verbunden ist, das zweite Fragment. Idealerweise verbindet sich der Client sofort nach dem Senden des Dissoziations-Frames neu. Dies kann das Deaktivieren aller anderen Netzwerke im getesteten Client erfordern. Ich habe außerdem festgestellt, dass einige Clients die Dissoziation nicht ordnungsgemäß zu verarbeiten scheinen; in diesem Fall können Sie die Option --full-reconnect hinzufügen, wie in der Tabelle gezeigt, um stattdessen einen Deauthentifizierungs-Frame zu senden.

• Ich habe festgestellt, dass es am besten ist, jeden Cache-Angriffstest mehrmals auszuführen. Manchmal kann ein Cache-Angriffstest fehlschlagen, obwohl die Implementierung anfällig ist. Dies kann auf Hintergrundrauschen, andere Geräte, die Frames an das getestete Gerät senden, usw. zurückzuführen sein.

• ping I,E,R,AE [--full-recon]: Hier wird das zweite Fragment unmittelbar nach der erneuten Verbindung mit dem getesteten Gerät gesendet, was wichtig ist, falls das Gerät Fragmente nach kurzer Zeit aus dem Speicher löscht. Beachten Sie, dass full-recon eine Kurzform von full-reconnect ist.

• ping I,E,R,E [--full-recon]: Hier wird das zweite Fragment 1 Sekunde nach der erneuten Verbindung mit dem getesteten Gerät gesendet, was nützlich sein kann, falls es eine kleine Verzögerung zwischen dem Abschluss des Handshakes und der Installation des ausgehandelten Schlüssels gibt.

7.6. Angriff mit nicht aufeinanderfolgenden PNs (§6.2 -- CVE-2020-26146)

In unseren Experimenten schlug dieser Test nur gegen Linux und gegen Geräte fehl, die keine Fragmentierung unterstützen.

7.7. Gemischter Klartext-/Verschlüsselungsangriff (§6.3 -- CVE-2020-26147/26140/26143)

• ping I,E,P und linux-plain: Wenn dieser Test erfolgreich ist, werden die resultierenden Angriffe in Abschnitt 6.3 des Papers beschrieben. Zusammengefasst kann er in Kombination mit der A-MSDU- oder Cache-Schwachstelle ausgenutzt werden, um Pakete zu injizieren. Wenn er nicht mit anderen Schwachstellen kombiniert wird, ist die Auswirkung implementierungsspezifisch (CVE-2020-26147).

• ping I,P,E: Wenn dieser Test erfolgreich ist, ist es trivial, Klartext-Frames an das Gerät zu injizieren, wenn vom Netzwerk Fragmentierung verwendet wird (CVE-2020-26147).

• ping I,P: Wenn dieser Test erfolgreich ist, akzeptiert die Implementierung Klartext-Frames in einem geschützten Wi-Fi- Netzwerk, was eine triviale Paketinjektion ermöglicht (CVE-2020-26140).

• ping I,P,P: Wenn dieser Test erfolgreich ist, akzeptiert die Implementierung fragmentierte Klartext-Frames in einem geschützten Wi-Fi-Netzwerk, was eine triviale Paketinjektion ermöglicht (CVE-2020-26143).

7.8. Broadcast-Fragment-Angriffstests (§6.4 -- CVE-2020-26145)

Die folgenden beiden Tests senden Broadcast-Frames, die nicht automatisch erneut übertragen werden. Daher wird empfohlen, sie mehrmals auszuführen. Dies liegt daran, dass Hintergrundrauschen die getesteten Geräte daran hindern kann, den injizierten Broadcast-Frame zu empfangen. In meinen Experimenten waren hauptsächlich Clients betroffen (von den getesteten APs waren nur Free/NetBSD-Systeme betroffen).

• ping I,D,P --bcast-ra: Sendet nach dem Verbinden einen Unicast-Ping in einem im Klartext übertragenen 2. Fragment. Das Ergebnis dieser Angriffsvariante wird vom Testtool automatisch geprüft.

• ping D,BP --bcast-ra: Hier wird der obige Frame gesendet, während eine Verbindung zum Netzwerk hergestellt wird (d. h. während des 4-Way-Handshakes). Dies ist wichtig, da mehrere Clients und APs nur vor dem Abschluss des 4-Way-Handshakes anfällig sind. Um das Ergebnis dieses Tests zu bestätigen, müssen Sie Wireshark oder tcpdump auf dem Opfer ausführen und überwachen, ob die injizierte Ping-Anfrage vom Opfer empfangen wird. In tcpdump können Sie den Filter icmp verwenden, und in Wireshark können Sie auch den Filter frame contains "test_ping_icmp" verwenden, um diese Ping-Anfrage leichter zu erkennen. In meinen Experimenten waren hauptsächlich Clients betroffen.

7.9. A-MSDU-EAPOL-Angriffstests (§6.5 -- CVE-2020-26144)

• eapol-amsdu I,P: Dies ist der Standardtest für die in Abschnitt 6.5 des Papers diskutierte implementierungsspezifische Schwachstelle. Sowohl Clients als auch APs können anfällig sein. Das Ergebnis wird automatisch vom Testtool geprüft.

• Tests, die auf BP enden (eapol-amsdu BP und eapol-amsdu-bad BP): Diese Tests injizieren den bösartigen Frame während der Ausführung des 4-Way-Handshakes. Um das Ergebnis dieses Tests zu bestätigen, müssen Sie Wireshark oder tcpdump auf dem Opfer ausführen und überwachen, ob die injizierte Ping-Anfrage vom Opfer empfangen wird. In tcpdump können Sie den Filter icmp verwenden, und in Wireshark können Sie auch den Filter frame contains "test_ping_icmp" verwenden, um diese Ping-Anfrage leichter zu erkennen.

• Tests, die mit eapol-amsdu-bad beginnen (eapol-amsdu-bad BP und eapol-amsdu-bad I,P): Mehrere Implementierungen verarbeiten A-MSDU-Frames, deren erste 6 Bytes auch einem gültigen RFC1042-Header für EAPOL entsprechen, nicht korrekt. Um diese Implementierungen zu testen, müssen Sie die Testvariante eapol-amsdu-bad verwenden. Beachten Sie, dass die Auswirkung des Angriffs, wenn dieser Test erfolgreich ist, identisch mit Implementierungen ist, die solche Frames korrekt analysieren (Einzelheiten siehe Abschnitt 3.6 und 6.6 im Paper).

7.10. Checkliste zur Fehlerbehebung

Falls das Testtool nicht zu funktionieren scheint, prüfen Sie Folgendes:

1. Stellen Sie sicher, dass kein anderer Prozess die Netzwerkkarte verwendet (z. B. beenden Sie Ihren Netzwerkmanager).

2. Wenn zuvor alles funktioniert hat, versuchen Sie, Ihren Wi-Fi-Adapter zu entfernen, Ihren Computer oder Ihre virtuelle Maschine neu zu starten und es dann erneut zu versuchen. Versuchen Sie außerdem, die Hardwareverschlüsselung mithilfe des Skripts disable-hwcrypto.sh zu deaktivieren (starten Sie Ihren Computer nach der Ausführung dieses Skripts neu).

3. Stellen Sie sicher, dass das von Ihnen getestete Gerät nicht in einen Schlafzustand übergeht (was dazu führen würde, dass es injizierte Frames verpasst). Ich empfehle, das Testtool im gemischten Modus auszuführen, da dieser Clients besser behandelt, die möglicherweise in einen Schlafzustand übergehen.

4. Führen Sie die Injektionstests aus, um sicherzustellen, dass die Injektion ordnungsgemäß funktioniert. Stellen Sie außerdem sicher, dass ein 20-MHz-Kanal verwendet wird; die Injektion auf anderen Kanälen ist ungetestet.

5. Stellen Sie sicher, dass Ihr Rechner keinen Hintergrundverkehr erzeugt, der die Tests stört. Deaktivieren Sie insbesondere die Netzwerkfunktion in Ihrem Betriebssystem, beenden Sie Ihren DHCP-Client/-Server manuell usw. Siehe auch Vor jeder Verwendung.

6. Vergewissern Sie sich, dass Sie eine Verbindung zum richtigen Netzwerk herstellen. Überprüfen Sie client.conf doppelt.

7. Stellen Sie sicher, dass der getestete AP (AES-)CCMP als Verschlüsselungsalgorithmus verwendet. Andere Verschlüsselungsalgorithmen wie TKIP oder GCMP werden nicht unterstützt.

8. Wenn Sie den Code mit git aktualisiert haben, führen Sie ./build.sh und ./pysetup.sh erneut aus (siehe Voraussetzungen). Falls die gepatchten Treiber aktualisiert wurden, denken Sie daran, sie ebenfalls neu zu kompilieren.

9. Wenn Sie eine virtuelle Maschine verwenden, versuchen Sie stattdessen, das Testtool von einem Live-USB-Image auszuführen.

8. Erweiterte Schwachstellentests

Aufgrund von Implementierungsvarianten kann es schwierig sein, bestimmte Schwachstellen zu bestätigen/auszunutzen. Insbesondere der Mixed-Key- und der Cache-Angriff können in der Praxis nicht trivial zu bestätigen sein. Daher empfehle ich, ein Gerät nur dann als sicher zu betrachten, wenn es explizite Prüfungen im Code gibt, die diese Angriffe verhindern. Wenn die Zeit es außerdem erlaubt, empfehle ich auch die folgenden fortgeschritteneren Tests. Diese haben eine geringere Chance, neue Schwachstellen aufzudecken, können aber Angriffsvarianten oder besondere Geräteverhalten offenbaren, die die normalen Tests nicht erkennen können.

Wenn die normalen Tests in Test auf Schwachstellen das Vorhandensein einer bestimmten Schwachstellenklasse bereits bestätigt haben, besteht kaum ein Bedarf, die anderen Angriffsvarianten dieser Schwachstelle zu testen. Alle Befehle funktionieren, sofern nicht anders angegeben, sowohl gegen Clients als auch gegen APs.

8.1. A-MSDU-Angriffstests (§3 -- CVE-2020-24588)

Es ist nur sinnvoll, diese beiden Tests auszuführen, wenn der Haupttest ping I,E --amsdu fehlschlägt und Sie besser verstehen möchten, wie das getestete Gerät A-MSDU-Frames verarbeitet:

• ping I,E --amsdu-fake: Wenn dieser Test erfolgreich ist, behandelt der Empfänger alle Frames als normale Frames (d. h. er unterstützt keine A-MSDU-Frames). Dieses Verhalten ist nicht ideal, obwohl es unwahrscheinlich ist, dass ein Angreifer dies in der Praxis ausnutzen kann (siehe Abschnitt 3.5 im Paper).

• ping I,E --amsdu-fake --amsdu-spp: Wenn dieser Test erfolgreich ist, authentifiziert der Empfänger das QoS-A-MSDU-Flag jedes empfangenen Frames (d. h. er maskiert es beim Empfang nicht auf null), behandelt dann aber alle empfangenen Frames als normale Frames (d. h. er unterstützt den Empfang echter A-MSDU-Frames nicht). Dieses Verhalten ist nicht ideal, obwohl es unwahrscheinlich ist, dass ein Angreifer dies in der Praxis ausnutzen kann (siehe Abschnitt 3.5 im Paper).

8.2. Mixed-Key-Angriffstests (§4 -- CVE-2020-24587)

Die meisten Geräte, die ich getestet habe, sind anfällig für Mixed-Key-Angriffe. Falls die normalen Mixed-Key-Angriffstests darauf hindeuten, dass ein Gerät nicht anfällig ist, der Test ping-frag-sep jedoch erfolgreich ist, wird dringend empfohlen, diese alternativen Mixed-Key-Angriffstests auszuprobieren.Allgemein gilt: Wenn Sie einen AP testen, können Sie den Parameter --rekey-req zu jedem der Mixed-Key-Angriffstests hinzufügen, um aktiv einen Rekey-Handshake anzufordern. Eine geringe Anzahl von APs führt dann den Rekey-Handshake durch. Die meisten APs ignorieren diese Anforderung jedoch und müssen explizit so konfiguriert werden, dass sie den Sitzungsschlüssel (PTK) regelmäßig erneuern.

Einige Anmerkungen zu den Tests:

• ping I,F,BE,E und ping I,E,F,AE: Dies sind recht einfache Mixed-Key-Angriffstests, bei denen beide Fragmente zu unterschiedlichen Zeiten injiziert werden.

• ping I,E,F,AE --rekey-plain: Einige Treiber (z. B. MediaTek) führen den Rekey-Handshake im Klartext aus. Um Geräte zu testen, die einen solchen Treiber verwenden, müssen Sie den Parameter --rekey-plain hinzufügen.

• ping I,E,F,AE --rekey-plain --rekey-req: Diese spezielle Kombination ist nützlich, um Router zu testen, die einen MediaTek-Treiber verwenden. Diese Router führen den Rekey-Handshake im Klartext aus, und der Client kann aktiv einen Rekey-Handshake anfordern.

• ping I,E,F,AE --rekey-early-install: Eine geringe Anzahl von Clients installiert den Schlüssel (fälschlicherweise) zu früh während einer Pairwise-Session-Rekey. Um diese Clients zuverlässig zu testen, fügen Sie den Parameter --rekey-early-install hinzu. Dieser Test ist gegenüber APs nicht aussagekräftig.

• ping I,E,F,E [--rekey-pl] [--rekey-req]: Diese Testvariante ist dieselbe wie die vorherigen ping I,E,F,AE *-Tests, außer dass das zweite Fragment 1 Sekunde nach dem 4-Wege-Handshake gesendet wird. Dies kann wichtig sein, da bei einer geringen Anzahl von Geräten eine kleine Verzögerung auftritt, bevor der neue Schlüssel installiert wird. Beachten Sie, dass eine Kurzform von ist.

Schließlich sollten Sie, falls der Test ping-frag-sep nicht erfolgreich ist, den folgenden Mixed-Key-Angriffstest versuchen:

• ping I,F,BE,AE --freebsd: Dieser führt im Wesentlichen den Rekey-Handshake gegen eine FreeBSD-Implementierung oder einen Treiber, der Code von FreeBSD übernimmt, aus, ohne den Defragmentierungsprozess von Datenrahmen zu beeinträchtigen. Siehe Anhang E im Paper für Details.

8.3. Cache-Angriffstests (§5 -- CVE-2020-24586)

• ping I,E,R,AE --freebsd --full-reconnect: Mit diesem Test kann geprüft werden, ob ein FreeBSD-AP oder ein Treiber, der Code von FreeBSD übernimmt, anfällig für einen Cache-Angriff ist. Siehe Anhang E im Paper für Details zur Funktionsweise dieses Tests. Sie sollten diesen Test auch ohne den Parameter --full-reconnect ausprobieren. Der Test funktioniert auch gegen Clients, aber diese sind wahrscheinlich nicht betroffen.

• ping I,E,R,AP --freebsd --full-reconnect: Dieser Test ist eine Variante gegen FreeBSD-APs oder gegen einen Treiber, der Code von FreeBSD übernimmt, bei der das zweite Fragment nach dem erneuten Verbinden mit dem AP im Klartext gesendet wird. Bei einigen Dongles unter FreeBSD war dieser Test zuverlässiger und beweist weiterhin, dass alte Fragmente nach dem erneuten Verbinden im Speicher des AP verbleiben. Sie sollten diesen Test auch ohne den Parameter --full-reconnect ausprobieren. Der Test funktioniert auch gegen Clients, aber diese sind wahrscheinlich nicht betroffen.

• ping I,E,R,AP [--full-reconnect]: Bei diesem Test wird das zweite Fragment im Klartext gesendet. Dies kann nützlich sein, wenn das getestete Gerät den Schlüssel nicht sofort nach dem 4-Wege-Handshake installiert. Wenn dieser Test erfolgreich ist, zeigt er, dass das Gerät Fragmente nach dem (erneuten) Verbinden mit einem Netzwerk im Speicher behält, was bedeutet, dass es anfällig für Cache-Angriffe ist. Im Gegensatz zu den obigen beiden Befehlen ist dieser auch gegen Clients (sowie APs) nützlich.

8.4. Mixed-Plain/Encrypt-Angriff (§6.3 -- CVE-2020-26147)

• ping I,E,E --amsdu: Dieser Test sendet einen fragmentierten A-MSDU-Rahmen, den nicht alle Geräte korrekt empfangen können. Er testet keine Schwachstelle. Stattdessen ist dieser Test nützlich, um die praktische Ausnutzbarkeit des „Mixed-Plain/Encrypt-Angriffs“ zu bestimmen. Wenn dieser Test erfolgreich ist, ist es nämlich einfacher, das Gerät anzugreifen, wenn das zweite Fragment im Klartext gesendet werden kann (Test ping I,E,P). Siehe Abschnitt 6.3 des Papers für Details.

• ping I,E,P,E und linux-plain 3: Wenn alle anderen Mixed-Plain/Encrypt-Angriffstests nicht erfolgreich waren, können Sie auch diese beiden zusätzlichen Tests versuchen. Ich denke, es ist ziemlich unwahrscheinlich, dass dadurch eine neue Schwachstelle aufgedeckt wird.

8.5. Broadcast-Fragment-Angriffstests (Erweiterungen von §6.4)

Die meisten der folgenden Tests senden Broadcast-Frames, die nicht automatisch erneut übertragen werden. Daher wird empfohlen, sie mehrmals auszuführen. Der Grund dafür ist, dass Hintergrundrauschen die getesteten Geräte daran hindern kann, den injizierten Broadcast-Frame zu empfangen. In meinen Experimenten waren hauptsächlich Clients betroffen. Die meisten Clients sind nur während der Verbindung mit dem Netzwerk anfällig (d. h. während der Ausführung des 4-Wege-Handshakes).

• ping I,P --bcast-ra: Dies sendet eine Unicast-ICMP-Ping-Anfrage innerhalb eines Klartext-Broadcast-WLAN-Frames (CVE-2020-26145). Dieser Test kann sowohl gegen Clients als auch gegen APs durchgeführt werden.

• ping BP --bcast-ra: Ähnlich wie der obige Test ping I,P --bcast-ra, aber der Ping wird gesendet, bevor sich der Client beim Netzwerk authentifiziert hat, d. h. während der Ausführung des 4-Wege-Handshakes (CVE-2020-26145). Sie müssen tcpdump oder Wireshark ausführen, um zu prüfen, ob der Client den Frame akzeptiert. In tcpdump können Sie den Filter icmp verwenden, und in Wireshark können Sie auch den Filter frame contains "test_ping_icmp" verwenden, um diese Ping-Anfrage leichter zu erkennen.

• ping BP --bcast-ra --bcast-dst: Dieser Test ist derselbe wie der vorherige, ist aber nützlich, wenn Sie auf dem Ziel-AP kein tcpdump ausführen können. Beachten Sie, dass dieser Test nur gegen APs aussagekräftig ist. Der zusätzliche Parameter --bcast-dst in diesem Test bewirkt, dass ein anfälliger AP die injizierte Ping-Anfrage an alle verbundenen Clients broadcastet. Mit anderen Worten: Um zu prüfen, ob ein AP anfällig ist, führen Sie diesen Befehl aus und lauschen Sie auf einem zweiten Gerät, das mit dem AP verbunden ist, auf Broadcast-WLAN-Frames, indem Sie den Filter icmp oder frame contains "test_ping_icmp" verwenden.

• ping BP [--bcast-dst]: Dies ist eine Variante der obigen beiden Tests ping BP --bcast-ra [--bcast-dst], außer dass die Ping-Anfrage nun in einem Klartext-Unicast-Frame statt in einem Broadcast-Frame gesendet wird (es ist noch keine CVE zugewiesen – sie steht im Zusammenhang mit CVE-2020-26145). Dieser Test muss sowohl gegen Clients als auch gegen APs durchgeführt werden. Der Ping wird gesendet, bevor sich der Client beim Netzwerk authentifiziert hat (d. h. während der Ausführung des 4-Wege-Handshakes), was bedeutet, dass Sie tcpdump oder Wireshark ausführen müssen, um zu prüfen, ob das Gerät diesen Frame akzeptiert. Alternativ können Sie beim Testen von APs den Parameter --bcast-dst ähnlich wie im obigen Test hinzufügen und dann auf einem zweiten Gerät, das mit dem AP verbunden ist, tcpdump oder Wireshark verwenden, mit dem Filter icmp oder frame contains "test_ping_icmp".

• eapfrag BP,BP: Dies ist eine Spezialisierung der obigen Broadcast-Fragment-Tests, die durchgeführt wird, bevor sich der Client authentifiziert hat. Es handelt sich um einen sehr experimentellen Angriff, der auf der Analyse von geleaktem Code basiert. Zuerst wird ein Klartext-Fragment gesendet, das mit einem EAPOL-Header beginnt und akzeptiert wird, weil der 4-Wege-Handshake noch ausgeführt wird. Dann wird ein zweites Broadcast-Fragment mit derselben Sequenznummer gesendet. Basierend auf der Analyse von geleaktem Code akzeptieren einige Geräte dieses Fragment möglicherweise (weil das vorherige Fragment erlaubt war), aber der anschließende Code verarbeitet es als normalen Frame (weil das Fragment broadcastet wird). Sie müssen tcpdump oder Wireshark auf dem Opfer verwenden, um festzustellen, ob der Frame ordnungsgemäß empfangen wird, zum Beispiel mit dem Filter icmp oder . Eine alternative Variante ist , falls die normale Variante nicht funktioniert.

8.6. A-MSDU-EAPOL-Angriffstests (§6.5 -- CVE-2020-26144)

Dieser Test kann verwendet werden, wenn Sie die eapol-amsdu[-bad] BP-Tests ausführen möchten, aber auf dem AP kein tcpdump oder Wireshark ausführen können. Dieser Test ist nur gegen APs aussagekräftig: Der Befehl eapol-amsdu[-bad] BP --bcast-dst bewirkt, dass ein anfälliger AP die injizierte Ping-Anfrage an alle verbundenen Clients broadcastet. Mit anderen Worten: Um zu prüfen, ob ein AP anfällig ist, führen Sie diesen Befehl aus und lauschen Sie auf einem zweiten Gerät, das mit dem AP verbunden ist, auf Broadcast-WLAN-Frames, indem Sie den Filter icmp oder frame contains "test_ping_icmp" verwenden.

8.7. Angriffstests zur EAPOL-Weiterleitung durch den AP (§6.6 -- CVE-2020-26139)

• eapol-inject 00:11:22:33:44:55: Dieser Test ist nur gegen APs aussagekräftig. Um diesen Test durchzuführen, müssen Sie sich mit einem zweiten Gerät mit dem Netzwerk verbinden und die MAC-Adresse 00:11:22:33:44:55 durch die MAC-Adresse dieses zweiten Geräts ersetzen. Vor der Authentifizierung sendet das Testtool ein EAPOL-Frame an den AP, mit diesem zweiten Gerät als endgültigem Ziel. Wenn der AP das EAPOL-Frame an das zweite Gerät weiterleitet, gilt der AP als anfällig. Um zu bestätigen, ob der AP das EAPOL-Frame weiterleitet, müssen Sie auf dem zweiten Gerät tcpdump oder Wireshark ausführen. Sie können den Wireshark-Filter frame contains "forwarded_data" verwenden, wenn Sie den entschlüsselten Datenverkehr auf der WLAN-Schnittstelle des zweiten Geräts überwachen (oder den tcpdump-Filter ether proto 0x888e, um alle EAPOL-Frames zu überwachen). Siehe Abschnitt 6.6 des Papers für Details und Auswirkungen.

• eapol-inject-lage 00:11:22:33:44:55: Falls der obige eapol-inject-Test erfolgreich ist, können Sie auch eapol-inject-large ausprobieren, um zu sehen, ob diese Schwachstelle ausgenutzt werden kann, um die Übertragung verschlüsselter Fragmente zu erzwingen. Sie müssen erneut tcpdump oder Wireshark verwenden, um dies zu prüfen. Verwenden Sie den Wireshark- oder tshark-Filter (wlan.fc.frag == 1) || (wlan.frag > 0), um fragmentierte Frames zu erkennen. Ich habe festgestellt, dass dieser Angriff nur sehr selten funktioniert.

8.8. Angriffstest für fehlende Fragmentierungsunterstützung (§6.8 -- CVE-2020-26142)

• ping I,D,E: Wenn dieser Test erfolgreich ist, unterstützt der Client oder AP keine (De-)Fragmentierung, ist aber weiterhin anfällig für Angriffe. Das Problem ist, dass der Empfänger das letzte Fragment als vollständigen Frame behandelt. Siehe Abschnitt 6.8 im Paper für Details und wie dies ausgenutzt werden kann.

• ping I,E,D: Wenn dieser Test erfolgreich ist, behandelt der Client oder AP das erste Fragment als vollständigen Frame. Obwohl dieses Verhalten nicht ideal ist, ist derzeit unbekannt, ob dies für sich genommen in der Praxis ausgenutzt werden kann.

9. Erweiterte Nutzung

9.1. Injektionstests für Netzwerkkarten

Injektionsmodus

Das Skript test-injection.py kann verwendet werden, um zu testen, ob Frames bei Verwendung des Injektionsmodus ordnungsgemäß injiziert werden:

./test-injection.py wlan0 wlan1

Hier testen wir, ob die Netzwerkkarte wlan0 Frames ordnungsgemäß injiziert, und verwenden die Netzwerkkarte wlan1, um zu überwachen, ob Frames ordnungsgemäß injiziert werden. Beachten Sie, dass beide Schnittstellen den Monitor-Modus unterstützen müssen, damit dieses Testskript funktioniert.

Falls Sie keine zweite Netzwerkkarte haben, können Sie einen partiellen Injektionstest mit folgendem Befehl ausführen:

./test-injection.py wlan0

Leider kann der obige Test nur prüfen, ob der Kernel Felder injizierter Frames überschreibt; er kann nicht testen, ob die Firmware oder der WLAN-Chip selbst Felder überschreibt.

Mixed-Modus

Um zu testen, ob eine Netzwerkkarte Frames im Mixed-Modus ordnungsgemäß injiziert – dem Modus, den ich empfehle –, können Sie die folgenden beiden Befehle ausführen:

./fragattack.py wlan0 ping --inject-test wlan1
./fragattack.py wlan0 ping --inject-test wlan1 --ap

Hier testen wir, ob wlan0 Frames ordnungsgemäß injiziert, indem wir die injizierten Frames mit der zweiten Netzwerkkarte wlan1 überwachen. Der erste Befehl testet, ob Frames bei Verwendung des Mixed-Modus als Client ordnungsgemäß injiziert werden, und der zweite Befehl bei Verwendung des Mixed-Modus als AP. Um den Test zu starten, muss der Client eine Verbindung zu einem Netzwerk herstellen können, und der AP wartet, bis ein Client eine Verbindung herstellt, bevor die Injektionstests beginnen (siehe Vor jeder Verwendung für die Konfiguration der Verbindungseinrichtung von Client und AP).

Wenn Sie auch das Wiederholungsübertragungsverhalten von wlan0 im Mixed-Modus testen möchten, können Sie Folgendes ausführen:

./fragattack.py wlan0 ping --inject-test-postauth wlan1
./fragattack.py wlan0 ping --inject-test-postauth wlan1 --ap

Falls Sie keine zweite Netzwerkkarte haben, können Sie einen partiellen Mixed-Modus-Injektionstest mit folgendem Befehl ausführen:

./fragattack.py wlan0 ping --inject-test[-postauth] self
./fragattack.py wlan0 ping --inject-test[-postauth] self --ap

Leider können die obigen Tests nur prüfen, ob der Kernel Felder injizierter Frames überschreibt; sie können nicht testen, ob die Firmware oder der WLAN-Chip selbst Felder überschreibt.

Interpretieren der Testergebnisse

Das Testskript gibt eine detaillierte Ausgabe darüber, welche Tests erfolgreich waren oder fehlgeschlagen sind, und endet mit der Ausgabe von entweder ==> The most important tests have been passed successfully oder einer Meldung, die angibt, dass entweder wichtige Tests fehlgeschlagen sind oder bestimmte injizierte Frames nicht erfasst werden konnten.

Beachten Sie, dass die Injektionsskripte nur das wichtigste Verhalten testen. Der beste Weg, um zu bestätigen, dass die Injektion ordnungsgemäß funktioniert, ist, die Schwachstellentests gegen Geräte durchzuführen, die bekanntermaßen anfällig sind, und zu bestätigen, dass das Tool das/die Gerät(e) korrekt als anfällig identifiziert.

Wenn bestimmte injizierte Frames nicht erfasst werden konnten, kann dies entweder an Hintergrundrauschen liegen oder daran, dass die getestete Netzwerkkarte bestimmte Frames nicht ordnungsgemäß injizieren kann (z. B. stürzt die Firmware der Intel AX200 ab, wenn fragmentierte Frames injiziert werden). Es könnte auch sein, dass Frames tatsächlich ordnungsgemäß injiziert werden, aber die Netzwerkkarte, die zur Überwachung verwendet wird, ob Frames ordnungsgemäß injiziert werden (wlan1 in den obigen Beispielen), nicht zuverlässig ist und z. B. die meisten Frames aufgrund von Hintergrundrauschen verpasst. Versuchen Sie, die Tests auch auf einem anderen Kanal auszuführen.

Wenn die Injektionstests funktionieren, Sie aber Probleme haben, die Angriffstests zuverlässig durchzuführen, kann dies daran liegen, dass die von Ihnen getesteten Geräte in den Schlafmodus wechseln. Siehe Umgang mit dem Schlafmodus für zusätzliche Hinweise zu diesem Problem.

Hinweise zu manuellen Prüfungen

Wenn Sie Wireshark verwenden, um das Injektionsverhalten eines Geräts zu untersuchen, empfiehlt es sich, ein zweites Gerät im Monitor-Modus zu verwenden, um zu sehen, wie Frames injiziert werden.

Wenn Sie die Schnittstelle öffnen, die zum Injizieren von Frames verwendet wird, sollten Sie injizierte Frames zweimal sehen: (1) zuerst sehen Sie den Frame, wie er von dem jeweiligen sendenden Tool injiziert wurde, und dann (2) ein zweites Mal, wie der Frame vom Treiber injiziert wurde. Diese beiden Frames können leicht voneinander abweichen, wenn der Kernel bestimmte Felder überschrieben hat. Wenn Sie einen injizierten Frame nur einmal sehen, wurde er möglicherweise vom Kernel verworfen.

9.2. Statische IP-Konfiguration

Falls das von Ihnen getestete Gerät kein DHCP unterstützt, können Sie die IP-Adressen, die das Testtool verwenden soll, manuell angeben. Zum Beispiel:

./fragattack.py wlan0 [--ap] ping --inject wlan1 --ip 192.168.100.10 --peerip 192.168.100.1

Hier verwendet das Testtool die IP-Adresse 192.168.100.10 und injiziert eine Ping-Anfrage an die Peer-IP-Adresse 192.168.100.1.

Wenn ein Test IP-Pakete sendet, bevor IP-Adressen per DHCP bezogen wurden, verwendet er die Standard-IP-Adresse 127.0.0.1. Um andere (Standard-)IP-Adressen zu verwenden, können Sie auch die Parameter --ip und -peerip verwenden.

9.3. Keine ICMP-Unterstützung

Die meisten Angriffstests funktionieren, indem sie ICMP-Ping-Anfragen auf besondere Weise senden und prüfen, ob wir eine ICMP-Ping-Antwort erhalten. Falls das getestete Gerät keine ICMP-Pings unterstützt, können Sie stattdessen ARP-Anfragen verwenden, indem Sie den Parameter --arp zu allen Tests hinzufügen. Falls ein Test das Senden von ARP-Anfragen nicht unterstützt, zeigt das Tool den Fehler Cannot override request type of the selected test an; in diesem Fall kann der jeweilige Test nur mit ICMP-Ping-Anfragen ausgeführt werden.

TODO: Wenn wir als Client agieren, können wir stattdessen auch DHCP-Anfragen injizieren.

1. Netzwerkkarten, die ath9k_htc verwenden

2. Netzwerkkarten, die carl9170 verwenden

3. Netzwerkkarten, die iwlmvm verwenden.

Ich empfehle Karten auf Basis von ath9k_htc. Nicht alle Karten, die iwlmvm verwenden, sind kompatibel. Wenn Sie eine alternative Netzwerkkarte verwenden, empfehle ich dringend, zuerst die Injektionstests auszuführen, um zu bestätigen, dass die Netzwerkkarte kompatibel ist.

9.5. 5-GHz-Unterstützung

Um das Testtool auf 5-GHz-Kanälen verwenden zu können, muss die verwendete Netzwerkkarte die Injektion von Frames im 5-GHz-Kanal erlauben. Leider ist dies aufgrund regulatorischer Beschränkungen nicht immer möglich. Um zu sehen, auf welchen Kanälen Sie Frames injizieren können, können Sie iw list ausführen und unter „Frequencies“ nach Kanälen suchen, 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 zum Beispiel in der Arch-Linux-Dokumentation.

Beachten Sie, dass ein Gerät möglicherweise verschiedene Treiber für das 2,4- und das 5-GHz-Band verwendet. Daher ist es wichtig, Geräte in beiden Bändern zu testen, da sich ein Gerät je nach verwendetem Frequenzband unterschiedlich verhalten kann.

Beachten Sie, dass der Linux-Kernel im Mixed-Modus die Injektion 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. Infolgedessen verweigert Linux möglicherweise die Injektion von Frames, obwohl dies eigentlich erlaubt ist. Wenn cfg80211_reg_can_beacon unter den richtigen Bedingungen true zurückgibt, wird dieser Fehler verhindert.

In der Praxis haben einige festgestellt, dass Sie die WLAN-Netzwerkkarte zuerst manuell auf den 5-GHz-Kanal einstellen müssen, auf dem der AP arbeitet. Siehe dieses GitHub-Issue für Details.

9.6. Umgang mit dem Schlafmodus

Geräte wie Mobiltelefone oder IoT-Gadgets können ihr WLAN-Funkmodul in den Schlafmodus versetzen, um den Energieverbrauch zu reduzieren. Im Schlafmodus sind diese Geräte nicht in der Lage, WLAN-Frames zu empfangen, was unsere Tests stören kann. Es gibt einige Möglichkeiten, dieses Problem zu entschärfen:

1. Versuchen Sie, den Schlafmodus auf dem getesteten Gerät zu deaktivieren. Dies ist die zuverlässigste Lösung, aber leider nicht immer möglich.

2. Führen Sie das Testtool im Mixed-Modus aus. Die meisten Netzwerkkarten stellen injizierte Frames dann in eine Warteschlange, bis das getestete Gerät wieder aufgewacht ist.

3. Verwenden Sie eine andere Netzwerkkarte für die Tests. Ich habe festgestellt, dass verschiedene Netzwerkkarten Frames zu (geringfügig) unterschiedlichen Zeitpunkten injizieren, und dies kann den Unterschied zwischen ordnungsgemäß ankommenden und verpassten injizierten Frames ausmachen. Beispielsweise war das Testtool gegen ein Pixel 4 XL mit einer TL-WN722N unzuverlässig, funktionierte aber mit einem Intel 8265 zuverlässig.

4. Weisen Sie dem getesteten Gerät statische IPs zu und lassen Sie das Testtool statische IPs verwenden (siehe Statische IP-Konfiguration). Bei vielen Tests kann dies zuverlässiger sein, da das Testtool dann sofort den Testframe senden kann, anstatt zuerst DHCP verwenden/abwarten zu müssen.

9.7. Vermeidung von tcpdump auf APsEinige Schwachstellen können nur ausgenutzt werden, während sich das zu testende Gerät mit dem Netzwerk verbindet,

d. h., wenn es den 4-Wege-Handshake ausführt. Dadurch lassen sie sich schwerer automatisch testen, und in der Regel bedeutet das, dass tcpdump oder Ähnliches auf dem zu testenden Gerät verwendet werden muss. APs können jedoch getestet werden, ohne tcpdump auf ihnen auszuführen. Insbesondere die Tests für den Broadcast-Fragment-Angriff (CVE-2020-26145) und die Tests für den A-MSDU-EAPOL-Angriff (CVE-2020-26144) können durchgeführt werden, ohne tcpdump auf dem zu testenden Gerät auszuführen. Stattdessen muss tcpdump auf einem anderen Client laufen, der mit dem AP verbunden ist. Konkret können die folgenden Befehle verwendet werden:

• ping I,P --bcast-ra --bcast-dst und ping BP --bcast-ra --bcast-dst

• eapol-amsdu BP --bcast-dst und eapol-amsdu-bad BP --bcast-dst

Mit diesen Befehlen können Sie auf einem anderen Client, der mit dem AP verbunden ist, nach der Ping-Anfrage Ausschau halten. Falls die Ping-Anfrage auf diesem unabhängigen Client empfangen wird, ist der zu testende AP verwundbar. Leider scheint es derzeit schwierig zu sein, Clients gegen diese Angriffsvarianten zu testen, ohne tcpdump auf dem Client auszuführen.

9.8. Hinweise zur Geräteunterstützung

AWUS036ACM

Falls Linux diesen Dongle aus irgendeinem Grund nicht automatisch erkennt, führen Sie sudo modprobe mt76x2u aus, um den Treiber manuell zu laden. Dieser Dongle scheint mit unseren neuesten Treibern zuverlässig zu funktionieren. Falls der Dongle unzuverlässig ist, erstellen Sie die Datei /etc/modprobe.d/mt76.conf mit folgendem Inhalt:``` options mt76_usb disable_usb_sg=1

Starten Sie dann Ihren Rechner neu. Achten Sie außerdem darauf, ein gutes USB-Kabel mit diesem Dongle zu verwenden! Ich habe zuvor unzuverlässiges Verhalten mit diesem Dongle festgestellt, das durch ein schlechtes USB-3.0-Kabel verursacht wurde. Wenn Sie also Probleme haben, kann es helfen, den Dongle direkt ohne Kabel einzustecken.

Wenn Sie VirtualBox verwenden, stellen Sie sicher, dass Sie USB3.0 aktivieren, damit der Dongle erkannt wird. Siehe [dieses Issue](https://github.com/vanhoefm/fragattacks/issues/22) für Details.

Der AWUS036ACM verwendet intern einen MT7612U-Chipsatz. Es gibt inzwischen auch Dongles mit einem MT7612UN-Chipsatz, die mit unserem Testwerkzeug ebenfalls zuverlässig sind. Ein Beispiel ist der [CSL Wireless Network Adaptor](https://www.amazon.de/dp/B0873BNBD8?tag=modwiffir-20).

### ath9k_htc

Die Technoethical N150 HGA, der TP-Link TL-WN722N v1.x und der Alfa AWUS036NHA verwenden alle den Treiber `ath9k_htc`.

Bei mir funktionierten diese Geräte in einer virtuellen Maschine recht gut, obwohl sie wie alle Geräte zuverlässiger sind, wenn sie nativ verwendet werden. Bei Verwendung einer VM empfehle ich, die VM so zu konfigurieren, dass sie einen USB-2.0-Controller verwendet, da das stabiler erschien (zumindest mit VirtualBox).

In aktuellen Kerneln gab es eine ([inzwischen behobene](https://www.spinics.net/lists/linux-wireless/msg200825.html)) Regression mit dem Treiber `ath9k_htc`, die dazu führte, dass er nicht funktionierte. Verwenden Sie einfach einen aktuellen Kernel oder unsere gepatchten Treiber, um dieses Problem zu vermeiden.

#### AWUS036ACH

Dieses Gerät wird in den meisten Linux-Distributionen standardmäßig nicht unterstützt und erfordert die manuelle Installation von Treibern. Unter Kali Linux können Sie den Treiber mit `sudo apt install realtek-rtl88xxau-dkms` installieren. Informationen zur Installation des Treibers auf anderen Distributionen finden Sie in Ihrem Paketmanager oder folgen Sie den Installationsanweisungen auf [GitHub](https://github.com/aircrack-ng/rtl8812au). Bevor Sie das Gerät einstecken, empfiehlt es sich, `modprobe 88XXau rtw_monitor_retransmit=1` auszuführen.

Leider funktioniert dieses Gerät nicht im gemischten Modus (Mixed Mode), dem empfohlenen Modus, und es ist schwierig, es in Kombination mit unseren modifizierten Treibern zu verwenden. In der Praxis müssen Sie die modifizierten Treiber deinstallieren und das Testwerkzeug dann mit den Parametern `--no-drivercheck` und `--inject wlan0` ausführen, wobei sich wlan0 auf die AWUS036ACH-Karte bezieht. Aufgrund dieser Einschränkungen wird dieses Gerät nicht empfohlen.

### Intel AX200

Ich habe den Intel AX200 getestet und festgestellt, dass er _nicht_ mit dem Testwerkzeug kompatibel ist: Seine Firmware stürzt ab, nachdem ein Frame mit gesetztem More-Fragments-Flag injiziert wurde. Falls ein Intel-Entwickler dies liest: Bitte aktualisieren Sie die Firmware und ermöglichen Sie das Injizieren fragmentierter Frames.

### RT5572-basierte Chips

Ich habe diesen Chipsatz mit dem allgemeinen [CSL USB 2.0 WLAN Adapter 300Mbit adapter](http://www.amazon.de/dp/B00LLIOT34?tag=modwiffir-20) getestet. Nachdem ich die Hardware-Entschlüsselung durch Ausführen des Skripts `disable-hwcrypto.sh` deaktiviert hatte, konnte ich einen grundlegenden Ping-Test (`ping`) durchführen. Ein fragmentierter Ping-Test (`ping I,E,E`) war sehr unzuverlässig, funktionierte aber manchmal.

Die derzeitige Schlussfolgerung ist, dass RT5572-Chips _möglicherweise_ mit dem Testwerkzeug funktionieren, nachdem die Hardware-Verschlüsselung deaktiviert wurde. Es sind jedoch weitere Experimente erforderlich, um dies zu bestätigen (Feedback ist willkommen).

<a id="id-hwsim-details"></a>
## 9.9. Details zum Hwsim-Modus

**Warnung**: *Dies ist derzeit ein experimenteller Modus; verwenden Sie ihn nur zu Forschungszwecken.*

Dieser Modus benötigt nur eine Netzwerkkarte, die den Monitormodus unterstützt. Im Gegensatz zum gemischten Modus muss die Netzwerkkarte keine virtuellen Schnittstellen unterstützen. Der Nachteil ist, dass in diesem Modus Frames etwas langsamer verarbeitet werden und es unzuverlässig ist, wenn die Netzwerkkarte Frames nicht bestätigt:

- Aufgrund von Commit 1672c0e31917 ("mac80211: start auth/assoc timeout on frame status") schlägt die Authentifizierung als Client sofort mit einem Timeout fehl, was bedeutet, dass wir den Hwsim-Modus derzeit nicht als Client verwenden können.
  _TODO: Wir müssen den Kernel patchen, um dieses Timeout zu vermeiden._

- Wenn wir einen Client testen, der Commit 1672c0e31917 ("mac80211: start auth/assoc timeout on frame status") verwendet, müssen wir (als AP) Frames bestätigen, die an uns gesendet werden. Andernfalls kann sich der getestete Client nicht verbinden.
  _TODO: Testen, welche Geräte Frames im Monitormodus bestätigen, und `iw set wlanX monitor active` testen._

- Bestimmte APs verlangen außerdem, dass Authentifizierungs- und Assoziierungsframes vom Client bestätigt werden. Das bedeutet, dass wir (als Client) erneut Frames bestätigen müssen, die an uns gesendet werden.
  _TODO: Testen, welche Geräte Frames im Monitormodus bestätigen, und `iw set wlanX monitor active` testen._

- Aus irgendeinem seltsamen Grund kann Intel/mvm nach dem 4-Wege-Handshake keine Datenframes von Android/iPhone/iPad empfangen? Das ist ein sehr seltsamer Fehler. _TODO: Dies weiter untersuchen._

Bevor Sie diesen Modus verwenden, erstellen Sie zwei virtuelle Netzwerkkarten:

	./hwsim.sh

Dies gibt die beiden erstellten virtuellen "hwsim"-Schnittstellen aus, zum Beispiel wlan1 und wlan2. Wenn Sie in diesem Modus einen AP testen, müssen Sie zuerst den Kanal des AP suchen und die echte Netzwerkkarte auf diesen Kanal legen:

	./scan.sh wlan0
	ifconfig wlan0 down
	iw wlan0 set type monitor
	ifconfig wlan0 up
	# Pick the channel that the AP is on (in this example 11)
	iw wlan0 set channel 11

Hier bezieht sich wlan0 auf die _echte_ Netzwerkkarte (nicht auf eine von `hwsim.sh` erstellte Schnittstelle). Beim Testen eines Clients müssen Sie den Kanal nicht zuerst konfigurieren (er wird aus `hostapd.conf` übernommen). Sie können das Testwerkzeug nun wie folgt starten:

	./fragattack.py	 wlan0 --hwsim wlan1,wlan2 [--ap] $COMMAND

Nachdem das Werkzeug ausgeführt wurde, können Sie es direkt mit einem neuen `$COMMAND` erneut ausführen.

<a id="id-wpa3-sae"></a>
## 9.10. Testen von WPA3- und SAE-Geräten

Sie können einen WPA3/SAE-AP testen, indem Sie die folgenden beiden Zeilen in `client.conf` aufnehmen:

	key_mgmt=SAE
	ieee80211w=1

Um WPA3/SAE-Clients zu testen, können Sie `hostapd.conf` ändern und die Parameter setzen:

	wpa_key_mgmt=SAE
	ieee80211w=2

Wir haben das oben Genannte mit einem Intel 8265, Intel 3160, Netgear WN111v2 (`carl9170`), TP-Link TL-WN722N (`ath9k_htc`) und WNDA3200 (`ath9k_htc`) getestet. Mit diesen Geräten konnte ich mich mit dem AP verbinden und einige Tests ausführen. Es scheint also, dass dies mit allen bereits unterstützten Dongles funktionieren sollte. Beachten Sie, dass ich dies nicht im Detail getestet habe: Meine Annahme war, dass es keine Auswirkungen auf die Testergebnisse hat, ob ein Gerät im WPA2- oder WPA3-Modus arbeitet.

Die mitgelieferte `client.conf` aktiviert standardmäßig sowohl die Hunting-and-Pecking-Methode als auch die Hash-to-Element-Methode. Um einen AP einzurichten, der Hash-to-Element unterstützt (und damit die neuesten WPA3/SAE-Clients zu testen), können Sie `hostapd.conf` ändern und den Parameter setzen:

	sae_pwe=2

Durch das Setzen dieses Werts akzeptiert der AP sowohl die Hunting-and-Pecking-Methode als auch die Hash-to-Element-Methode.

<a id="id-live-image"></a>
## 9.11. Live-USB-Image

Laden Sie das [Live-USB-Image](https://people.cs.kuleuven.be/~mathy.vanhoef/fragattacks/ubuntu-20.04.2-fragattacks-1.3.3-amd64.iso) herunter und schreiben Sie es mit folgenden Befehlen auf USB:

	# Unmount in case there's an old partition on the USB
	sudo umount /dev/sdb*
	# Copy the image
	sudo dd bs=4M if=ubuntu-20.04.2-fragattacks-1.3.3-amd64.iso of=/dev/sdb conv=fdatasync status=progress

Die sha256sum des Images ist `4b973452a08b981778285a33accfd4ce58625a91e8e0eab20941facf54904bba`. Ersetzen Sie `/dev/sdb` durch Ihren USB-Stick. Wenn Sie kein Linux verwenden, suchen Sie online, wie Sie ein ISO-Image auf Ihren USB-Stick schreiben.

Wenn Sie das Live-Image starten, klicken Sie beim Booten auf "Try Ubuntu". Öffnen Sie ein Terminal, indem Sie mit der rechten Maustaste auf den Desktop klicken und "Open in Terminal" auswählen, und führen Sie dann Folgendes aus:

	cd ~/fragattacks/research
	sudo su
	nmcli radio wifi off
	source venv/bin/activate

Sie können nun `./fragattacks.py` ausführen und den normalen Anweisungen in dieser README folgen. Denken Sie daran, Wi-Fi wie oben gezeigt mit `nmcli radio wifi off` zu deaktivieren, andernfalls stört der Netzwerkmanager von Ubuntu das Testwerkzeug. Diese README ist auf dem Live-Image ebenfalls unter `~/fragattacks/README.md` vorhanden.

Beachten Sie, dass airmon-ng auf dem Live-Image unzuverlässig sein kann und es besser ist, [iw](https://github.com/vanhoefm/fragattacks/issues/36) zu verwenden.

<a id="id-design-notes"></a>
# 10. Design-Hinweise

Die an den Ping-Befehl übergebenen Argumente legen fest, welche Aktionen das Testwerkzeug ausführt und wann diese Aktionen ausgeführt werden. Jede Aktion wird durch ein Komma (`,`) getrennt. Standardmäßig wird eine Aktion ausgeführt, nachdem der Client verbunden ist; in diesem Fall repräsentiert ein einzelner Buchstabe, welche Aktion ausgeführt wird. Beachten Sie, dass dies in der Funktion [`stract2action`](https://github.com/vanhoefm/fragattacks/blob/master/research/fragattack.py#L23) implementiert ist. Mögliche Aktionen sind:

- `I`: eine IP-Adresse beziehen. Standardmäßig geschieht dies über DHCP, sofern nicht eine IP-Adresse explizit über die Argumente `--ip` und `--peerip` angegeben wird; in diesem Fall wird nichts getan.
- `E`: ein verschlüsseltes Paket/Fragment der Ping-Anfrage injizieren.
- `P`: ein Klartext-Paket/Fragment der Ping-Anfrage injizieren.
- `F`: den Sitzungsschlüssel erneuern, indem der 4-Wege-Handshake initiiert wird (als AP) oder auf den 4-Wege-Handshake gewartet wird (als Client).
- `R`: den Client sich erneut mit dem Netzwerk verbinden lassen.
- `D`: Dies ist eine spezielle "Meta-Aktion". Behandeln Sie dies wie ein leeres Fragment der Ping-Anfrage, das tatsächlich nicht gesendet wird.

Wenn es nur eine einzelne `E`- oder `P`-Aktion gibt, wird die Ping-Anfrage als einzelner Frame injiziert. Wenn es mehrere `E`-, `P`-Aktionen gibt, wird die Ping-Anfrage fragmentiert, wobei die Anzahl der Fragmente der Anzahl der `E`- oder `P`-Aktionen entspricht. Wenn die spezielle `D`-Aktion vorhanden ist, wird die Ping-Anfrage über die verbleibenden `E`- oder `P`-Aktionen fragmentiert (siehe die Beispiele in der Tabelle). Dieses Fragmentierungsverhalten ist in der Klasse [PingTest](https://github.com/vanhoefm/fragattacks/blob/master/research/tests_common.py#L47) implementiert.

Ein Buchstabe kann vor die oben genannten Aktionen gesetzt werden, um zu ändern, wann die Aktion ausgeführt werden soll:

- `S`: die Aktion wird bei der 1. oder 2. Nachricht des 4-Wege-Handshakes ausgeführt.
- `B`: die Aktion wird bei der 3. oder 4. Nachricht des 4-Wege-Handshakes ausgeführt.
- `A`: die Aktion wird unmittelbar nach Abschluss des 4-Wege-Handshakes ausgeführt.
- `C`: die Aktion wird 1 Sekunde nach Abschluss des 4-Wege-Handshakes ausgeführt. Die Anzahl der Sekunden, die gewartet wird, kann über den Parameter `--connected-delay` geändert werden.

Siehe zum Beispiel die beiden obigen Tabellen mit Befehlen.

<a id="id-change-log"></a>
# 11. Änderungsprotokoll

**Version 1.3.4 (in Arbeit):**:

- EAPOL-(Rekey)-Request-Frames immer verschlüsseln, auch wenn --rekey-plaintext verwendet wird.

- Der Client akzeptiert nun wiederholte (replayed) EAPOL-Frames. Dies stellt sicher, dass Rekeys auch dann funktionieren, wenn der getestete AP Rekeys falsch implementiert.

- wpa_supplicant wurde aktualisiert, um die Verbindung zu Enterprise-Netzwerken mit MS-CHAPv2 wieder zu ermöglichen. Zuvor war MD4 standardmäßig deaktiviert, wenn das Betriebssystem OpenSSL 3.0 oder höher verwendet, sodass MS-CHAPv2 nicht verwendet werden konnte.

- Den Parameter `--pre-test-delay` hinzugefügt. Dieser fügt eine Verzögerung zwischen dem Erhalten einer IP-Adresse und dem Senden der ersten Fragmente/Frames ein. Siehe den [Pull Request](https://github.com/vanhoefm/fragattacks/pull/44) von Michael Trimarchi und Angelo Compagnucci.

- Die modifizierten Treiber wurden aktualisiert, sodass sie auch mit Linux-Kernel 5.13 kompilieren. Dies ist experimentell.

- Den Injektionstest zuverlässiger gemacht, indem im Reorder-Test länger auf Frames gewartet wird.

- Mehrere kleinere Änderungen vorgenommen, um das Kompilieren des Codes auf älteren Plattformen (mit älteren Python-Versionen und OpenSSL-Bibliotheken) zu erleichtern.

- Die README um ein Beispiel ergänzt, wie ein älterer unterstützter Kernel unter Ubuntu 20.04 installiert wird. Design-Hinweise hinzugefügt. Empfiehlt nun den AWUS036ACM.

**Version 1.3.3 (11. Mai 2021)**:

- Die modifizierten Treiber wurden aktualisiert, sodass sie mit Linux-Kernel 5.10, 5.11 und 5.12 kompilieren.

- Firmware für `ath9k_htc`-Geräte aktualisiert (sollte keine Auswirkungen auf Tests haben).

- Das Repository für die öffentliche Veröffentlichung umstrukturiert. Interne Dokumente und Folien entfernt, um stattdessen auf die öffentlichen Versionen dieser Dokumente zu verweisen.

- Grundlegende Unterstützung für 40-MHz-Kanäle bei Verwendung des Parameters `--inject-test[-postauth]` zum Testen der Injektion. In tatsächlichen Schwachstellentests ist die Verwendung von 40-MHz-Kanälen ungetestet (verwenden Sie bei Bedarf `disable_ht40` in `client.conf`).

**Version 1.3.2 (8. März 2021)**:

- Präsentations-[Handouts](https://papers.mathyvanhoef.com/fragattacks-slides-2021-03-8.pdf) und eine [Zusammenfassung](https://papers.mathyvanhoef.com/fragattacks-overview.pdf) der Grundursache und Auswirkung jeder Schwachstelle hinzugefügt.

- Diese README aktualisiert, um zu [erklären](#id-test-sanity), dass der Parameter `--icmp-size 100` oder ähnlich zu allen Tests hinzugefügt werden kann, die fragmentierte Frames senden, wenn das getestete Gerät nur Fragmente einer bestimmten Mindestgröße akzeptiert.

- Kleinere Tippfehler in dieser README korrigiert.

**Version 1.3.1 (1. März 2021)**:

- Den Test [`ping BP [--bcast-dst]`](#id-extended-bcast-check-ping-bp) zu dieser README hinzugefügt. Er injiziert einen Klartext-Ping während der Verbindung (d. h. während des 4-Wege-Handshakes). Sowohl Clients als auch APs können gegenüber diesem Angriff verwundbar sein.

- Die [Angriffsübersicht](#id-paper-clarifications) um neue Beispiele aktualisiert, wie Paketinjektions-Schwachstellen in der Praxis missbraucht werden können. Dies umfasst Techniken, um IPv4-only-Clients dazu zu bringen, einen bösartigen DNS-Server zu verwenden, sowie Techniken, um direkt mit Geräten hinter einer NAT/Firewall zu kommunizieren (z. B. um lokale Dienste auszunutzen).

- Klargestellt, dass [Broadcast-Fragment-Tests](#id-extended-bcast-check) sowohl gegen Clients als auch gegen APs durchgeführt werden können.

- Das Testwerkzeug prüft nun, ob die erwartete Version der Python-Scapy-Bibliothek geladen wurde.

- Einige Verweise auf das Paper in dieser README korrigiert (verweist nun ordnungsgemäß auf die Abschnitte 6.4, 6.6 und 6.8).

- Auf Entwurfsversion 3 des Papers aktualisiert. Im Vergleich zu Entwurfsversion 2 gibt es keine größeren Änderungen, nur geringfügige Text- und Strukturanpassungen. Inhaltlich ist dies nun die endgültige Version des Papers.

**Version 1.3 (20. Januar 2021)**:

- Diese Version basiert auf hostap-Commit `a337c1d7c` ("New TWT operations and attributes to TWT Setup and Nudge").

- Eine [Übersicht](https://github.com/vanhoefm/fragattacks/blob/HEAD/attacks.pdf) über Angriffe und ihre Voraussetzungen hinzugefügt und [diese Folien](https://github.com/vanhoefm/fragattacks/blob/HEAD/amsduattack.pdf) erstellt, um besser zu veranschaulichen, wie der Aggregationsangriff (CVE-2020-24588) in der Praxis funktioniert.

- <a href="#id-wpa3-sae">Anweisungen</a> hinzugefügt, wie WPA3/SAE-Geräte entweder mit der Hunting-and-Pecking- oder der Hash-to-Element-Methode getestet werden können. Dies impliziert auch, dass Management Frame Protection (MFP) vom Testwerkzeug unterstützt wird.

- Eine Klarstellung zu dieser README hinzugefügt, wie tcpdump verwendet wird, um das Ergebnis bestimmter Tests zu überprüfen.

- Den zusätzlichen Test `ping BP --bcast-ra --bcast-dst` zu dieser README hinzugefügt, um CVE-2020-26145 gegen APs testen zu können, die tcpdump nicht ausführen können (bei diesem Test muss tcpdump auf einem unabhängigen verbundenen Client ausgeführt werden).

- Die zusätzlichen Tests `ping I,E,F,E [--rekey-pl] [--rekey-req]` zu dieser README hinzugefügt, um Mixed-Key-Angriffe (CVE-2020-24587) bei bestimmten Geräten besser zu erkennen.

- Die Injektion fragmentierter Frames bei Verwendung von ath9k_htc-Dongles in Kombination mit 802.11n behoben.

- Das Skript `pysetup.sh` wurde hinzugefügt, um die Python-Virtual-Environment zu erstellen. Dieses Skript behebt auch [einen Fehler](https://github.com/secdev/scapy/commit/46fa40fde4049ad7770481f8806c59640df24059) in der Scapy-Bibliothek bei Verwendung mit Python 3.9.

- Die gepatchten Treiber wurden aktualisiert, um unter Linux 5.9.0 ordnungsgemäß zu kompilieren.

- Den Test `ping-frag-sep` behoben. Zuvor verhielt er sich wie `ping-frag-sep --pn-per-qos`. Beachten Sie, dass dieser Test nicht zur Erkennung von Schwachstellen dient, sondern nur zum besseren Verständnis von Implementierungen.

**Version 1.2 (15. November 2020)**:

- Diese Version (und niedrigere) basiert auf hostap-Commit `1c67a0760` ("tests: Add basic power saving tests for ap_open").

- Das Werkzeug beendet sich automatisch, nachdem ein Test abgeschlossen ist oder ein Timeout aufgetreten ist.

- Das Werkzeug erkennt, ob der 4-Wege-Handshake in einer Schleife läuft oder ob keine Antwort auf eine Rekey-Anfrage (`--rekey-req`) erfolgt.

- Bei Verwendung eines externen DHCP-Servers sendet das Werkzeug nun EAPOL-Frames immer mit dem AP als Zieladresse (anstatt des DHCP-Servers). Dies ist wichtig bei Mixed-Key- und Cache-Angriffstests, wenn ein externer DHCP-Server verwendet wird.

- Beim Testen eines AP mit `--rekey-req` sendet das Werkzeug nun den EAPOL-Rekey-Request mit einem Replay-Zähler von eins statt null.

- Die Debug-Ausgabe zeigt nun den korrekten (Gruppen-)Schlüssel beim Verschlüsseln von Broadcast-/Multicast-Frames. Dies beeinflusst keine Testergebnisse, sondern ändert nur die Ausgabe des Testwerkzeugs.

- Klargestellt, dass alle Befehle in dieser README sowohl Clients als auch APs testen können, sofern nicht anders angegeben.

- Die Beschreibung von Cache-Angriffen, Broadcast-Fragment- und A-MSDU-EAPOL-Angriffstests in dieser README klargestellt.

- In dieser README klargestellt, dass es wichtig ist, sowohl das 2,4-GHz- als auch das 5-GHz-Band zu testen.

**Version 1.1 (20. Oktober 2020)**:

- Einen Fehler behoben, bei dem der Befehl `ping I,E,D` eine normale verschlüsselte Ping-Anfrage sendete. Er sendet nun eine verschlüsselte Ping-Anfrage mit gesetztem More-Fragments-Flag im Header.

- Die Befehle `amsdu-inject-[bad]` in Abschnitt 7 dieser README verschoben. Diese simulieren reale Angriffe und können verwendet werden, um zu überprüfen, ob temporäre Gegenmaßnahmen funktionieren (siehe Abschnitt 7.2 im Paper).

- Die Schreibweise von A-MSDU-SPPs in dieser README und im Testwerkzeug korrigiert. Das neue Argument `--amsdu-spp` ist nun ein Synonym des alten Arguments `--amsdu-ssp`.

**Version 1.0 (11. August 2020)**:

- Erste Veröffentlichung für die Nutzung während des Embargos vorbereitet.