Introduction

After discovering key reinstallation attacks (KRACKs) against WPA2 last year, which allowed an attacker to recover data sent over a protected Wi-Fi network, we investigated whether products were properly updated to prevent attacks. Although we found that most vendors properly updated their products, in certain cases attacks were still possible. Apart from this, we also discovered techniques to bypass Wi-Fi's official defense against KRACK, allowing an adversary to replay broadcast and multicast frames. We are now also disclosing easier and more effective techniques to attack unpatched Wi-Fi devices. Finally, in new our paper we explain in more detail how to abuse certain vulnerabilities that were already disclosed last year.

The good news is that most vendors already distributed (new) updates to prevent attacks, and that the impact of replaying broadcast and multicast frames is low in practice. Therefore most users should not worry, simply follow the usual security advice and keep your devices up to date. In other words, our new paper and results are not as serious as the original key reinstallation attacks. Nevertheless, our research is a good reminder that patching vulnerabilities can be hard in practice, and that we must keep checking whether devices are properly updated.

All our new findings are described in detail in our research paper "Release the Kraken: New KRACKs in the 802.11 Standard" which will be presented at the Computer and Communications Security (CCS) conference this year.

Details

Before explaining our new results, it's good to quickly recap our original findings. The following BCC video provides an excellent summary:

Overview of our new results

In our new paper, we extend the original KRACK attack in several directions. First, we improve existing attacks against the 4-way handshake, making it easier to attack unpatched devices. We then study the Wi-Fi standard, and find that the FILS handshake is also vulnerable to key reinstallations. Fortunately, this handshake is not yet deployed in practice. Apart from this, the paper also shows how WNM power-save features can be abused to bypass Wi-Fi's official countermeasure against KRACK. Finally, we investigate whether products were properly updated to prevent key reinstallations, and discovered implementation-specific vulnerabilities related to key reinstallation attacks (e.g. we found vulnerabilities in macOS and iOS that have in the meantime been patched).

The paper also describes how to abuse certain vulnerabilities that we already disclosed last year, but that were not yet discussed in detail. In particular, the paper explains how WNM power-save features can be abused to trigger reinstallations of the group key, and how the TPK handshake can be manipulated into reinstalling the TPK key. The TPK handshake enables direct connectivity between clients (e.g. between smart TV's and a tablets).

Improved 4-way handshake attacks

We first increase the practicality of key reinstallation attacks against the 4-way handshake. Previously, device-specific and hard-to-win race conditions had to be used to exploit the 4-way handshake of Android, macOS, and OpenBSD. This was necessary, because otherwise these platforms would not accept the plaintext handshake message that triggers the key reinstallation. We overcame these limitations by generating an encrypted (instead of plaintext) handshake message that triggers the key reinstallation. As a result, an adversary no longer has to rely on hard-to-win race conditions to exploit vulnerable implementations of the 4-way handshake.

Attacking the FILS and TPK handshake

A systematic analysis of the Wi-Fi standard revealed that the Fast Initial Link Setup (FILS) and Tunneled direct-link setup PeerKey (TPK) handshake are also vulnerable to key reinstallations. The FILS handshake can establish a secure Internet connection in only 100 ms, and is expected to be widely adopted in highly mobile environments. The TPK handshake is mainly used to stream data from a device to a smart TV, and establishes a direct tunnel between two clients. Fortunately, the FILS handshake is not yet used in practice, and the vulnerability in the TPK handshake was already patched during the coordinated disclosure last year.

Bypassing Wi-Fi's official countermeasure

We also found that an adversary can abuse WNM-Sleep frames to bypass Wi-Fi's official defense against KRACK. That's because the official defense states that a device shouldn't reinstall an already in-use key. However, this defense can by bypassed by first letting the victim install a new key, to then let it (re)install an old key. On a technical level, this is achieved by exploiting interactions between EAPOL-Key frames and WNM-Sleep frames. An adversary can only reinstall the (integrity) group key in this manner. As a result, the impact of this bypass is low in practice. Note that WNM-Sleep frames are part of the 802.11v amendment to the Wi-Fi standard. Meanwhile, the Wi-Fi standard has been updated to prevent these kind of attacks.

We also found implementation-specific vulnerabilities where the group key is improperly installed. For example, we found that certain devices always install the group key with a zero replay counter. More troublesome, we even discovered some devices that always accept replayed broadcast and multicast frames. All combined, this shows that securely handling and installing group keys is a non-trivial task.

Implementation-specific vulnerabilities

Last but not least, we discovered several implementation-specific key reinstallation vulnerabilities while inspecting patches and open source code. For example, even after the patches that prevent the KRACK attack, macOS reused the SNonce during rekeys of the session key. As another example, iOS did not properly install the (integrity) group key. These vulnerabilities have a similar impact as the original KRACK attacks. Another noteworthy vulnerability is that some routers accept replayed message 4's of the 4-way handshake. In particular, more than 100 routers that use the MediaTek MT7620 chip, such as the RT-AC51U, are vulnerable to this attack. An adversary can abuse this to trivially trigger key reinstallations against the router, without having to obtain a man-in-the-middle position. In turn it becomes possible to decrypt, replay, and possibly forge frames.

Discussion: protocol gadgets

One common theme in our new work is that seemingly innocent bugs, and even protocol features, can act as essential gadgets when trying to exploit (implementation-specific) protocol bugs. For example, on its own the technique to generate encrypted handshake messages is innocent. However, this technique allowed us to perform key reinstallation attacks against more devices than previously thought possible. Similarly, a bug in Linux allowing an insider to spoof the source and destination address, had little impact on its own. Unfortunately, this bug proved essential to trigger key reinstallations against certain versions of wpa_supplicant. As another example, having separate receive replay counters for each Quality-of-Service (QoS) channel is also not a security risk on its own. However, this protocol feature allowed us to attack the group key and TPK handshake. In other words, seemingly innocent protocol features or implementation bugs can act as essential gadgets that enable exploitation of other vulnerabilities.

The most intriguing example is that users noticed that some versions of wpa_supplicant were installing an all-zero key upon receiving a retransmitted message 3. However, they did not realize an adversary could actively trigger these retransmissions, and therefore only treated this as an innocent bug. In a sense they almost discovered key reinstallation attacks, but failed to realize the capabilities of an adversary, and because of that did not realize this was an exploitable bug.

These observations teach us that it can be very difficult to determine whether a protocol bug is exploitable or not. In other words, one needs an expert understanding of all available gadgets, i.e., related protocol features and implementations bugs. Only when having this knowledge is it possible to accurately determine whether, and under which conditions, a protocol bug is exploitable.

Conclusion

Our results show that preventing key reinstallations is harder than initially assumed. For example, we were able to bypass Wi-Fi's official countermeasure and reinstall the group key. Additionally, we showed that the FILS handshake is vulnerable to key reinstallation attacks, and we also discovered novel implementation-specific vulnerabilities that facilitate key (re)installation attacks.

We believe the main reason vulnerabilities are still present is because the Wi-Fi standard is large, is continually being expanded with new features, and requires domain-specific knowledge to understand. These obstacles can be overcome by having high-level descriptions (or formal models) of all security-related features of Wi-Fi. This would make it easier to reason about its design, and test the correctness of implementations. Additionally, we believe the Wi-Fi Alliance should not only test products for interoperability, but also fuzz them for vulnerabilities.

Paper

Our research paper behind the attack is titled Release the Kraken: New KRACKs in the 802.11 Standard and will be presented at the Computer and Communications Security (CCS) conference in October 2018.

To cite our paper, you can use the following example citation or bibtex entry:

Mathy Vanhoef and Frank Piessens. 2018. Release the Kraken: New KRACKs in the 802.11 Standard. In 2018 ACM SIGSAC Conference on Computer and Communications Security (CCS ’18). ACM.

@inproceedings{vanhoef-ccs2018,
  author        = {Mathy Vanhoef and Frank Piessens},
  title         = {Release the Kraken: new {KRACKs} in the 802.11 Standard},
  booktitle     = {Proceedings of the 25th ACM Conference on Computer and Communications Security (CCS)},
  year          = {2018},
  publisher     = {ACM}
}

New tools

Our proof-of-concept script to perform key reinstallation attacks is now available on github. It targets Android and Linux devices that (re)install an all-zero key. This script is also the one that we used in the demonstration video last year. We successfully tested it in a lab setup against Chromium and Android. The script uses Channel Switch Announcements to establish a channel-based man-in-the-middle.

We remark that the reliability of our proof-of-concept script depends on how close the victim is to the real network. If the victim is close to the real network, the script may fail because the victim will always directly communicate with the real network, even if the victim is (forced) to use a Wi-Fi channel different from the real network.

Q&A

Why did you make a website about these new results?

To clearly state that our new results are not as serious as the original key reinstallation attacks. Several new attacks mentioned in the paper are implementation-specific, and the attack against the TPK handshake was already patched during the coordinated disclosure last year. Similarly, key reinstallations caused by WNM frames were also already patched last year. However, in our new paper we describe for the first time how these (already disclosed) vulnerabilities can be exploited. Finally, the method to bypass Wi-Fi's official defense can only be abused to reinstall the (integrity) group key, and is non-trivial to execute in practice. Nevertheless, it is good to make people aware that fully preventing KRACK attacks is hard in practice, meaning it is important to keep checking whether devices are properly patched.

Will WPA3 prevent KRACK?

On its own WPA3 does not prevent key reinstallation attacks. So a WPA3-capable device may be still vulnerable to KRACK. That's because internally WPA3 still uses the 4-way handshake (in combination with the new Dragonfly handshake). In other words, if a vendor does not properly implement the 4-way handshake, a WPA3 network may be vulnerable to KRACK.

Does KRACK also affect Opportunistic Wireless Encryption (OWE)?

It could. Opportunistic Wireless Encryption (called Enhanced Open by the Wi-Fi Alliance) internally still uses the 4-way handshake (in addition to an unauthenticated Diffie-Hellman handshake). So if a vendor does not properly implement the 4-way handshake, an OWE network may also be vulnerable to KRACK.

Are the key reinstallations in the RT-AC51U fixed?

Based on the firmware update history, the RT-AC51U router has not yet received a patched.

When did Apple fix the additional vulnerabilities?

We do not know precisely when Apple patched the vulnerabilities mentioned in the paper, because the corresponding patches are not mentioned in Apple's security update notes. Based on our own tests, we know that the improper installation of the group key (GTK) was fixed in iOS 12.0 and above. Similarly, the SNonce reuse vulnerability was fixed in macOS High Seirra 10.13.3 and above. Do note that these vulnerabilities might have already been fixed in earlier versions, unfortunately, we are not able to test older versions ourselves.

Has the Wi-Fi standard been updated in the meantime?

After the disclosure of key reinstallation attacks last years, the Wi-Fi standard was updated to prevent most attacks. However, even with this update, it is still possible to force a victim to temporarily install a new group key, to then reinstall an old group key. This allows an adversary to replay broadcast and multicast frames towards the victim. Abusing this remaining vulnerability is non-trivial, and has a low impact in practice. Nevertheless, it would be better to update the Wi-Fi standard such that all key reinstallation attacks are prevented.

Looking back, how serious do you think the original KRACK attack was?

The original KRACK attack highlighted a weakness in the core of the WPA2 standard, and practically all clients were affected by some variant of the attack. This was very surprising, considering the core of WPA2 was formally proven secure, and over its decade-long lifetime, there were no known attacks against it (assuming a strong password is used). Therefore the impact was quite serious and unexpected.

Thankfully, in practice it appears few people are abusing KRACK. We attribute this to two important factors. First, thanks to the coordinated disclosure last year, a significant proportion of devices were quickly patched (even though some devices took a really long time to receive updates). Second, we purposely did not release our attack tools, making it non-trivial for others to abuse KRACK in practice. Even the tools we released now are purposely not fully weaponized, to prevent people from easily performing KRACK attacks in practice.