A Technical Overview
Recently, the news has been full of highly publicized but often misunderstood, vulnerabilities affecting a range of devices and protocols. It seems as if critical vulnerabilities are popping up everywhere and it’s getting harder and harder to maintain a secure footprint. Within the past few weeks, several vulnerabilities affecting wireless protocols have been released; including one affecting the industry standard wireless networking protocol, WPA2. While most vulnerabilities are restricted to a single platform, application, or device, vulnerabilities identified in the underlying protocols supporting those devices have far wider implications.
Key Reinstallation AttaCK (KRACK) is a replay attack on Wi-Fi Protected Access v2 (WPA2), a security protocol for wireless connections. The specific mechanism by which an individual wireless device may be vulnerable will vary. However, all wireless devices, including laptops, phones, wireless access points, and “Internet of Things” (IoT) devices, are potentially affected by this vulnerability. This is because the specific implementation of the IEEE 802.11 specification varies by manufacturer and device. This specification does not include requirements for every condition in the wireless handshake process thereby leaving some room for variation in manufacturers’ implementation of the standard.
The attack abuses design and implementation flaws in the WPA2 protocol to reinstall a key that is already in use. By doing this, the key’s associated parameters (including transmit nonces and receive replay counters) are reset. This attack affects the “handshake,” which is the process by which a wireless client connects to a wireless access point. Most wireless access points are vulnerable to this attack — while Android and Linux are at a greater risk. This is due to wpa_supplicant versions 2.4 and 2.5, which are commonly found as a Wi-Fi client on Linux. Since Android 6.0 and Android Wear 2.0 are using modified wpa_supplicant, they are also at risk.
All WPA2 Wi-Fi networks use a “handshake” to retrieve fresh session keys, which are used to encrypt traffic sent “over-the-air.” An attacker can trick a user into reinstalling a key that is already in use by manipulating and replaying handshake messages. When the key is reinstalled, they receive a packet number (replay counter) and the incremental transmit packet number (nonce) is reset to their starting value. The impact of the attack depends on which type of handshake is being attacked and also what data confidentiality protocol is in use. Against WPA-TKIP and GCMP, the impact is much more severe than against AES-CCMP. While an attacker can replay and decrypt packets using AES-CCMP, WPA-TKIP and GCMP packets can be replayed, decrypted, and forged.
The vulnerability and associated attack method was developed by Mathy Vanhoef and Frank Piessens from imec DistriNet, KU Leuven Belgium. Vanhoef and Piessens summarize their attack as follows:
“When a client joins a network, it executes the 4-way handshake to negotiate a fresh session key. It will install this key after receiving message 3 of the handshake. Once the key is installed, it will be used to encrypt normal data frames using a data-confidentiality protocol. However, because messages may be lost or dropped, the Access Point (AP) will retransmit message 3 if it did not receive an appropriate response as acknowledgment. As a result, the client may receive message 3 multiple times. Each time it receives this message, it will reinstall the same session key, and thereby reset the incremental transmit packet number (nonce) and receive replay counter used by the data-confidentiality protocol.”
In summary, the KRACK vulnerability can lead to unauthorized disclosure of information, as well as unauthorized network access, depending on the specific parameters of the device being exploited. To mitigate the risk associated with Key Reinstallation Attack, the problem must be addressed at layer 2 of the OSI model (data-link). Since this attack depends on the resets of both nonces and replay counters, the device implementing the data-confidentiality protocol must check if the key being installed is already in use. This check is not enforced by all devices implementing WPA2, leaving some devices vulnerable. Because the vulnerability affects the underlying protocol and not a specific device or implementation, it’s crucial to check with the vendors of your wireless hardware to determine the actual exposure and remediation methods.
The KRACK vulnerability is highly technical in nature and requires extensive knowledge of the WPA2 protocol for successful exploitation. Even though there are no “fire-and-forget” exploits yet available for KRACK, it is only a matter of time before this type of exploit is made available. As such, due to the potential impact associated with exploitation of the vulnerability, it is recommended to apply vendor-supplied patches to all wireless hardware as soon as possible.
For more information see Vanhoef and Piessens paper: Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2 (https://papers.mathyvanhoef.com/ccs2017.pdf)
