From 30ac30c8e65d0fdeabb65b07f37b1ff1e363b23f Mon Sep 17 00:00:00 2001 From: Mathy Vanhoef Date: Sat, 22 Aug 2020 00:58:13 +0400 Subject: [PATCH] fragattack: add CVEs --- research/README.md | 12 ++++++------ research/SUMMARY.md | 6 +++--- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/research/README.md b/research/README.md index 8ae7892e9..122ee025c 100644 --- a/research/README.md +++ b/research/README.md @@ -284,14 +284,14 @@ 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. -## 7.2. A-MSDU attack tests (§3) +## 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 attacks. To prevent attacks, the network must mandate the usage of SSP A-MSDUs (and drop all non-SSP A-MSDUs). It's currently unclear how to prevent this attack in a backward-compatible manner. See Section 3 of the paper for details. -## 7.3. Mixed key attack tests (§4) +## 7.3. 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) renew the session key (PTK) by executing a new 4-way handshake. The tool will display @@ -312,7 +312,7 @@ for details. succeed or not. In case the tests fail, it is recommended to also perform the mixed key attack tests listed in [Extended Vulnerability Tests](#id-extended-tests). -## 7.4. Cache attack tests (§5) +## 7.4. 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 sends the second fragment. However, not all APs properly support the reassociation process. In that case, @@ -464,7 +464,7 @@ presence of a certain vulnerability class, there is no need to test the other at |
*A-MSDUs EAPOL attack (§6.8)*
| `eapol-amsdu[-bad] BP --bcast-dst` | Same as `eapol-amsdu BP` but easier to verify against APs (use tcpdump). -## 8.1. A-MSDU attack tests (§3) +## 8.1. A-MSDU attack tests (§3 -- CVE-2020-24588) It is only useful to execute the first two tests if the main test `ping I,E --amsdu` fails and you want to better understand how the tested device handles A-MSDU frames: @@ -488,7 +488,7 @@ The last two tests are used to simulate our A-MSDU injection attack: above test to fail. In that case try `amsdu-inject-bad` instead (see Section 3.6 in the paper). Note that if this tests succeeds, the impact of the attack is effectively identical to implementations that correctly parse such frames. -## 8.2. Mixed key attack tests (§4) +## 8.2. Mixed key attack tests (§4 -- CVE-2020-24587) Most devices I tested are vulnerable to mixed key attacks. In case the normal mixed key attack tests indicate that a device is not vulnerable, but the test `ping-frag-sep` does succeed, it is highly recommended to try @@ -515,7 +515,7 @@ Finally, in case the test `ping-frag-sep` doesn't succeed, you should try the fo - `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. -## 8.3. Cache attack tests (§5) +## 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 diff --git a/research/SUMMARY.md b/research/SUMMARY.md index 223edd340..39a527a24 100644 --- a/research/SUMMARY.md +++ b/research/SUMMARY.md @@ -4,11 +4,11 @@ This document contains a summary of the discovered vulnerabilities. ## Design Flaws -- **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-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. -- **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 decrypt selected fragments when another device sends fragmented frames and the WEP, CCMP, or GCMP encryption key is periodically renewed. -- **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 decrypt user data. ## Common Implementation Vulnerabilities