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

fragattack: updated README based on feedback WFA

Browse Source
This commit is contained in:
Mathy Vanhoef 2020-10-30 16:24:46 +04:00
parent 65a533d905
commit ca9a02b3b9
2 changed files with 52 additions and 34 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

84
research/README.md
View File

@ -20,6 +20,15 @@ the paper also briefly discusses the applicability of the attacks against WEP.
## 2.2. Change log
**Version 1.2 (? November 2020)**:
- Clarified that all commands can test both clients and APs unless noted otherwise.
- Clarified the description of cache attacks, Broadcast fragment, and A-MSDU EAPOL attack tests in this README.
- Debug output now shows the correct (group) key when encrypting broadcast/multicast frames. This does not
influence any test results, it only changes the output of the test tool.
**Version 1.1 (20 October 2020)**:
- Fixed a bug where the command `ping I,E,D` would send a normal encrypted ping request. It now sends an
@ -234,6 +243,7 @@ for more information.
You can test devices by running the test tool as discussed in [interface modes](#id-interface-modes)
and replacing `$COMMAND` with one of the commands in the table blow. We assume that clients will
request an IP using DHCP (if this is not the case see [static IP configuration](#id-static-ip-config)).
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
to the given `$COMMAND`, and outputs `Test timed out! Retry to be sure, or manually check result` if
@ -315,7 +325,7 @@ include) these reference CVEs as a way to easily refer to each type of discovere
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
- `ping-frag-sep --pn-per-qos`: Same as above, but adding the `--pn-per-qos` parameter assures 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.
@ -379,11 +389,11 @@ The last two tests are used to simulate our A-MSDU injection attack:
sending frames to the tested device, etc.
- `ping I,E,R,AE [--full-reconnect]`: Here the second fragment is sent immediately after reconnecting with the
AP, which is important in case the device under test clears fragments from memory after a short time.
device under test, which is important in case the device clears fragments from memory after a short time.
- `ping I,E,R,E [--full-reconnect]`: Here the second fragment is sent 1 second after reconnecting with the AP,
which can be useful in case there is a small delay between completion of the handshake and installing the
negotiated key.
- `ping I,E,R,E [--full-reconnect]`: Here the second fragment is sent 1 second after reconnecting with the
device under test, which can be useful in case there is a small delay between completion of the handshake
and installing the negotiated key.
- Overall it can be tedious to test if a device is vulnerable to cache attacks. Therefore I also recommend to
perform a code audit to check if fragments stay in the memory after disassociating or deauthenticating from
@ -421,30 +431,34 @@ recommended to **execute them several times**. This is because background noise
from receiving the injected broadcast frame:
- `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.
of this variant of the attack is checked automatically by the test tool. In my experiments mainly clients were
affected.
- `ping D,BP --bcast-ra`: Here the above frame is sent while connecting to the network (i.e. during the 4-way handshake).
This is important because several 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.
can also use the filter `frame contains "test_ping_icmp"` to more easily detect this ping request. In my experiments
mainly clients were affected.
<a id="id-test-cloackamsdu"></a>
## 7.8. A-MSDU EAPOL attack tests (§6.5 -- CVE-2020-26144)
- `eapol-amsdu I,P`: This is the standard test for the implementation-specific vulnerability discussed in
Section 6.5 of the paper. Its result is checked automatically by the test tool.
Section 6.5 of the paper. Both clients and APs can be vulnerable. Its result is checked automatically by
the test tool.
- Tests ending on `BP` (`eapol-amsdu BP` and `eapol-amsdu-bad BP`): These tests inject the malicious frame
while the client is still connecting to the network (i.e. during the execution of 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.
during the execution of 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.
- 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).
incorrectly process A-MSDU frames whose first 6 bytes also equal a valid RFC1042 header for EAPOL. 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
@ -497,7 +511,8 @@ I also recommend the following more advanced tests. These have a lower chance of
but might reveal attack variants or particular device behaviour that the normal tests can't detect.
If the normal tests in [Testing for Vulnerabilities](#id-testing-for-flaws) have already confirmed the
presence of a certain vulnerability class, there is no need to test the other attack variants of that vulnerability.
presence of a certain vulnerability class, there is little need to test the other attack variants of that vulnerability.
All commands work against both clients and APs unless noted otherwise.
| Command | Short description
| -------------------------------------- | ---------------------------------
@ -523,7 +538,7 @@ presence of a certain vulnerability class, there is no need to test the other at
| `ping I,P --bcast-ra` | Ping in a plaintext broadcast frame after 4-way HS.
| `ping BP --bcast-ra` | Ping in plaintext broadcast frame during 4-way HS (use tcpdump).
| `eapfrag BP,BP` | Experimental broadcast fragment attack (use tcpdump).
| <div align="center">*[A-MSDUs EAPOL attack (§6.5)](#id-extended-cloackamsdu)*</div>
| <div align="center">*[A-MSDU EAPOL attack (§6.5)](#id-extended-cloackamsdu)*</div>
| `eapol-amsdu[-bad] BP --bcast-dst` | Same as `eapol-amsdu BP` but easier to verify against APs (use tcpdump).
| <div align="center">*[AP forwards EAPOL attack (§6.6)](#id-extended-apforward)*</div>
| `eapol-inject 00:11:22:33:44:55` | Test if AP forwards EAPOL frames before authenticated (use tcpdump).
@ -572,35 +587,38 @@ these alternative mixed key attack tests. Some remarks:
Finally, in case the test `ping-frag-sep` doesn't succeed, you should try the following mixed key attack test:
- `ping I,F,BE,AE --freebsd`: This essentially performs the rekey handshake against a FreeBSD implementation or
driver without affecting the defragmentation process of data frames. See Appendix F in the paper for details.
- `ping I,F,BE,AE --freebsd`: This essentially performs the rekey handshake against a FreeBSD implementation, or
a driver that borrows code from FreeBSD, without affecting the defragmentation process of data frames. See
Appendix F in the paper for details.
<a id="id-extended-cache"></a>
## 8.3. Cache attack tests (§5 -- CVE-2020-24586)
- `ping I,E,R,AE --freebsd --full-reconnect`: This test can be used to check if a FreeBSD AP, or an implementation
based on FreeBSD drivers, is vulnerable to a cache attack. See Appendix F in the paper for details on how this
test works. You should also try this test without the `--full-reconnect` parameter.
- `ping I,E,R,AE --freebsd --full-reconnect`: This test can be used to check if a FreeBSD AP, or a driver that
borrows code from FreeBSD, is vulnerable to a cache attack. See Appendix F in the paper for details on how this
test works. You should also try this test without the `--full-reconnect` parameter. The test also works against
clients, but these are unlikely to be affected.
- `ping I,E,R,AP --freebsd --full-reconnect`: This test is a variant against FreeBSD APs, or an implementation based
on FreeBSD drivers, where the second fragment is sent in plaintext after reconnecting with the AP. Against some
- `ping I,E,R,AP --freebsd --full-reconnect`: This test is a variant against FreeBSD APs, or against a driver that
borrows code from FreeBSD, where the second fragment is sent in plaintext after reconnecting with the AP. Against some
dongles on FreeBSD this test was more reliable and still proves that old fragments remain in the AP's memory after
reconnecting. You should also try this test without the `--full-reconnect` parameter.
reconnecting. You should also try this test without the `--full-reconnect` parameter. The test also works against
clients, but these are unlikely to be affected.
- `ping I,E,R,AP [--full-reconnect]`: In this test the second fragment is sent in plaintext. This can be useful if
the device being tested doesn't immediately install the key after the 4-way handshake. If this tests succeeds, it
shows that the device keeps fragments in memory after (re)connecting to a network, meaning its vulnerable to cache
attacks.
attacks. Unlike the above two commands, this one is also useful to perform against clients (as well as APs).
<a id="id-extended-mixplainenc"></a>
## 8.4. Mixed plain/encrypt attack (§6.3 -- CVE-2020-26147)
- `ping I,E,E --amsdu`: This test sends a fragmented A-MSDU frame, which not all devices can properly receive.
This test is useful to determine the practical exploitability of the "Mixed plain/encrypt attack".
Summarized, if this tests succeeds, it is easier to attack the device if the second fragment can be sent
Summarized, if this tests succeeds, it's easier to attack the device if the second fragment can be sent
in plaintext (test `ping I,E,P`). See Section 6.3 of the paper for details.
- `ping I,E,P,E` and `linux-plain 3`: If all the other mixed plain/encrypt attack tests in didn't succeed, you
- `ping I,E,P,E` and `linux-plain 3`: If all the other mixed plain/encrypt attack tests didn't succeed, you
can try these two extra tests as well. I think it's quite unlikely this will uncover a new vulnerability.
<a id="id-extended-bcast-check"></a>
@ -656,12 +674,12 @@ command, and listen for broadcast Wi-Fi frames on a second device that is connec
<a id="id-extended-nofrag"></a>
## 8.8. No fragmentation support attack test (§6.8 -- CVE-2020-26142)
- `ping I,D,E`: If this test succeeds, the device doesn't support (de)fragmentation, but is still vulnerable to attacks. The
problem is that the receiver treats the _last_ fragment as a full frame. See Section 6.6 in the paper for details and how this
can be exploited.
- `ping I,D,E`: If this test succeeds, the client or AP doesn't support (de)fragmentation, but is still vulnerable to attacks.
The problem is that the receiver treats the _last_ fragment as a full frame. See Section 6.6 in the paper for details and how
this can be exploited.
- `ping I,E,D`: If this test succeeds, then the devices treats the _first_ fragment as a full frame. Although this behaviour is
not ideal, it's currently unknown whether this, on its own, can be exploited in practice.
- `ping I,E,D`: If this test succeeds, then the client or AP treats the _first_ fragment as a full frame. Although this behaviour
is not ideal, it's currently unknown whether this, on its own, can be exploited in practice.
# 9. Advanced Usage

2
research/SUMMARY.md
View File

@ -16,7 +16,7 @@
- **CVE-2020-26145: 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 arbitrary network packets independent of the network configuration.
- **CVE-2020-26144: 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.
- **CVE-2020-26144: Accepting plaintext A-MSDU frames that start with an RFC1042 header with EtherType EAPOL (in an encrypted network)**: Vulnerable Wi-Fi implementations accept plaintext A-MSDU frames as long as the first 8 bytes correspond to a valid RFC1042 (i.e., LLC/SNAP) header for EAPOL. An adversary can abuse this to inject arbitrary network packets independent of the network configuration.
## Other Implementation Vulnerabilities