KRACK (Key Reinstallation Attacks) is an effective attack on the WPA2 802.11i protocol used for protecting WiFi networks, published on October 16 2017 .
Because it is an attack on the protocol itself, every piece of equipment that can communicate over WiFi is affected. The attack must be carried out by a device that is in range of the network; i.e. this is a local attack, not a remote one.
Be WORRIED, but there is no need to PANIC. If there is a PATCH for your device, apply it as soon as possible. Otherwise, worry until there is.
KRACK tricks your wireless devices into resetting their encryption sessions to a known state, after which the attacker can read everything that they do, and can inject their own data into the network (i.e. a Man-in-the-Middle attack). This effectively turns your “private, secure” WPA2 network into a “public, insecure” one.
If you are safe operating your device on a public insecure network (e.g. airport or coffee-shop WiFi), then you will be equally safe operating it on a compromised WPA2 network.
KRACK does NOT steal your WiFi passwords or credentials.
The only effective fix for KRACK is on your client devices. PCs and laptops are likely to be patched quickly, mobile phones much more slowly if at all, and IoT devices are at serious risk.
- KRACK website, https://www.krackattacks.com/
- Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2, https://papers.mathyvanhoef.com/ccs2017.pdf
- CERT CVEs, http://www.kb.cert.org/vuls/id/228519
- CVE-2017-13077: reinstallation of the pairwise key in the Four-way handshake
- CVE-2017-13078: reinstallation of the group key in the Four-way handshake
- CVE-2017-13079: reinstallation of the integrity group key in the Four-way handshake
- CVE-2017-13080: reinstallation of the group key in the Group Key handshake
- CVE-2017-13081: reinstallation of the integrity group key in the Group Key handshake
- CVE-2017-13082: accepting a retransmitted Fast BSS Transition Reassociation Request and reinstalling the pairwise key while processing it
- CVE-2017-13084: reinstallation of the STK key in the PeerKey handshake
- CVE-2017-13086: reinstallation of the Tunneled Direct-Link Setup (TDLS) PeerKey (TPK) key in the TDLS handshake
- CVE-2017-13087: reinstallation of the group key (GTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame
- CVE-2017-13088: reinstallation of the integrity group key (IGTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame
In early 2017 the researchers were finishing off another security publication when they realised that part of the OpenBSD network code for WiFi that they were discussing had a potential problem. By July 2017 a wide range of systems had been confirmed with this problem, and the CERT/CC co-ordinated a wider notification to OS and device vendors in late August. The public announcement was made on 16 October 2017.
Many vendors have made announcements and released patches already, more will be coming soon. OpenBSD patched early due to their relationship to the original discovery, some other vendors seem to have issued patches already but many important ones are yet to patch.
At the moment I’m getting my information from the CERT/CC and the Bleeping Computer website, but I’ll verify from original sources as soon as I can. https://www.bleepingcomputer.com/news/security/list-of-firmware-and-driver-updates-for-krack-wpa2-vulnerability/
- Microsoft: Security updates issued on 10 October.
- Apple: No statement has been made to CERT/CC
Possibly patches have been issued but we’re not sure.
- Linux: wpa_supplicant upstream has been patched.
RedHat, Fedora, Debian, Ubuntu and many others have incorporated this patch already.
- Android: No information yet from Google.
In any case, Android devices generally don’t get their patches from Google, you will have to check with individual vendors (Samsung, etc) directly.
- Internet of Things (IoT): Check with every vendor directly. Many devices are already infamous for their lack of security responses, so please review all such devices carefully.
If you have a device using WiFi, and there are no patches for it, you should assume that all traffic from that device can be spied on and potentially altered. If you are encrypting your communications with TLS/SSL or something equivalent like OpenSSH, then all you are at risk from is a lack of privacy. However, you might need to consider implementing a VPN if you rely on plaintext or easily spoofed protocols.
If you have any further questions, please get in touch with the Information Security Office through the usual channels.