KRACK and WPA2: What It Means for Your Home Wi-Fi and Smart Devices

On Monday the details of KRACK went public, and the headline was as alarming as they get: WPA2, the protocol behind basically every password-protected Wi-Fi network, has a flaw in the protocol itself. That’s true, but it’s a lot narrower than “Wi-Fi is broken,” and the difference decides what you need to do this week. So I read the paper and the official advisories to sort out what the attack can and can’t do, and what that means for a home network full of laptops, phones and smart devices.

What a key reinstallation actually is

The research comes from Mathy Vanhoef and Frank Piessens of imec-DistriNet at KU Leuven, in a paper called Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2, due to be presented at ACM CCS in early November. The main target is the 4-way handshake, which runs whenever a device joins a protected network, personal or enterprise. It confirms both sides share the network’s secret and negotiates a fresh session key.

The client installs that session key when it receives message 3 of the handshake. Radio is lossy, so if the access point never hears message 4 it sends message 3 again, and many clients install the same key again when the retransmission shows up. The paper shows an attacker can force that retransmission on purpose. Reinstalling the key resets the packet number (the nonce) and the replay counter back to their starting values, so the device starts encrypting new frames with nonces it has already used under the same key. The paper points out that all of WPA2’s data confidentiality protocols use a stream cipher, and reusing a nonce means reusing keystream, which is what lets an attacker replay and decrypt frames.

How bad that gets depends on the cipher. Against AES-CCMP, the paper says an attacker can replay and decrypt packets but not forge them. Decryption is still enough to hijack TCP connections, and the paper’s example is injecting malicious content into unencrypted HTTP connections. Against WPA-TKIP and GCMP it’s worse, because packets can also be forged. The same trick works against the group key handshake, which lets an attacker replay broadcast and multicast frames, and against the Fast BSS Transition handshake used for roaming.

The nastiest case is on Linux and Android. The paper found that wpa_supplicant versions 2.4 and 2.5 install an all-zero encryption key when they receive the retransmitted message 3, and because Android uses a modified wpa_supplicant, Android 6.0 does the same. CERT/CC’s vulnerability note adds that John A. Van Boxtel found wpa_supplicant 2.6 is also vulnerable to CVE-2017-13077. Windows and iOS don’t accept retransmissions of message 3, so the paper says they aren’t vulnerable to the 4-way handshake attack, though they’re still exposed to the group key attack.

Ten CVEs and a CERT note

CERT/CC tracks the whole thing as VU#228519, published October 16. It lists ten CVE identifiers: CVE-2017-13077 through CVE-2017-13082, CVE-2017-13084, and CVE-2017-13086 through CVE-2017-13088, covering key reinstallation in the 4-way, group key, Fast BSS Transition, PeerKey and TDLS handshakes and in WNM Sleep Mode responses. The note says the weakness is in the standard itself, so any correct implementation is likely affected, and its solution is to install updates as vendors release them.

What it can’t do

The paper’s attacks don’t recover the session key, and the researcher’s own site says plainly that they don’t recover the Wi-Fi password. Red Hat’s KRACK page puts the practical version well: an attacker has to be within range of the Wi-Fi network, changing the Wi-Fi password won’t prevent the attack, and the attack can’t be used to recover that password either. So rotating your passphrase isn’t the fix, although the researcher’s site notes it’s never a bad idea to change it once your devices and router are updated.

Range is the other big limit. CERT/CC describes the attacker as within wireless range of the client and access point, and Microsoft’s advisory says the attacker would need to be in physical proximity and pull off a man-in-the-middle attack. This is someone near your house or coffee shop, not someone across the internet.

Don’t downgrade, either. The researcher’s site answers the WEP question with a flat no, and Red Hat says switching to WPA or WEP isn’t suggested. The researcher says implementations can be patched in a backwards compatible way, the Wi-Fi Alliance statement says patched and unpatched devices will keep working together, and it reports no evidence of malicious exploitation.

Where HTTPS fits

WPA2 only protects the hop between your device and the access point, which is why the paper’s showcase is injection into unencrypted HTTP. The researcher’s site calls HTTPS an additional layer of protection, but warns it has been bypassed in a worrying number of situations, citing non-browser software, Apple’s iOS and OS X, Android apps, banking apps and even VPN apps. So I’d treat HTTPS and a VPN you trust as habits that shrink the damage, especially on networks you don’t control, not as a reason to skip patches. And take it seriously if a browser suddenly complains about a certificate on a site that was fine yesterday.

Patch the clients first

Because the main attack goes after the client, the devices that connect to Wi-Fi are the priority. Microsoft was already there. Its advisory for CVE-2017-13080 says the fix shipped with the October 10 security updates, so Windows machines with Windows Update enabled and applied are protected. There’s one wrinkle worth knowing: when a Windows device goes into connected standby, the vulnerable functionality may be offloaded to the Wi-Fi hardware, so Microsoft encourages getting updated drivers from your Wi-Fi hardware vendor too.

Linux distributions shipped fixes the day of disclosure or right after. Debian’s DSA-3999-1 fixed wpa in jessie, stretch and later on October 16, and noted the vulnerabilities apply to both hostapd on the access point side and wpa_supplicant on the client side. Ubuntu’s USN-3455-1 covered 17.04, 16.04 LTS and 14.04 LTS the same day and says to reboot after updating, and Red Hat released RHSA-2017:2907 for RHEL 7 on October 17.

Phones are the gap. As I write this, neither Apple’s security updates page nor the Android security bulletins list a fix for these CVEs, and Android is where the all-zero key problem reaches phones. Keep automatic updates on, install the next security update from your phone or tablet maker as soon as it lands, and until then lean harder on HTTPS and your cellular connection for anything sensitive. Red Hat’s interim advice is to use wired networking where you can, which is easy for a desktop and not much help for a phone.

Then the router

Routers matter less for the 4-way handshake attack, but they aren’t off the hook. The Fast BSS Transition attack targets the access point, and the researcher’s site says both the client and the access point must be patched to defend against all the attacks. It also suggests that routers and access points can reduce exposure by disabling client functionality, the kind used in repeater modes, and by disabling 802.11r fast roaming. Check your router or mesh system maker’s support site for a firmware update, and if you use a range extender or run a router in repeater mode, that box is acting as a client and belongs on the update list too.

Smart devices that may never get a patch

This is the part of the home network I’d worry about most. CERT/CC’s vendor list includes chip makers next to operating system vendors. Espressif, for example, says its ESP8266 and ESP32 chips are affected and that it fixed its SDKs on GitHub. That’s how IoT fixes flow: the chip vendor patches an SDK, the device maker has to rebuild firmware with it, and then the device has to actually install that firmware. I suspect plenty of cheap cameras, plugs and bulbs will never complete that trip.

The paper gives two reasons this matters beyond the device itself. When the attack allows forging frames toward the access point, the paper notes the access point forwards them on, so packets can be forged toward any device on the network. And replaying broadcast frames isn’t harmless: the paper points at broadcast NTP, and it conjectures that home automation protocols that send commands as broadcast UDP could have those commands replayed.

So take inventory. Write down everything that joins your Wi-Fi, check each maker’s support page for a KRACK statement or firmware, and be honest about the ones that have no update path. For those, a guest network or a separate SSID with client isolation won’t stop KRACK against the device itself, since it still uses WPA2 over the air, but it does limit what an attacker who gets frames onto that network can reach. Your laptop and NAS shouldn’t share a network with a camera that last saw a firmware update in 2015.

The takeaway

KRACK is a real protocol flaw, but the fix is ordinary: software updates that make devices install a key only once. The attacker has to be nearby, can’t learn your Wi-Fi password, and gets the most out of unpatched clients, especially Linux and Android. Update your computers now, install phone updates the moment they arrive, check your router firmware, keep HTTPS on, and move the smart devices you can’t patch somewhere they can’t reach everything else.