Security

KRACK WPA2 protocol Wi-Fi attack: How it works and who's at risk

A vulnerability in the WPA2 protocol used in secured Wi-Fi networks allows hackers to force devices to install arbitrary encryption keys. Here are the details of how the attack works.

A vulnerability in the WPA2 protocol allowing attackers to read encrypted information transmitted over Wi-Fi was discovered by Mathy Vanhoef, a post-doctorate researcher at KU Leuven. Due to a flaw in the design of the protocol itself—not a specific vendor implementation—attackers can capture part of the handshake message, and use modified versions of that to trick devices into installing a blank encryption key, a process called "key reinstallation attacks," or KRACKs by Vanhoef.

SEE: Information security incident reporting policy (Tech Pro Research)

As this vulnerability does not rely on a specific vendor implementation, practically any device with a specification-compliant implementation of WPA2 is affected. For enterprise Wi-Fi deployments, this can be particularly problematic as fast BSS transition is vulnerable to this attack. In the immediate term, patching client devices is the highest priority. However, wireless routers and access points may require a vendor patch to protect against this vulnerability.

How the attack works

Because of the depth and nuance of this vulnerability, collectively KRACK has 10 CVE identifiers assigned to it. The lynchpin of the vulnerability is the four-way handshake used when a client device attempts to join a protected network. After verifying the Wi-Fi password for the network itself, the encryption key for the session is negotiated. These handshake messages can be captured and manipulated by an attacker, and rebroadcast to a device which proceeds to reinstall the encryption key.

The WPA2 handshake design permits for the possibility of a dropped packet during handshake. Therefore, the third step of the four-way handshake—in which the encryption key is negotiated—may be rebroadcast to the client if the access point has not received an acknowledgement. Per protocol design, the client may receive the encryption key multiple times, and is expected to reinstall that key, resetting the incremental packet transit number ("nonce") and receive reply counter. Attackers can take advantage of this behavior to replay, decrypt, or forge packets.

Naturally, this ability extends to TCP SYN packets, making it possible for attackers to hijack TCP connections, in functionally the same way attackers inject data on unprotected Wi-Fi networks.

Of note, this attack does not allow attackers to recover the network password.

When was this discovered

Vanhoef's paper on this vulnerability, Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2 was submitted for review on May 19, 2017. It will be presented at the Computer and Communications Security conference on November 1, 2017.

Vanhoef first notified vendors with products he personally tested and found to be vulnerable "around" July 14, 2017. After determining that this was a vulnerability of the protocol, not of a vendor-specific implementation, Vanhoef approached CERT/CC, which in turn notified product vendors on August 28th.

Who is affected

Practically any device capable of sending or receiving a Wi-Fi signal is affected. Because of the nature of the attack, the client device is the target and is, therefore, the highest priority for patching.

In Vanhoef's proof of concept against a phone running Android 6.0, the behavior of wpa_supplicant—a Wi-Fi library used in Android and various Linux distributions—causes the encryption key to be erased from memory after being installed the first time. As such, if an attacker retransmits part of the handshake, the library will reinstall the cleared key, effectively replacing the key with a blank one.

According to Vanhoef, "This makes it trivial to intercept and manipulate traffic sent by these Linux and Android devices." He also noted that 41% of Android devices run Android 6.0 or above, where this behavior was introduced. At press time, a patched wpk_supplicant is in testing for Fedora, though no patch has yet been introduced for Ubuntu.

SEE: Online security 101: Tips for protecting your privacy from hackers and spies (ZDNet)

CERT provides a list of vendors with products affected by this vulnerability, with information from individual vendors about the status of their plans to patch or otherwise mitigate this issue. For enterprise Wi-Fi deployments, Ubiquiti noted that UniFi access points on firmware 3.9.3 and above are not affected by WPA2 key issues, but that fast BSS transition is still affected, though that feature is in beta. Zyxel has posted a page detailing the rollout of patches to address this issue, projected to begin next month. Aruba has posted a memo and updated firmware to address this issue.

What can be done to mitigate damage

For mobile, particularly Android devices, avoiding connecting to Wi-Fi networks in public places—even if they are protected networks.

It is possible to patch devices in a backward-compatible manner, though distribution of these patches is likely to take time. Check with your product vendors to see if a patch is available or necessary.

Update (from an article by TechRepublic's Conner Forrest) : Security professionals are reminding enterprises that the vulnerability is patchable, and there is currently no publicly-available code to attack this flaw. In a statement to the Verge, Microsoft said that it has already issued a patch for the KRACK vulnerability, and Google has promised a patch in the coming weeks. A Linux patch is also available and a host of other organizations have issued patches as well.

Also see

reddata.jpg
Image: iStockphoto/imply

About James Sanders

James Sanders is a Java programmer specializing in software as a service and thin client design, and virtualizing legacy programs for modern hardware.

Editor's Picks

Free Newsletters, In your Inbox