Mathy Vanhoefm published a set of attacks against the Wi-Fi security protocol WPA2 with the name Key Reinstallation Attacks, or KRACKS.
Last Monday, October 16th, Mathy Vanhoefm published a set of attacks against the Wi-Fi security protocol WPA2 with the name Key Reinstallation Attacks, or KRACKS. Almost immediately, the infosec community reacted and we started to read about how “WPA2 got broken”. Then the official webpage and paper were released, and we were able to start to technically analyse the problem and its implications. In this blog post, we will try to summarize our conclusions about this attack.
One of the things we found to be lacking the most is clarification on the context or scenario in which this set of attacks took place. This is important in order to comprehend the impact and technical complexity needed to exploit the vulnerabilities.
So, let’s give context. In KRACK, the goal is to decrypt, manipulate and/or replay packets being sent over a Wi-Fi network for which the attacker doesn’t know the password. For this to work, there are several limitations.
Firstly, the attacker needs to be within Wi-Fi range (this is a Wi-Fi attack, after all), which requires physical proximity to the target. Secondly, for some of the attacks to work, the attacker needs to establish himself as a Man in the Middle between the client and the Access Point (AP). Now, this does not mean that the attacker is able to passively decrypt all communications, he just needs the ability to decide when to pass packets around, when to delay them and when to completely block them. Keep in mind that WPA2 is encrypting these packets, so even in a MitM position, an attacker cannot read them without the proper keys. Thirdly, the impact depends greatly on the encryption protocol used in the network, the specific client and AP implementations and the handshake being attacked.
These context and limitations must be taken into account at all times when trying to weigh the severity and implications of the attacks.
The main idea behind KRACK lies in Key Reinstallation, as the name suggests. The attacks target the different handshakes performed in WPA2 to protect information confidentiality and integrity; and such handshakes, at one moment or another, derive symmetric cryptographic keys that are installed in both the client and the AP and are used from that point on to protect communications.
This protection relies on the AES cipher in Counter mode, which basically means packets are ciphered via a stream cipher. Technical details aside, the most important thing in a stream cipher to ensure authentication and confidentiality is never to repeat nonces (arbitrary random values used to create the keystream) for the same key. If a nonce is repeated, the security of the cipher is compromised.
With this, the author of KRACKS had an initially simple idea: what if the same key was to be installed multiple times? And the answer is, apparently, also simple: the key would remain unchanged, but the nonces would be reset as if a new key had been installed, because that’s what the standard specifies. That means that, for every packet sent between the first key installation and the second, a nonce will be repeated, and that package can therefore be decrypted”¦ without knowing the originally used key!
Now, the standard is formally proven secure! There is no way it can allow for this to happen, right? Well, it is specified that messages can be retransmitted in case of packet loss because of background noise or other causes, and this includes the key installation messages. So, standard in hand, clients and AP should support installing a new key if the other part resends the message that instructs it to do so, even when a key is already installed. What is not specified in the standard is what to do when the same key that is already installed is retransmitted for installation again. It is that little window of “freedom” in the implementation that creates the vulnerability: reinstalling the currently installed key is effectively the same as resetting the nonces without changing the key.
There it is.
Every one of the four handshakes used in WPA2 (4-way Handshake, Group Handshake, PeerKey Handshake and Fast BSS Transition Handshake) are attacked with KRACK and vulnerable in varying degrees depending on encryption protocols and implementations used.
Among the attacks against 4-way Handshake, Group Handshake and PeerKey Handshake target client implementations, the most impactful of them is probably the 4-way Handshake. This attack focuses on forcing reinstallation of the Pairwise Transient Key (PTK), which is derived from the Pairwise Master Key (PMK, directly calculated from the WPA2 pre-shared password), the Authenticator Nonce (ANonce, a random value calculated by the AP), the Supplicant Nonce (SNonce, a random value calculated by the client) and the MAC addresses of the client and the AP.
In this attack, the adversary must be in a MitM position and also spoof the MAC address of the AP (in order not to interfere with the PTK derivation as seen above), which requires a certain degree of technical ability and tooling. Once in this situation, the attacker can let the 4-way handshake happen: after the nonces are sent, the AP sends the Group Temporal Key (GTK) to the client, which also instructs it to install the derived PTK.
The attacker can now block the confirmation the client sends to the AP after successfully installing the PTK, making the AP believe its previous message was not received, and so sending it again. After giving some time to the client to start sending encrypted data and using nonces (take into account that the client is not aware of AP not receiving the confirmation), the attacker can now let the retransmission of the AP’s GTK message reach the client. In this situation, the client, following the standard, must reinstall the PTK, but since neither the PMK, the ANonce, the SNonce or the MAC addresses have changed, the derived PTK is the same. So, the PTK is reinstalled, the nonces are reset, and encrypted data is sent again. The attacker can now decrypt every packet ciphered with a repeated nonce.
There are several complications that can appear depending on the implementation, but this is the main idea behind the attack. For further technical details, please refer to the official paper, which is wonderfully explained.
Aside from the repeating nonces vulnerability, which would allow for packet decryption and/or replay (and, depending on the encryption protocol, even forging), another, more impactful bug was found by the author when testing the client implementations of Android 6.0 and wpa_supplicant (a popular Linux Wi-Fi client) 2.4 and above.
The bug is reproduced in every reinstallation of the PTK, even those that could occur naturally when a message is lost due to, for example, background noise. These specific implementations cleanse the PTK from memory immediately after installing it, and so, when instructed to perform a reinstallation, they end up installing an all-zero PTK (!). This allows the attacker to easily predict the key being used by the client, thus gaining full control over the packets sent by it.
As can be seen, this is not a problem with the protocol itself (though it is in fact suggested that PTK should be removed from memory after installation) but a straightforward implementation error, with a rather severe impact.
As we said previously, the exact implications depend on:
All attacks allow for packet replay, the direction of which depends on the target (it goes from the AP to the client if the client is being targeted and vice-versa), while the attack against the 4-way Handshake allows for decrypting packets sent by the client to the AP, and the attack against FT Handshake (targeted on the AP) allows for decrypting packets sent by the AP to the client. This makes sense, because the entity that is reinstalling the key is the one resetting nonces, thus accepting replayed packets with previous nonces, on the one hand; and sending packets ciphered with repeated nonces, on the other hand.
Apart from the All-Zero Key bug (see above), forging packets is only possible when TKIP or GCMP are used. With TKIP, a different Message Integrity Check (MIC) key is used for each client and the AP. Because of that, and the fact that only the MIC key of the entity being targeted is recoverable, packets can only be forged in one direction. In the case of GCMP, though, the full authentication key is recoverable, thus allowing for forging packets in both directions.
Regarding client implementations, there is a special case in Windows and iOS clients. These specific implementations actually ignore part of the standard and do not allow for key reinstallation, and because of that they are not vulnerable to the 4-way Handshake or the PeerKey Hanshake attacks, only the Group Key Handshake one, and thus they are only vulnerable to replayed packets. The rest of clients are vulnerable to packet decryption via the 4-way Handshake attack, at least.
Finally, all AP implementations are vulnerable to the FT Handshake attack, except OpenBSD clients. This is due to the fact that this is the only client that has both a strict Replay Check and delays GTK installation to after receiving client confirmation of the GTK being installed at its side. There are ways of circumventing one of these cases, but not both (see the paper for details).
To summarize:
Take into account that even if your device is not affected by one of the attacks, if other devices on the network are vulnerable your communications could be impacted too (e.g. a Windows client communicating with a vulnerable AP).
Patches are being developed and released as we write these lines. The main correction applied by these patches will be not to r
einstalling keys if they are the same as those that are currently installed, which completely solves the vulnerability exploited by these attacks. We recommend installing the patch as soon as your device has it available.
Until then, several measures can be put in place to increase protection against KRACK. The most straightforward of them is, obviously, not using Wi-Fi. Wired connections are completely unaffected by these attacks. When this is not an option, consider securing your communications in additional ways.
Even if WPA2 is broken by KRACK, if you are using secure protocols such as VPN, SSH or HTTPS, your connections will still remain secure (unless these protocols are also broken by using additional attacks, which is significantly harder to do).
Another preventive option would be deploying a Wi-Fi Intrusion Prevention System (WIPS) in order to detect and stop the MAC Spoofing necessary to clone the AP and perform the MitM technique as explained above. Without this ability, the options of the attacker are significantly reduced.
As we have seen above, KRACKS is a very real attack against WPA2 which can compromise the confidentiality and integrity of packets sent over a secured Wi-Fi. That said, we think the attack is far from devastating. A limited number of packets can be affected at once (depending on the number of reused nonces), and this is a somewhat targeted attack which requires timing and resources to perform. Of course, if well executed, it can compromise very sensitive data; but as of today, since there are no public exploits that we know of, we consider it to be of high complexity and difficult to perform effectively in a real environment.
To wrap up, yes, it is a big vulnerability and a great finding by Mathy Vanhoef, but unless you are affected by the All-Zero Key bug or you are not using further layers of encryption in your communications, you should just be slightly worried. Needless to say, patch as soon as you can, configure your networks to use CCM if possible, add additional layers of encryption and deploy and maintain good defence mechanisms (such as WIPS). But we would recommend the same even if KRACK did not exist anyway!
Get resources in your mailbox for free
The internet is full of bad guys that are constantly scanning all IP addresses looking for unpatched services, misconfigured servers, or simply gathering information from new targets.
Between September 6 and 9, the second radare2 conference (r2con) took place in Barcelona. This security conference is mainly focused in radare2, an open-source framework for reverse engineering with a great and active community.
Etienne Stalmans (@_staaldraad) recently discovered a Remote Code Execution vulnerability in the version-control software Git (CVE-2018-11235).