RocketSlack/2017-1/wpa-packet-number-reuse-with-replayed-messages.txt

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