Release the KRACKen: WPA2 Wi-Fi Encryption Hackable Until All Clients & APs Are Patched

Some of us woke up at the KRACK of dawn to begin reading about the latest serious vulnerability that impacts the vast majority of users on Wi-Fi. If you weren't one of those early readers, I'm talking about the Key Reinstallation Attack, which affects nearly all Wi-Fi devices.

The researcher who discovered KRACK, Mathy Vanhoef of imec-DistriNet at KU Leuven in Belgium, recently released his research paper "Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2," additionally crediting Frank Piessens, his supervisor, for his guidance. Vanhoef will be presenting at the Computer and Communications Security (CSS) this November.

Microsoft, Ubiquiti (for UniFi), Aruba, Cisco, Espressif, Intel, Linux, Mikrotik, OpenBSD, and Netgear have already released patches. Until other vendors begin working on patches, the rest of the internet using Wi-Fi remains vulnerable.

So what is actually going on?

The proof-of-concept exploit that affects a core part of the 802.11i (WPA2) protocol was revealed at 8 a.m. EST this morning by Vanhoef. The vulnerabilities were index under the following: CVE-2017-13077, CVE-2017-13078, CVE-2017-13079, CVE-2017-13080, CVE-2017-13081, CVE-2017-13082, CVE-2017-13084, CVE-2017-13086, CVE-2017-13087, and CVE-2017-13088.

A demonstration of the attack from the paper may be seen here:

It is effective in targeting home or enterprise access points, as well as vulnerable devices such as computers, laptops, smartphones, and IoT devices. Vanhoef provided vendors 45 days (or more) after reaching out to them in July to patch the vulnerability before revealing them publicly, with the US-CERT (United States Computer Emergency Readiness Team) sending a broader notification to vendors in late August. On the release of a script using this exploit, as stated by Vanhoef:

It will be released once everyone had a reasonable chance to update their devices (and we have had a chance to prepare the code repository for release). We remark that the reliability of our proof-of-concept script may depend on how close the victim is to the real network. If the victim is very 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) on a different Wi-Fi channel than this network.

While they are providing time prior to releasing a working exploit, this does not aid in the massive issue of devices that cannot be immediately patched and fixed. Many devices do the work on just the hardware level with no on-chip storage making it much harder to access and update, if at all, for many access points. People are most likely going to or have already begun working on creating their own tools and scripts for easy access to the vulnerability in unpatched devices before the patches have been released.

The impact of this vulnerability being unpatched in the wild is unsettling. An advisory by the US-CERT distributed to around 100 organizations stated:

US-CERT has become aware of several key management vulnerabilities in the 4-way handshake of the Wi-Fi Protected Access II (WPA2) security protocol. The impact of exploiting these vulnerabilities includes decryption, packet replay, TCP connection hijacking, HTTP content injection, and others. Note that as protocol-level issues, most or all correct implementations of the standard will be affected. The CERT/CC and the reporting researcher KU Leuven, will be publicly disclosing these vulnerabilities on 16 October 2017.

While this attack does not recover the password of your Wi-Fi network, the abilities it provides to attackers is astounding. Android and Linux users are especially susceptible, as the researchers have found that 41% of Android devices are vulnerable to these attacks (where an additional bug effectively resets the encryption key to all zeros).

The new attack in the 802.11i protocol (WPA2) can force nonce reuse — even during the four-way handshake — which is used to establish a key for encrypting traffic between clients and access points. Typically, the protocol uses AES in CCM mode (what CCM mode really just means it is only defined for block ciphers with a block length of 128-bit) but other modes are used, too. The primary modes used are stream ciphers, hence their vulnerability to an attack where reusing a nonce means reusing the same key again.

A nonce is a single-use per-packet counter used to ensure that each packet (even if containing identical data) does not reuse the same encryption key. In most WPA2 encryption implementations, the nonce starts at zero when you've begun a session and increments up to 2^48. This attack takes advantage of a flaw in the protocol that allows an attacker to force nonce reuse, and by extension, key reuse.

This occurs by attacking and blocking the third message of the four-part handshake, causing the access point to reset the nonce and resend the third message again to the client. One attack handles scenarios where a message is sent encrypted and one where it is sent still unencrypted. By being able to force your access point to essentially have another go at sending a message back to you, an attacker can subsequently do a MitM attack where each subsequent nonce is reused, allowing the attacker to (depending on the protocol used) either decrypt the traffic or even alter it. This, of course, allows for further attacks.

As of right now, there is no knowledge of this attack being used in the wild. On the other hand, this vulnerability will likely remain in devices that may never be able to get patched, and tools to easily exploit the vulnerability already exist (though they haven't been made public yet).

Vendors currently working on patches include Peplink, who has notified clients that their access point is not affected but their client (for Wi-Fi-based WAN) is, promising a patch within two weeks. Amazon likewise says they are working on one, and Google has stated there will be no patches for the latest version of Android until November 6 and have not provided any timelines for older versions.

As an end user, you can check CERT's vendor list to see if your vendor has issued a patch (though this list appears to be a little out of date already). Ultimately, your exposure to the vulnerability comes down to your devices, vendors, and their ability to patch devices quickly (if at all). Until then, using cellular data, Ethernet, and forcing HTTPS (ex: by using the HTTPS Everywhere extension by the EFF) are the most recommended options to limit your exposure.

• Follow Null Byte on Twitter and Google+
• Follow WonderHowTo on Facebook, Twitter, Pinterest, and Google+