fragattack: updated A-MSDU EAPOL attack description and minor fixes

research/README.md

@@ -283,12 +283,12 @@ device and are further discussed below the table.
 | `linux-plain`                    | Mixed plaintext/encrypted fragmentation attack specific to Linux.
 | <div align="center">*[Broadcast fragment attack (§6.4)](#id-test-broadcastfrag)*</div>
 | `ping I,D,P --bcast-ra`          | Send a unicast ping in a plaintext broadcasted 2nd fragment once connected.
-| `ping D,BP --bcast-ra`           | Same as above, but the ping is sent during the handshake (check with tcpdump).
+| `ping D,BP --bcast-ra`           | Same as above, but frame is sent during 4-way handshake (check with tcpdump).
-| <div align="center">*[A-MSDUs EAPOL attack (§6.5)](#id-test-cloackamsdu)*</div>
+| <div align="center">*[A-MSDU EAPOL attack (§6.5)](#id-test-cloackamsdu)*</div>
-| `eapol-amsdu BP`                 | Send A-MSDU disguised as EAPOL during handshake (check result with tcpdump).
+| `eapol-amsdu I,P`                | Send a plaintext A-MSDU containing a ping request cloacked as an EAPOL frame.
-| `eapol-amsdu I,P`                | Same as above, except the frame is injected after obtaining an IP.
+| `eapol-amsdu BP`                 | Same as above, but the frame is sent during the handshake (check with tcpdump).
-| `eapol-amsdu-bad BP`             | Send malformed A-MSDU disguised as EAPOL during handshake (use tcpdump).
+| `eapol-amsdu-bad I,P`            | Send malformed plain. A-MSDU containing a ping req. cloacked as EAPOL frame.
-| `eapol-amsdu-bad I,P`            | Same as above, except the frame is injected after obtaining an IP.
+| `eapol-amsdu-bad BP`             | Same as above, but the frame is sent while connecting (check with tcpdump).
 
 How commands match to CVEs is listed below. Note that for implementation flaws we list a reference
 CVE identifier, however, vendors may use different CVEs because an implementation vulnerability normally
@@ -410,32 +410,35 @@ In our experiments, this test only failed against Linux and against devices that
 <a id="id-test-broadcastfrag"></a>
 ## 7.7. Broadcast fragment attack tests (§6.4 -- CVE-2020-26145)
 
-- Because all these tests send broadcast frames, which are not automatically retransmitted, it is recommended
+The following two tests send broadcast frames, which are not automatically retransmitted, and it is therefore
-  to **execute these tests several times**. This is because background noise may prevent the tested devices
+recommended to **execute them several times**. This is because background noise may prevent the tested devices
-  from receiving the injected broadcast frame. So far only clients were affected by these attacks. Additionally,
+from receiving the injected broadcast frame:
-  most clients are only vulnerble while connecting to the network (i.e. during the execution of the 4-way handshake).
 
-- `ping I,D,P --bcast-ra`: Variant of the attack whose result can be checked automatically by the test tool.
+- `ping I,D,P --bcast-ra`: Send a unicast ping in a plaintext broadcasted 2nd fragment once connected. The result
+   of this variant of the attack is checked automatically by the test tool.
 
-- `ping D,BP --bcast-ra`: To confirm the result of this test you have to run wireshark or tcpdump on
+- `ping D,BP --bcast-ra`: Here the above frame is sent while connecting to the network (i.e. during the 4-way handshake).
-  the victim, and monitor whether the injected ping request is received by the victim. In tcpdump you can
+  This is important because several clients and APs are only vulnerable before completing the 4-way handshake. To
-  use the filter `icmp` and in wireshark you can also use the filter `frame contains "test_ping_icmp"`
+  confirm the result of this test you have to run wireshark or tcpdump on the victim, and monitor whether the
-  to more easily detect this ping request.
+  injected ping request is received by the victim. In tcpdump you can use the filter `icmp` and in wireshark you
+  can also use the filter `frame contains "test_ping_icmp"` to more easily detect this ping request.
 
 <a id="id-test-cloackamsdu"></a>
-## 7.8. A-MSDUs EAPOL attack tests (§6.5 -- CVE-2020-26144)
+## 7.8. A-MSDU EAPOL attack tests (§6.5 -- CVE-2020-26144)
 
-- `eapol-amsdu[-bad] BP`: These two tests inject the malicious frame while the client is still connecting
+- `eapol-amsdu I,P`: This is the standard test for the implementation-specific vulnerability discussed in
-  to the network (i.e. during the execution of the 4-way handshake). This is important because several
+  Section 6.5 of the paper. Its result is checked automatically by the test tool.
-  clients and APs are only vulnerable before completing the 4-way handshake. To confirm the result of this
-  test you have to run wireshark or tcpdump on the victim, and monitor whether the injected ping request
-  is received by the victim. In tcpdump you can use the filter `icmp` and in wireshark you can also use the
-  filter `frame contains "test_ping_icmp"` to more easily detect this ping request.
 
-- `eapol-amsdu-bad BP` and `eapol-amsdu-bad I,P`: Several implementations incorrectly process A-MSDU frames
+- Tests ending on `BP` (`eapol-amsdu BP` and `eapol-amsdu-bad BP`): These tests inject the malicious frame
-  that start with a valid EAPOL header. To test these implementations, you have to use the `eapol-amsdu-bad`
+  while the client is still connecting to the network (i.e. during the execution of the 4-way handshake).
-  test variant. Note that if this tests succeeds, the impact of the attack is identical to implementations
+  To confirm the result of this test you have to run wireshark or tcpdump on the victim, and monitor whether
-  that correctly parse such frames (for details see Section 3.6 and 6.8 in the paper).
+  the injected ping request is received by the victim. In tcpdump you can use the filter `icmp` and in wireshark
+  you can also use the filter `frame contains "test_ping_icmp"` to more easily detect this ping request.
+
+- Tests starting with `eapol-amsdu-bad` (`eapol-amsdu-bad BP` and `eapol-amsdu-bad I,P`): Several implementations
+  incorrectly process A-MSDU frames whose first 6 bytes also equal a valid EAPOL header. To test these implementations,
+  you have to use the `eapol-amsdu-bad` test variant. Note that if this tests succeeds, the impact of the attack is
+  identical to implementations that correctly parse such frames (for details see Section 3.6 and 6.8 in the paper).
 
 ## 7.9. Troubleshooting checklist
 
@@ -623,10 +626,10 @@ Finally, in case the test `ping-frag-sep` doesn't succeed, you should try the fo
 ## 8.6. A-MSDU EAPOL attack tests (§6.5 -- CVE-2020-26144)
 
 This test can be used in case you want to execute the `eapol-amsdu[-bad] BP` tests but cannot run tcpdump or wireshark on
-the AP. This means this test is only meaningfull against APs. In particular, the command `eapol-amsdu[-bad] BP --bcast-dst`
+the AP. This test is only meaningfull against APs: the command `eapol-amsdu[-bad] BP --bcast-dst` causes a vulnerable AP
-will cause a vulnerable AP to broadcast the ping request to all connected clients. In other words, to check if an AP is
+to broadcast the injected ping request to all connected clients. In other words, to check if an AP is vulnerable, execute this
-vulnerable, execute this command, and listen for broadcast Wi-Fi frames on a second device that is connected to the AP by
+command, and listen for broadcast Wi-Fi frames on a second device that is connected to the AP by using the filter `icmp` or
-using the filter `icmp` or `frame contains "test_ping_icmp"`.
+`frame contains "test_ping_icmp"`.
 
 <a id="id-extended-apforward"></a>
 ## 8.7. AP forwards EAPOL attack tests (§6.6 -- CVE-2020-26139)
@@ -679,8 +682,8 @@ it cannot test whether the firmware or wireless chip itself overwrites fields.
 
 ### Mixed mode
 
-To test whether a network card properly injects frames in _mixed mode_, you can execute the
+To test whether a network card properly injects frames in _mixed mode_, which is the mode I
-following two commands:
+recommend to use, you can execute the following two commands:
 
 	./fragattack wlan0 ping --inject-test wlan1
 	./fragattack wlan0 ping --inject-test wlan1 --ap
@@ -689,7 +692,8 @@ Here we test whether `wlan0` properly injects frames by monitoring the injected
 second network card `wlan1`. The first command tests if frames are properly injected when using
 mixed mode while acting as a client, and the second command when using mixed mode while acting
 as an AP. In order to start the test, the client must be able to connect to a network, and the
-AP waits until a client is connecting before starting the injection tests.
+AP waits until a client is connecting before starting the injection tests (see [Before every usage](#id-before-every-usage)
+for configuring the connection setup of the client and AP).
 
 If you also want to test the retransmission behaviour of `wlan0` in mixed mode you can execute:
 
@@ -755,7 +759,7 @@ parameters.
 
 Most attack tests work by sending ICMP ping requests in special manners, and seeing wether we receive
 an ICMP ping response. In case the device being tested does not support ICMP pings you can instead
-using ARP requests by adding the `--arp` parameter to all tests. **TODO: Explain in detial for which**
+use ARP requests by adding the `--arp` parameter to all tests. **TODO: Explain in detial for which**
 **tests this parameter has an effect.**.
 
 **TODO: When acting as a client we can also inject DHCP requests intead.**