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

  • shabby - Monday, October 16, 2017 - link

    How timely are router manufacturers with updates, better than android oem's?
  • DanNeely - Monday, October 16, 2017 - link

    Outside of enterprise hardware (which are either going live with patches today, or ninja patched their firmware weeks ago and are just updating patch notes this morning) they're generally worse.
  • Bateluer - Tuesday, October 17, 2017 - link

    For what its worth, my consumer grade Netgear WiFi router, which is a couple years old now and hasn't seen any firmware updates in a long time, has a new update posted.
  • dgingeri - Tuesday, October 17, 2017 - link

    Netgear is usually better than any other off the shelf router company, but still lacking in fixing security issues. All of the off the shelf router makers are pretty bad at security fixes, though. Most simply ignore the issues reported to them, and it is like pulling teeth to even get bug fixes.

    Corporate and small business class wifi AP makers are usually pretty good about things like this, though. As noted in the article above, Aruba, Mikrotik, and Ubiquiti have already patched it.
  • Ninhalem - Monday, October 16, 2017 - link

    I have several pieces of equipment including one access point all made by Ubiquiti. Ubiquiti has already pushed a firmware patch for this. Other major enterprise equipment manufacturers have probably pushed patches or in the process of. As for consumer grade wireless, no idea. There's a reason I jumped ship to Enterprise Lite.
  • crimson117 - Monday, October 16, 2017 - link

    I'm worried most people will never flash update their home of small business router, assuming a software fix is even possible.
  • crimson117 - Monday, October 16, 2017 - link

    *home OR small business router
  • ddriver - Monday, October 16, 2017 - link

    Many of consumer routers' admin pass is the product model default. And even for those that don't, a surprising amount of passwords can be guessed within 5 tries.

    I also doubt much of the most widely spread routers will even see a security patch related to this.
  • dgingeri - Tuesday, October 17, 2017 - link

    I saw a line of consumer routers that had randomly generated passwords that were included in an internal sticker. It was still advised to change the password, but with passwords like "melodiconion2783", it wasn't as easy to crack the default. However, since they got so many support calls about the default passwords, they reverted to their old ways of setting a single default password for all their models the next year. Stupid people will always be our bane.
  • flyingpants1 - Monday, October 16, 2017 - link

    Well, you're right. Most (almost all) routers and wi-fi devices will simply NEVER BE UPDATED.

    Wi-fi was never secure. That's why we used to have hardware wi-fi switches on laptops. Turn off your wi-fi.

Log in

Don't have an account? Sign up now