Amazing-Mirror/fragattacks
1
0
Fork 0
mirror of https://github.com/vanhoefm/fragattacks.git synced 2024-11-25 00:38:24 -05:00
Code Issues Projects Releases Wiki Activity

fragattack: clarify tcpdump usage in README

Browse Source
This commit is contained in:
Mathy Vanhoef 2020-12-18 21:11:46 +04:00
parent 0593119c76
commit 48ca650035
1 changed files with 31 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

37
research/README.md
View File

@ -24,6 +24,8 @@ the paper also briefly discusses the applicability of the attacks against WEP.
- This version is based on hostap commit **XXX**. - This version is based on hostap commit **XXX**.
- Added a clarification to this README on how to use tcpdump to verify the result of certain tests.
- Added the extra tests `ping I,E,F,E [--rekey-pl] [--rekey-req]` to this README to better detect mixed key - Added the extra tests `ping I,E,F,E [--rekey-pl] [--rekey-req]` to this README to better detect mixed key
attacks (CVE-2020-24587) in certain devices. attacks (CVE-2020-24587) in certain devices.
@ -273,9 +275,14 @@ All commands work against both clients and APs unless noted otherwise.
The tool outputs `TEST COMPLETED SUCCESSFULLY` if the device is vulnerable to the attack corresponding The tool outputs `TEST COMPLETED SUCCESSFULLY` if the device is vulnerable to the attack corresponding
to the given `$COMMAND`, and outputs `Test timed out! Retry to be sure, or manually check result` if to the given `$COMMAND`, and outputs `Test timed out! Retry to be sure, or manually check result` if
the device is not vulnerable. After the test completed you can close the test tool using `CTRL+C`. the device is not vulnerable. After the test completed you can close the test tool using `CTRL+C`.
Most attacks have several slight variants represented by different `$COMMAND` values. Verifying the Most attacks have several slight variants represented by different `$COMMAND` values.
result of some tests requires running tcpdump or wireshark on the targeted device (this is further
clarified below the table). Verifying the result of some tests requires running tcpdump or wireshark on the device under test (the
table below states if tcpdump has to be used). This tcpdump packet capture must only include packets that
passed PHY and MAC layer processing. For instance, on Linux this capture should be made while the
wireless interface is in "managed" or "ap" mode, not in monitor mode, meaning the capture will only
contain packets that passed processing at the Wi-Fi layer. See [avoiding tcpdump on APs](#id-avoiding-tcpdump-aps)
for a discussion on how some tests can nevertheless be performed without having to run tcpdump on APs.
To **verify your test setup**, the first command in the table below performs a normal ping that must To **verify your test setup**, the first command in the table below performs a normal ping that must
succeed. The second command sends the ping as two fragmented Wi-Fi frames, and should only fail succeed. The second command sends the ping as two fragmented Wi-Fi frames, and should only fail
@ -882,8 +889,26 @@ are some options to try to mitigate this problem:
With many tests this can be more reliable because the test tool can then immediately send the test frame instead With many tests this can be more reliable because the test tool can then immediately send the test frame instead
of first having to use/wait on DHCP. of first having to use/wait on DHCP.
<a id="id-avoiding-tcpdump-aps"></a>
## 9.7. Avoiding tcpdump on APs
Some vulnerabilities can only be exploited while the device under test is connecting to the network,
i.e., when it's executing the 4-way handshake. This makes them harder to test automatically and typically
means that tcpdump or similar has to be used on the device under test. However, APs can be tested without running
tcpdump on it. In particular, the broadcast fragment attack tests (CVE-2020-26145) and A-MSDU EAPOL attack
tests (CVE-2020-26144) can be performed without running tcpdump on the device under test. Instead, tcpdump has
to run on another client connected to the AP. Concretely, the following commands can be used:
- `ping I,P --bcast-ra` and `ping BP --bcast-ra --bcast-dst`
- `eapol-amsdu BP --bcast-dst` and `eapol-amsdu-bad BP --bcast-dst`
With these commands, you can monitor for the ping request on another client that is connected to the AP. In
case the ping request is received on this independent client, the AP under test is vulnerable. Unfortunately,
currently, it appears hard to test clients against these attack variants without running tcpdump on the client.
<a id="id-notes-device-support"></a> <a id="id-notes-device-support"></a>
## 9.7. Notes on device support ## 9.8. Notes on device support
### ath9k_htc ### ath9k_htc
@ -920,7 +945,7 @@ after injecting a frame with the More Fragments flag set. If an Intel developer
update the firmware and make it possible to inject fragmented frames. update the firmware and make it possible to inject fragmented frames.
<a id="id-hwsim-details"></a> <a id="id-hwsim-details"></a>
## 9.8. Hwsim mode details ## 9.9. Hwsim mode details
**Warning**: *this is currently an experimental mode, only use it for research purposes.* **Warning**: *this is currently an experimental mode, only use it for research purposes.*
@ -968,7 +993,7 @@ start the test tool as follows:
After the tool executed, you can directly run it again with a new `$COMMAND`. After the tool executed, you can directly run it again with a new `$COMMAND`.
<a id="id-wpa3-sae"></a> <a id="id-wpa3-sae"></a>
## 9.9. Testing WPA3 and SAE devices ## 9.10. Testing WPA3 and SAE devices
You can test a WPA3/SAE AP by including the following two lines in `client.conf`: You can test a WPA3/SAE AP by including the following two lines in `client.conf`: