Updated README and SUMMARY

README

@@ -1,14 +1,13 @@
 fragattacks
 -----------
 
-See research/README.md for documentation on how to test implementations
-for aggregation and fragmentation attacks.
+See research/README.md for documentation on how to use this tool.
 
 Copyright of portions of this project are held by Jouni Malinen and
-contributors (see below). Copyright of project fragsattacks are held by
+contributors (see below). Copyright of project fragattacks are held by
 Mathy Vanhoef <mathy.vanhoef@nyu.edu> and contributors.
 
-Software of project krackattacks is licensed under the 2-clause BSD
+Software of project fragattacks is licensed under the 2-clause BSD
 license (the license below with the 3rd clause removed).
 
 

research/README.md

@@ -86,7 +86,7 @@ The test tool was tested on Kali Linux and Ubuntu 20.04. To install the required
 Now clone this repository, build the tools, and configure a virtual python3 environment:
 
 	# **TODO: replace with real HTTP unauthenticated link on release**
-	git clone https://gitlab.com/aconf/wifi.git fragattack --recursive
+	git clone https://github.com/vanhoefm/fragattack.git fragattack
 	cd fragattack/research
 	./build.sh
 	python3 -m venv venv
@@ -189,7 +189,8 @@ see [Handling sleep mode](#id-handling-sleep).
 ## 6.2. Injection mode
 
 This mode requires two wireless network cards: one will act as an AP or the client, and the other
-one will be used to inject frames. Execute the test tool in this mode using:
+one will be used to inject frames. The advantage is that this mode way work without requiring patched
+drivers. Execute the test tool in this mode using:
 
 	./fragattack wlan0 --inject wlan1 [--ap] $COMMAND
 
@@ -227,8 +228,8 @@ is not working, follow the instructions in [network card injection test](#id-inj
 to assure your network card is properly injecting frames. If the client being tested might enter
 sleep mode, see [Handling sleep mode](#id-handling-sleep).
 
-The third and fourth commands are not attacks but verify basic defragmentation behaviour of a device
-and are further discussed below the table.
+The third, fourth, and fifth commands are not attacks but verify basic defragmentation behaviour of a
+device and are further discussed below the table.
 
 |             Command              | Short description
 | -------------------------------- | ---------------------------------
@@ -238,6 +239,7 @@ and are further discussed below the table.
 | <div align="center">*Basic device behaviour*</div>
 | `ping I,E,E --delay 5`           | Send a normal fragmented ping with a 5 second delay between fragments.
 | `ping-frag-sep`                  | Send a normal fragmented ping with fragments separated by another frame.
+| `ping-frag-sep --pn-per-qos`     | Same as above, but also works if the target only accepts consecutive PNs.
 | <div align="center">*A-MSDU attacks (§3)*</div>
 | `ping I,E --amsdu`               | Send a ping encapsulated in a normal (non SSP protected) A-MSDU frame.
 | <div align="center">*Mixed key attacks (§4)*</div>
@@ -284,6 +286,10 @@ and are further discussed below the table.
   sending other frames between two fragments). The only purpose of this test is to better understand the
   behaviour of a device and to learn why other tests might be failing.
 
+- `ping-frag-sep --pn-per-qos`: Same as above, but adding the `--pn-per-qos` parametermeans  both fragments
+  have a consecutive Packet Number (PN). This is something that a reciever should be verifying in order to be
+  secure. Unfortunately, many implementations don't verify whether PNs are consecutive.
+
 ## 7.2. A-MSDU attack tests (§3 -- CVE-2020-24588)
 
 The test `ping I,E --amsdu` checks if an implementation supports A-MSDUs, in which case it is vulnerable to
@@ -300,9 +306,10 @@ for details.
   parameter, meaning there is no need to configure the AP to periodically renew the key.
 
 - Some APs cannot be configured to regularly renew the session key (PTK). Against these APs you can instead
-  try to run a cache attack test. In case the AP is vulnerable to cache attacks, then it is also vulnerable
-  to mixed key attacks. If the AP isn't vulnerable to cache attacks, then we cannot say anything about its
-  susceptibility to mixed key attacks, and in that case I recommend performing a code audit instead.
+  try a cache attack test. In case the AP is vulnerable to cache attacks, then it is likely also vulnerable
+  to mixed key attacks (unless these is strong evidence that contradict this, e.g., a code audit indicates
+  mixed key attacks are prevented). If the AP isn't vulnerable to cache attacks, then we cannot say anything
+  about its susceptibility to mixed key attacks, and in that case I recommend doing a code audit instead.
 
 - `ping I,F,BE,AE --pn-per-qos`: The extra `--pn-per-qos` parameter assures that both injected fragments have
   consecutive packet numbers, which is required for the mixed key attack to succeed against certain devices
@@ -774,7 +781,7 @@ In recent kernels there was a ([now fixed](https://www.spinics.net/lists/linux-w
 regression with the `ath9k_htc` driver causing it not te work. Simply use an up-to-date kernel or our patched
 drivers to avoid this issue.
 
-### AWUS036ACM
+#### AWUS036ACM
 
 If for some reason Linux does not automatically recognize this device, execute `sudo modprobe mt76x2u`
 to manually load the driver. I found that, at least on my devices, this dongle was unstable when connected

research/SUMMARY.md

@@ -6,29 +6,29 @@ This document contains a summary of the discovered vulnerabilities.
 
 - **CVE-2020-24588: Accepting non-SSP A-MSDU frames**: The 802.11 standard that underpins Wi-Fi Protected Access (WPA, WPA2, and WPA3) and Wired Equivalent Privacy (WEP) doesn't require that the A-MSDU flag in the plaintext QoS header field is authenticated. Against devices that support receiving non-SSP A-MSDU frames, which is mandatory as part of 802.11n, an adversary can abuse this to inject arbitrary network packets.
 
-- **CVE-2020-24587: Reassembling fragments encrypted under different keys**: The 802.11 standard that underpins Wi-Fi Protected Access (WPA, WPA2, and WPA3) and Wired Equivalent Privacy (WEP) doesn't require that all fragments of a frame are encrypted under the same key. An adversary can abuse this to decrypt selected fragments when another device sends fragmented frames and the WEP, CCMP, or GCMP encryption key is periodically renewed.
+- **CVE-2020-24587: Reassembling fragments encrypted under different keys**: The 802.11 standard that underpins Wi-Fi Protected Access (WPA, WPA2, and WPA3) and Wired Equivalent Privacy (WEP) doesn't require that all fragments of a frame are encrypted under the same key. An adversary can abuse this to exfiltrate selected fragments when another device sends fragmented frames and the WEP, CCMP, or GCMP encryption key is periodically renewed.
 
-- **CVE-2020-24586: Not clearing fragments from memory when (re)connecting to a network:** The 802.11 standard that underpins Wi-Fi Protected Access (WPA, WPA2, and WPA3) and Wired Equivalent Privacy (WEP) doesn't require that received fragments must be cleared from memory after (re)connecting to a network. Under the right circumstances, when another device sends fragmented frames encrypted using WEP, CCMP, or GCMP, this can be abused to inject arbitrary network packets and/or decrypt user data.
+- **CVE-2020-24586: Not clearing fragments from memory when (re)connecting to a network:** The 802.11 standard that underpins Wi-Fi Protected Access (WPA, WPA2, and WPA3) and Wired Equivalent Privacy (WEP) doesn't require that received fragments must be cleared from memory after (re)connecting to a network. Under the right circumstances, when another device sends fragmented frames encrypted using WEP, CCMP, or GCMP, this can be abused to inject arbitrary network packets and/or exfiltrate user data.
 
 ## Common Implementation Vulnerabilities
 
-- **Reassembling encrypted fragments with non-consecutive packet numbers**: Vulnerable implementations defragment (i.e. reassemble) fragments with non-consecutive packet numbers. An adversary can abuse this to decrypt selected fragments. This vulnerability is exploitable when another device sends fragmented frames and the WEP, CCMP, or GCMP encryption cipher is used (e.g. all WPA2 and WPA3 networks use CCMP or GCMP).
+- **Reassembling encrypted fragments with non-consecutive packet numbers**: Vulnerable WPA, WPA2, or WPA3 implementations reassemble fragments with non-consecutive packet numbers. An adversary can abuse this to exfiltrate selected fragments. This vulnerability is exploitable when another device sends fragmented frames and the WEP, CCMP, or GCMP data-confidentiality protocol is used.
 
-- **Reassembling mixed encrypted/plaintext fragments**: Vulnerable implementations defragment (i.e. reassemble) fragments even though some of them were sent in plaintext while connected to a protected Wi-Fi network. This vulnerability can be abused to inject packets and/or decrypt selected fragments when another device sends fragmented frames and the WEP, CCMP, or GCMP encryption cipher is used (e.g. all WPA2 and WPA3 networks use CCMP or GCMP).
+- **Reassembling mixed encrypted/plaintext fragments**: Vulnerable WEP, WPA, WPA2, or WPA3 implementations reassemble fragments even though some of them were sent in plaintext. This vulnerability can be abused to inject packets and/or exfiltrate selected fragments when another device sends fragmented frames and the WEP, CCMP, or GCMP data-confidentiality protocol is used.
 
-- **Accepting plaintext broadcast fragments as full frames (while connected to an encrypted network)**: Vulnerable implementations process broadcast fragments as full frames, and moreover accept plaintext broadcast fragments as full frames. An adversary can abuse this to inject arbitary network packets.
+- **Accepting plaintext broadcast fragments as full frames (in an encrypted network)**: Vulnerable WEP, WPA, WPA2, or WPA3 implementations accept second (or subsequent) broadcast fragments even when sent in plaintext and process them as full unfragmented frames. An adversary can abuse this to inject arbitary network packets independent of the network configuration.
 
-- **Accepting plaintext A-MSDU frames that start with an rfc1042 header (in an encrypted network)**: Vulnerable implementations accept plaintext A-MSDU frames as long as the first 6 to 8 bytes correspond to a valid rfc1042 (i.e. EAPOL LLC/SNAP) header. An adversary can abuse this to inject arbitrary network packets independent of the network configuration.
+- **Accepting plaintext A-MSDU frames that start with an EAPOL LLC/SNAP header (in an encrypted network)**: Vulnerable WEP, WPA, WPA2, or WPA3 implementations accept plaintext A-MSDU frames as long as the first 8 bytes correspond to a valid EAPOL LLC/SNAP header. An adversary can abuse this to inject arbitrary network packets independent of the network configuration.
 
 ## Other Implementation Vulnerabilities
 
-- **Accepting plaintext data frames when connected to an encrypted network**: Vulnerable implementations accept plaintext frames when connected to a protected Wi-Fi network. An adversary can abuse this to inject arbitrary packets independent of the network configuration.
+- **Accepting plaintext data frames in a protected network**: Vulnerable WEP, WPA, WPA2, or WPA3 implementations accept plaintext frames in a protected Wi-Fi network. An adversary can abuse this to inject arbitrary packets independent of the network configuration.
 
-- **Accepting plaintext fragmented data frames when connected to an encrypted network**: Vulnerable implementations accept plaintext fragmented frames when connected to a projected Wi-Fi network. An adversary can abuse this to inject arbitrary packets independent of the network configuration.
+- **Accepting plaintext fragmented data frames in an protected network**: Vulnerable WEP, WPA, WPA2, or WPA3 implementations accept plaintext fragmented frames in a protected Wi-Fi network. An adversary can abuse this to inject arbitrary packets independent of the network configuration.
 
-- **Forwarding EAPOL frames even though the sender is not yet authenticated**: Vulnerable APs will forward EAPOL frames to other clients even though the sender has not yet successfully authenticated to the AP. This makes it easier to exploit vulnerabilities in connected clients.
+- **Forwarding EAPOL frames even though the sender is not yet authenticated**: Vulnerable Access Points (APs) forward EAPOL frames to other clients even though the sender has not yet successfully authenticated to the AP. This can be abused in projected Wi-Fi networks to launch denail-of-service attacks against connected clients and makes it easier to exploit other vulnerabilities in connected clients.
 
-- **Not verifying the TKIP MIC of fragmented frames**: Vulnerable implementations do not verify the Message Integrity Check, i.e., authenticity, of fragmented TKIP frames. An adversary can abuse this to inject and possibly decrypt packets.
+- **Not verifying the TKIP MIC of fragmented frames**: Vulnerable implementations do not verify the Message Integrity Check (authenticity) of fragmented TKIP frames. An adversary can abuse this to inject and possibly decrypt packets in WPA or WPA2 networks that support the TKIP data-confidentiality protocol.
 
-- **Processing fragmented frames as full frames**: Vulnerable implementations treat fragmented frames as full frames. An adversary can abuse this to inject arbitrary packets, independent of the network configuration.
+- **Processing fragmented frames as full frames**: Vulnerable WEP, WPA, WPA2, or WPA3 implementations treat fragmented frames as full frames. An adversary can abuse this to inject arbitrary packets, independent of the network configuration.