Multiple WiFi Encryption Vulnerabilities Disclosed, Affecting Almost Everything

Today a collection of severe security vulnerabilities in the WPA2 encryption protocol for Wi-Fi are being disclosed, along with a proof of concept exploit. The weaknesses center around the process used for negotiating the encryption keys used by the client and access point. These core vulnerabilities are part of the Wi-Fi Protected Access WPA standard itself, so even devices that correctly implement WPA2 according to spec are expected to be affected. Both personal and enterprise WPA modes are affected, and both the original WPA and WPA2 are affected. The primary mode of attack exploits vulnerabilities in client devices, but there are some variants that affect features used by some access points.

As a quick WPA refresher, the password you type in to connect to an access point using WPA2 is not directly used as the encryption key for the network traffic your device exchanges with the access point. Instead, that password (technically referred to as a pre-shared key) is used to authenticate the client device to the access point and start the process of negotiating the connection. The vulnerabilities disclosed today allow for attacks on the four-way handshake sequence that is used in setting up the encryption and determining what keys will be used, all without having to broadcast the pre-shared key itself. Once a connection is fully established, the client and access point regularly rotate the encryption keys to new ones derived from the pre-shared key.

802.11i Four-Way Handshake (Image Via Wikipedia)

The proof of concept attack technique, named KRACK short for Key Reinstallation Attacks, focuses on step three of the four-way handshake. In the third step, the access point sends to the client confirmation that the access point has completed its side of the key negotiation process. After receiving that message, the client can begin using the negotiated key and initialization vector to encrypt traffic, and the client completes the handshake by sending the access point an acknowledgment.

But that assumes each of the four messages in the handshake process is successfully received. The key negotiation process needs to allow for the possibility of radio interference, so it permits the access point to re-send the message that is step three of the handshake. If an attacker sends a copy of this message, the client device will be tricked into reverting back to the original encryption key and initialization vector used at the start of the session. The client's next transmissions will have been encrypted with the same key as earlier transmissions, even though that key was only meant for a single use. That allows for a key reuse attack, which doesn't directly expose the underlying encryption key but does make it relatively easy to decrypt the data that was encrypted, especially if something is known about the structure of the messages that were both encrypted with the same key. IP packet headers, in turn, provide exactly that.

Despite not leaking the Wi-Fi pre-shared key itself or the per-session master key negotiated by the four-way handshake, KRACK style attacks can net the attacker enough information to start hijacking TCP connections and escalate to similar attacks. If the wireless network is using the older WPA-TKIP protocol instead of the WPA2 AES-CCMP protocol, then the attacker may be able to forge and inject packets into the wireless network itself instead of using the recovered information in less direct attacks. Meanwhile, newer networks using the short-range Wireless Gigabit (IEEE 802.11ad) standard generally use GCMP,  which uses the same authentication key for both directions of communication between the client and access point, so a KRACK attack can allow for decryption of transmissions from either device.

Linux systems including Android version 6.0 and above generally use the wpa_supplicant program. This implementation of WPA tries to defend against key reuse by wiping it from RAM after it is used for the first time. When subjected to a KRACK attack, this means wpa_supplicant doesn't revert to the original key but instead replaces its key with all zeroes. Unfortunately, in the KRACK scenario this technique backfires and results in a known, fixed key, making decrypting future transmissions too easy.

Today's disclosure is documented across ten CVEs, each describing a different style of key reinstallation attack on different parts or modes of WPA. This means that any full-featured Wi-Fi implementation is likely to require patching in several places. Fortunately, these key reinstallation vulnerabilities can all be fixed in a backwards-compatible manner, and the Wi-Fi standards are expected to be updated to require defenses against key reinstallation attacks. This class of vulnerabilities was discovered earlier this year and the researchers involved began informing vendors in July. CERT issued a broad notification to vendors on August 28. OpenBSD has already patched their WPA implementation, and Aruba, Mikrotik and Ubiquiti are among the vendors reported to have fixes ready or already deployed.

As with many other recent major security vulnerabilities, this discovery has been given memorable branding and a logo:

This is hardly the first major security breach to affect Wi-Fi. The original standard for Wi-Fi encryption was named Wired Equivalent Privacy (WEP), a name that proved to be completely inaccurate as flaws were found permitting quick and easy cracking of the encryption. Wi-Fi Protected Access (WPA) was introduced as a replacement that could be deployed on most existing hardware with software and firmware updates, while WPA2 made more significant changes like switching from the RC4 cipher to AES. Previous attacks against WPA2 have all relied on some form of password guessing at heart, such as attacks exploiting Wi-Fi Protected Setup (WPS) PINs. Until now, the four-way handshake process in WPA was regarded as secure, and the AES cipher used by WPA2 is still considered secure.

This is also not the first widespread security flaw affecting common network infrastructure to have been disclosed recently. Earlier this month, a team of Google security researchers published several vulnerabilities in DNSMasq, the DNS and DHCP server most commonly used by consumer-grade routers. The severity of these bugs ranged from denial of service to remote code execution and affected both the DNS and DHCP functionality of DNSMasq.