diff options
Diffstat (limited to 'source/n/wpa_supplicant/2017-1/wpa-packet-number-reuse-with-replayed-messages.txt')
| -rw-r--r-- | source/n/wpa_supplicant/2017-1/wpa-packet-number-reuse-with-replayed-messages.txt | 226 |
1 files changed, 0 insertions, 226 deletions
diff --git a/source/n/wpa_supplicant/2017-1/wpa-packet-number-reuse-with-replayed-messages.txt b/source/n/wpa_supplicant/2017-1/wpa-packet-number-reuse-with-replayed-messages.txt deleted file mode 100644 index 5ccb5098..00000000 --- a/source/n/wpa_supplicant/2017-1/wpa-packet-number-reuse-with-replayed-messages.txt +++ /dev/null @@ -1,226 +0,0 @@ -WPA packet number reuse with replayed messages and key reinstallation - -Published: October 16, 2017 -Identifiers: -- CERT case ID: VU#228519 -- CVE-2017-13077 -- CVE-2017-13078 -- CVE-2017-13079 -- CVE-2017-13080 -- CVE-2017-13081 -- CVE-2017-13082 -- CVE-2017-13084 (not applicable) -- CVE-2017-13086 -- CVE-2017-13087 -- CVE-2017-13088 -Latest version available from: https://w1.fi/security/2017-1/ - - -Vulnerability - -A vulnerability was found in how a number of implementations can be -triggered to reconfigure WPA/WPA2/RSN keys (TK, GTK, or IGTK) by -replaying a specific frame that is used to manage the keys. Such -reinstallation of the encryption key can result in two different types -of vulnerabilities: disabling replay protection and significantly -reducing the security of encryption to the point of allowing frames to -be decrypted or some parts of the keys to be determined by an attacker -depending on which cipher is used. - -This document focuses on the cases that apply to systems using hostapd -(AP) or wpa_supplicant (station), but it should be noted that the -generic vulnerability itself is applicable to other implementations and -may have different impact in other cases. - -This vulnerability can in theory apply to any case where a TK (the -pairwise/unicast encryption key used with TKIP, CCMP, GCMP), a GTK -(group/multicast encryption key), or an IGTK (group management frame -integrity protection key) is configured by the Authentication/Supplicant -component to the WLAN driver/firmware taking care of the TX/RX path and -encryption/decryption of frames. - -If the same key is configured multiple times, it is likely that the -transmit and receive packet numbers (PN, IPN, RSC/TSC, etc.) are cleared -to a smaller value (zero in case of pairwise keys, zero or at least a -smaller value than the last used value in case of group keys). When this -happens with the same key, this breaks replay protection on RX side and -can result in reuse of packet numbers on TX side. The former may allow -replaying of previously delivered packets (without the attacker being -able to decrypt them or modify their contents) while the latter may -result in more severe issues on the TX side due to resulting CCM nonce -replay and related issues with GCMP and TKIP. The TX side issue may make -it significantly easier for the attacker to decrypt frames and determine -some parts of the keys (e.g., a Michael MIC key in case of TKIP). - -Impact on AP/hostapd - -On the AP side, this generic issue has been determined to be applicable -in the case where hostapd is used to operate an RSN/WPA2 network with FT -(Fast BSS Transition from IEEE 802.11r) enabled. Replaying of the -Reassociation Request frame can be used to get the AP reinstalling the -TK which results in the AP accepting previously delivered unicast frames -from the station and the AP reusing previously used packet numbers -(local TX packet number gets reset to zero). This latter issue on the TX -side can result in CCM nonce reuse which invalidates CCMP security -properties. In case of TKIP this can result in the attacker being able -to determine part of the TK more easily and with GCMP, result in similar -issues. - -It should be noted that the AP side issue with FT would be close to -applying to FILS authentication (from IEEE 802.11ai) in hostapd with -replaying of (Re)Association Request frames. However, due to a different -handling of the repeated association processing with FILS, this would -actually result in the station getting immediately disconnected which -prevents this attack in practice. In addition, the FILS implementation -in the current hostapd version is still experimental and documented as -being discouraged in production use cases. - -Another area of potentially reduced security was identified when looking -into these issues. When AP/Authenticator implementation in hostapd is -requested to rekey the PTK without performing EAP reauthentication -(either through local periodic rekeying or due to a request from an -association station), the ANonce value does not get updated. This -results in the new 4-way handshake depending on the station/supplicant -side generating a new, unique (for the current PMK/PSK) SNonce for the -PTK derivation to result in a new key. While a properly working -supplicant would do so, if there is a supplicant implementation that -does not, this combination could result in deriving the same PTK -again. When the TK from that PTK gets configured in the driver, this -would result in reinstalling the same key and the same issues as -described above for the FT protocol case. - -Impact on station/wpa_supplicant - -On the station side, this generic issue has been determined to be -applicable in the cases where wpa_supplicant processes a group key (GTK -or IGTK) update from the AP. An attacker that is able to limit access -to frame delivery may be able to extract two update messages and deliver -those to the station with significant time delay between them. When -wpa_supplicant processes the second message, it may end up reinstalling -the same key to the driver and when doing this, clear the RX packet -number to an old value. This would allow the attacker to replay all -group-addressed frames that the AP sent between the time the key update -message was originally sent and the time when the attacker forwarded the -second frame to the station. The attacker would not be able to decrypt -or modify the frames based on this vulnerability, though. There is an -exception to this with older wpa_supplicant versions as noted below in -version specific notes. - -For the current wpa_supplicant version (v2.6), there is also an -additional EAPOL-Key replay sequence where an additional forged -EAPOL-Key message can be used to bypass the existing protection for the -pairwise key reconfiguration in a manner that ends up configuring a -known TK that an attacker could use to decrypt any frame sent by the -station and to inject arbitrary unicast frames. Similar issues are -reachable in older versions as noted below. - -PeerKey / TDLS PeerKey - -As far as the related CVE-2017-13084 (reinstallation of the STK key in -the PeerKey handshake) is concerned, it should be noted that PeerKey -implementation in wpa_supplicant is not fully functional and the actual -installation of the key into the driver does not work. As such, this -item is not applicable in practice. Furthermore, the PeerKey handshake -for IEEE 802.11e DLS is obsolete and not known to have been deployed. - -As far as the TDLS PeerKey handshake is concerned (CVE-2017-13086), -wpa_supplicant implementation is already rejecting TPK M2 retries, so -the reconfiguration issue cannot apply for it. For TPK M3, there is a -theoretical impact. However, if that frame is replayed, the current -wpa_supplicant implementation ends up tearing down the TDLS link -immediately and as such, there is no real window for performing the -attack. Furthermore, TPK M3 goes through the AP path and if RSN is used -there, that frame has replay protection, so the attacker could not -perform the attack. If the AP path were to use WEP, the frame could be -replayed, though. That said, if WEP is used on the AP path, it would be -fair to assume that there is no security in the network, so a new attack -vector would be of small additional value. - -With older wpa_supplicant versions, it may be possible for an attacker -to cause TPK M2 to be retransmitted with delay that would be able to -trigger reinstallation of TK on the peer receiving TPK M2 -(CVE-2017-13086). This may open a short window for the attack with v2.3, -v2.4, and v2.5; and a longer window with older versions. - -Vulnerable versions/configurations - -For the AP/Authenticator TK (unicast) reinstallation in FT protocol -(CVE-2017-13082): - -hostapd v0.7.2 and newer with FT enabled (i.e., practically all versions -that include full FT implementation). FT needs to be enabled in the -runtime configuration to make this applicable. - -For the AP/Authenticator missing ANonce during PTK rekeying: - -All hostapd versions. - -For the station/Supplicant side GTK/IGTK reinstallation and TK -configuration: - -All wpa_supplicant versions. The impact on older versions can be more -severe due to earlier changes in this area: v2.3 and older can also -reinstall the pairwise key and as such have similar impact as the AP FT -case (CVE-2017-13077); v2.4 and v2.5 end up configuring an all-zero TK -which breaks the normal data path, but could allow an attacker to -decrypt all following frames from the station and to inject arbitrary -frames to the station. In addition, a different message sequence -involving 4-way handshake can result in configuration of an all-zero TK -in v2.6 and the current snapshot of the development repository as of the -publication of this advisory. - - -Acknowledgments - -Thanks to Mathy Vanhoef of the imec-DistriNet research group of KU -Leuven for discovering and reporting this issue. Thanks to John A. Van -Boxtel for finding additional issues related to this topic. - - -Possible mitigation steps - -- For AP/hostapd and FT replay issue (CVE-2017-13082), it is possible to - prevent the issue temporarily by disabling FT in runtime - configuration, if needed before being able to update the - implementations. - -- Merge the following commits to hostapd/wpa_supplicant and rebuild them: - - hostapd and replayed FT reassociation request frame (CVE-2017-13082): - hostapd: Avoid key reinstallation in FT handshake - - hostapd PTK rekeying and ANonce update: - Fix PTK rekeying to generate a new ANonce - - wpa_supplicant and GTK/IGTK rekeying (CVE-2017-13078, CVE-2017-13079, - CVE-2017-13080, CVE-2017-13081, CVE-2017-13087, CVE-2017-13088): - Prevent reinstallation of an already in-use group key - Extend protection of GTK/IGTK reinstallation of WNM-Sleep Mode cases - - wpa_supplicant (v2.6 or newer snapshot) and known TK issue: - Prevent installation of an all-zero TK - - Additional protection steps for wpa_supplicant: - TDLS: Reject TPK-TK reconfiguration - WNM: Ignore WNM-Sleep Mode Response without pending request - FT: Do not allow multiple Reassociation Response frames - - These patches are available from https://w1.fi/security/2017-1/ - (both against the snapshot of hostap.git master branch and rebased on - top of the v2.6 release) - - For the TDLS TPK M2 retransmission issue (CVE-2017-13086) with older - wpa_supplicant versions, consider updating to the latest version or - merge in a commit that is present in v2.6: - https://w1.fi/cgit/hostap/commit/?id=dabdef9e048b17b22b1c025ad592922eab30dda8 - ('TDLS: Ignore incoming TDLS Setup Response retries') - -- Update to hostapd/wpa_supplicant v2.7 or newer, once available - * it should be noted that there are number of additional changes in - the related areas of the implementation to provide extra layer of - protection for potential unknown issues; these changes are not - included in this advisory as they have not been identified to be - critical for preventing any of the identified security - vulnerabilities; however, users of hostapd/wpa_supplicant are - encouraged to consider merging such changes even if not fully - moving to v2.7 |