fragattack: clarify fragmented ping test sanity check

This commit is contained in:
Mathy Vanhoef 2021-01-22 05:14:37 +04:00
parent 40d19275c8
commit 7eb3596f07

View File

@ -321,7 +321,7 @@ device and are further discussed below the table.
| <div align="center">*[Sanity checks](#id-test-sanity)*</div> | <div align="center">*[Sanity checks](#id-test-sanity)*</div>
| `ping` | Send a normal ping. | `ping` | Send a normal ping.
| `ping I,E,E` | Send a normal fragmented ping. | `ping I,E,E` | Send a normal fragmented ping.
| <div align="center">*[Basic device behaviour](#id-test-sanity)*</div> | <div align="center">*[Basic device behaviour](#id-test-behaviour)*</div>
| `ping I,E,E --delay 5` | Send a normal fragmented ping with a 5 second delay between fragments. | `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` | 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. | `ping-frag-sep --pn-per-qos` | Same as above, but also works if the target only accepts consecutive PNs.
@ -360,11 +360,16 @@ receives a unique CVE for each affected codebase. We nevertheless recommend to a
include) these reference CVEs as a way to easily refer to each type of discovered implementation flaw. include) these reference CVEs as a way to easily refer to each type of discovered implementation flaw.
<a id="id-test-sanity"></a> <a id="id-test-sanity"></a>
## 7.1. Sanity and implementation checks ## 7.1. Sanity checks
- `ping I,E,E`: This test should only fail if the tested device doesn't support fragmentation. In case - `ping`: This test must always succeed. If it fails, something is wrong with the test setup.
you encounter this, it is recommended to also run this test against a device that _does_ support
fragmentation to assure the test tool is properly injecting fragmented frames. - `ping I,E,E`: This test should succeed against all modern laptops, smartphones, and APs. If it fails,
something is wrong with the test setup. This test only fails if the tested device doesn't support receiving
fragmented frames, which can be the case on lightweight IoT devices and, for example, OpenBSD.
<a id="id-test-behaviour"></a>
## 7.2. Basic device behaviour
- `ping I,E,E --delay 5`: This test is used to check the maximum accepted delay between two fragments. - `ping I,E,E --delay 5`: This test is used to check the maximum accepted delay between two fragments.
If this test doesn't work, try it again with `--delay 1.5` or lower. For instance, Linux removes fragments If this test doesn't work, try it again with `--delay 1.5` or lower. For instance, Linux removes fragments
@ -384,7 +389,7 @@ include) these reference CVEs as a way to easily refer to each type of discovere
secure. Unfortunately, many implementations don't verify whether PNs are consecutive. secure. Unfortunately, many implementations don't verify whether PNs are consecutive.
<a id="id-test-amsdu"></a> <a id="id-test-amsdu"></a>
## 7.2. A-MSDU attack tests (§3 -- CVE-2020-24588) ## 7.3. A-MSDU attack tests (§3 -- CVE-2020-24588)
The test `ping I,E --amsdu` checks if an implementation supports non-SPP A-MSDUs, in which case it is likely The test `ping I,E --amsdu` checks if an implementation supports non-SPP A-MSDUs, in which case it is likely
vulnerable to one of the below two attacks. To prevent attacks, ideally the network must mandate the usage of vulnerable to one of the below two attacks. To prevent attacks, ideally the network must mandate the usage of
@ -402,7 +407,7 @@ The last two tests are used to simulate our A-MSDU injection attack:
succeeds, the impact of the attack is effectively identical to implementations that correctly parse such frames. succeeds, the impact of the attack is effectively identical to implementations that correctly parse such frames.
<a id="id-test-mixedkey"></a> <a id="id-test-mixedkey"></a>
## 7.3. Mixed key attack tests (§4 -- CVE-2020-24587) ## 7.4. Mixed key attack tests (§4 -- CVE-2020-24587)
- When running the mixed key test against an AP, the AP must be configured to regularly (e.g. every minute) - When running the mixed key test against an AP, the AP must be configured to regularly (e.g. every minute)
renew the session key (PTK) by executing a new 4-way handshake. The tool will display renew the session key (PTK) by executing a new 4-way handshake. The tool will display
@ -425,7 +430,7 @@ The last two tests are used to simulate our A-MSDU injection attack:
tests listed in [Extended Vulnerability Tests](#id-extended-tests). tests listed in [Extended Vulnerability Tests](#id-extended-tests).
<a id="id-test-cache"></a> <a id="id-test-cache"></a>
## 7.4. Cache attack tests (§5 -- CVE-2020-24586) ## 7.5. Cache attack tests (§5 -- CVE-2020-24586)
- When testing an AP, the tool sends a first fragment, then tries to _reassociate_ with the AP, and finally - When testing an AP, the tool sends a first fragment, then tries to _reassociate_ with the AP, and finally
sends the second fragment. However, not all APs properly support the reassociation process. In that case, sends the second fragment. However, not all APs properly support the reassociation process. In that case,
@ -456,12 +461,12 @@ The last two tests are used to simulate our A-MSDU injection attack:
is similar to knowing an implementation has a buffer overflow but not (yet) knowing how to exploit it. is similar to knowing an implementation has a buffer overflow but not (yet) knowing how to exploit it.
<a id="id-test-nonconsec"></a> <a id="id-test-nonconsec"></a>
## 7.5. Non-consecutive PNs attack (§6.2 -- CVE-2020-26146) ## 7.6. Non-consecutive PNs attack (§6.2 -- CVE-2020-26146)
In our experiments, this test only failed against Linux and against devices that don't support fragmentation. In our experiments, this test only failed against Linux and against devices that don't support fragmentation.
<a id="id-test-mixplainenc"></a> <a id="id-test-mixplainenc"></a>
## 7.6. Mixed plain/encrypt attack (§6.3 -- CVE-2020-26147/26140/26143) ## 7.7. Mixed plain/encrypt attack (§6.3 -- CVE-2020-26147/26140/26143)
- `ping I,E,P` and `linux-plain`: if this test succeeds the resulting attacks are described in Section 6.3 - `ping I,E,P` and `linux-plain`: if this test succeeds the resulting attacks are described in Section 6.3
of the paper. Summarized, in combintation with the A-MSDU or cache vulnerability, it can be exploited to of the paper. Summarized, in combintation with the A-MSDU or cache vulnerability, it can be exploited to
@ -478,7 +483,7 @@ In our experiments, this test only failed against Linux and against devices that
Wi-Fi network, allowing trivial packet injection (CVE-2020-26143). Wi-Fi network, allowing trivial packet injection (CVE-2020-26143).
<a id="id-test-broadcastfrag"></a> <a id="id-test-broadcastfrag"></a>
## 7.7. Broadcast fragment attack tests (§6.4 -- CVE-2020-26145) ## 7.8. Broadcast fragment attack tests (§6.4 -- CVE-2020-26145)
The following two tests send broadcast frames, which are not automatically retransmitted, and it is therefore The following two tests send broadcast frames, which are not automatically retransmitted, and it is therefore
recommended to **execute them 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
@ -496,7 +501,7 @@ from receiving the injected broadcast frame:
mainly clients were affected. mainly clients were affected.
<a id="id-test-cloackamsdu"></a> <a id="id-test-cloackamsdu"></a>
## 7.8. A-MSDU EAPOL attack tests (§6.5 -- CVE-2020-26144) ## 7.9. 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 - `eapol-amsdu I,P`: This is the standard test for the implementation-specific vulnerability discussed in
Section 6.5 of the paper. Both clients and APs can be vulnerable. Its result is checked automatically by Section 6.5 of the paper. Both clients and APs can be vulnerable. Its result is checked automatically by
@ -514,7 +519,7 @@ from receiving the injected broadcast frame:
of the attack is identical to implementations that correctly parse such frames (for details see Section 3.6 and of the attack is identical to implementations that correctly parse such frames (for details see Section 3.6 and
6.8 in the paper). 6.8 in the paper).
## 7.9. Troubleshooting checklist ## 7.10. Troubleshooting checklist
In case the test tool doesn't appear to be working, check the following: In case the test tool doesn't appear to be working, check the following: