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.

Source: KRACK Attacks

Comments Locked


View All Comments

  • Alexvrb - Monday, October 16, 2017 - link

    How do you figure? Most non-technically-inclined people use an ISP-supplied router. All the big ISPs supply self-updating routers. FiOS, Comcast, etc. Heck, I now use FiOS' Quantum router for the simplicity (especially since I also use them for TV). Back in the Actiontec days I used a second router... not really worth the hassle now since the Quantum is good enough.
  • beginner99 - Tuesday, October 17, 2017 - link

    In this case that doesn't matter because the client (android) is the real problem. It is the client that reused the wrong key or uses a default all zero key (android). It's the clients that need to be updated.
  • Despoiler - Monday, October 16, 2017 - link

    Asus is on point with their vulnerability updates. They patch all the time and mostly they contain updates for vulns.
  • DanNeely - Monday, October 16, 2017 - link

    Do Asus routers automatically patch themselves?

    If not, 99.9% of them are going to be as badly off as the collection of routers that will never get a patch.
  • Samus - Monday, October 16, 2017 - link

    Asus does have good router support. Netgear is pretty good too. TP-Link, while they make great routers, as abysmal support. Belkin, Linksys, and mostly D-Link, seem to be pretty lazy with firmware updates for older devices. I had a number of D-Link cameras fail after a botched firmware release a few years ago, requiring them to be sent in for warranty. Completely unacceptable.

    What's interesting about this exploit though is we don't technically need new firmware for the router. imec claims it can be patched on the client. So essentially, Microsoft could issue an update for the network stack in Windows to patch WPA2. But it's growing pretty obvious though that WPA2 has had its run and we need another security model.
  • Einy0 - Monday, October 16, 2017 - link

    I agree on ASUS but Netgear is horrible. Maybe they used to be good but there is a major security flaw that exists in their 6xxx series routers that last I checked hadn't been fixed despite them knowing about it for well over a year. TP-Link does make above average hardware at below average prices but again their firmware updates seem to bit hit or miss in frequency. I agree with the rest being lazy. D-Link is beyond lazy. I had a router that was Xbox incompatible due to a firmware bug they never fixed! Not even one fix, I inherited another D-Link router, it needed to be rebooted every two hours because of a DHCP bug, again never fixed.
  • rtho782 - Monday, October 16, 2017 - link

    The issue is that this doesn't really attack the AP, vulnerable client devices are the problem.

    Your router might get an update, but will the wifi module on your aircon unit? Or some other random device on your LAN...
  • kepstin - Monday, October 16, 2017 - link

    One thing to note is that most of the vulnerabilities listed here are attacks against the *client*, not the AP. I don't know if there's much mitigation that can be done on the AP side, but the main reason to update router firmware is to fix the vuln when using wireless repeater mode or wireless backhaul.

    Of course, this does mean that all those un-updated android clients are problematic...
  • Samus - Monday, October 16, 2017 - link

    There is no update. The whole model is flawed. They will need to replace it, and "WPA3" will likely require new hardware as I suspect the forward approach will be to radically reconsider how security is implemented in wireless devices, possibly a dedicated security ASIC.

    This is a mic drop from imec-Distrinet, because odds are this exploit has been used by the CIA and other governments for some time.
  • Samus - Monday, October 16, 2017 - link

    Before someone trolls me, I want to clarify that while this exploit can be patched according to imec, the security model needs to be updated. They point out in their Q&A that either the client or host (router) can be patched to fix the flaw, but none the less leave the door open to a next generation standard being needed in the near future.

Log in

Don't have an account? Sign up now