WiFi Key Reinstallation Attack breaks WPA2 encryption
Researchers have discovered a flaw in the Wi-Fi standard that attackers may use to eavesdrop on wireless network traffic even if WPA2 is used for protection.
Key Reinstallation Attacks, or Krack Attacks, work against all Wi-Fi networks protected by WPA2, and may in some cases be used to inject and manipulate data as well. The attack works against WPA and WPA2 standards, and against personal and Enterprise networks that implement Wi-Fi.
The attack method works against the 4-way handshake of the WPA2 protocol. This handshake is executed when client devices, say an Android smartphone or a laptop, want to join the Wi-Fi network.
The handshake verifies credentials and negotiates an encryption key that is then used to protect the traffic while the connection is active.
Update: Microsoft published advisory in which it highlighted that it fixed the issue for all supported and affected versions of Windows on this October 2017 Patch Tuesday.
The main flaw the researchers discovered affects the key, and is achieved by "manipulating and replying cryptographic handshake messages". In other words, the attacker tricks the victim into reinstalling a key that is already in use.
When a client joins a network, it executes the 4-way handshake to negotiate a fresh encryption key. It will install this key after receiving message 3 of the 4-way handshake. Once the key is installed, it will be used to encrypt normal data frames using an encryption protocol. However, because messages may be lost or dropped, the Access Point (AP) will retransmit message 3 if it did not receive an appropriate response as acknowledgment. As a result, the client may receive message 3 multiple times. Each time it receives this message, it will reinstall the same encryption key, and thereby reset the incremental transmit packet number (nonce) and receive replay counter used by the encryption protocol.
We show that an attacker can force these nonce resets by collecting and replaying retransmissions of message 3 of the 4-way handshake. By forcing nonce reuse in this manner, the encryption protocol can be attacked, e.g., packets can be replayed, decrypted, and/or forged.
The researchers note that any data that is transferred can in theory by decrypted by the attacker.
The following Common Vulnerabilities and Exposures identifiers were assigned to the vulnerability:
- CVE-2017-13077: Reinstallation of the pairwise encryption key (PTK-TK) in the 4-way handshake.
- CVE-2017-13078: Reinstallation of the group key (GTK) in the 4-way handshake.
- CVE-2017-13079: Reinstallation of the integrity group key (IGTK) in the 4-way handshake.
- CVE-2017-13080: Reinstallation of the group key (GTK) in the group key handshake.
- CVE-2017-13081: Reinstallation of the integrity group key (IGTK) in the group key handshake.
- CVE-2017-13082: Accepting a retransmitted Fast BSS Transition (FT) Reassociation Request and reinstalling the pairwise encryption key (PTK-TK) 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.
The research paper can be downloaded from here (PDF), additional information on the vulnerability and the researchers on the Krack Attacks website.
Good news is that it is possible to patch the issue. However, a firmware update needs to be released by the manufacturer of the router, access point or client. The researchers note that any device that uses Wi-Fi is likely vulnerable to the attack.
One thing that users may do is use VPN connections to use an extra layer of protection so that attackers cannot decrypt the traffic even if they attack a device successfully. You may use cable connections as well if that is an option.
Greetz* – Hey, when are they going to release the full version of Krack? ie the one that “actually works??” ….-_-
I would’t say it’s broken at this point:
1) Use cable over Wifi
2) Use encrypted login pages
3) Updates are coming (it will take some time to fix this but there will)
4) End … Nothing is broken here. However you still can abuse almost every protocol, so if you advertise something as broken then you can say this to every protocol.
Ms hasn’t fixed the issue btw. It’s the first concept, the real fix will take much longer and not only affects one OS btw.
Flash dd-wrt if your router is compatible with it. Dd-wrt is patched according to Windows central website.
I am just reading this Brian Benchoff article today, maybe it’s a good read.
Brian concludes that “this isn’t a world-ending Armageddon in the way the botnet of webcams was.” and “However, turning off Wi-Fi on your phone, relying on mobile data, not ignoring HTTPS cert warnings, and plugging into an Ethernet port might not be a bad idea”.
More info at:
https://hackaday.com/2017/10/16/oh-great-wpa2-is-broken/
The title of this article, “WiFi Key Reinstallation Attack breaks WPA2 encryption”, is misleading. From what is indicated in the article, the encryption does not appear to ever be broken, only the authentication or connection negotiation using the WPA2 protocol.
Microsoft has issued a fix: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-13080
However, the link takes me to the last Patch Tuesday update and not to the October 16 release: https://www.catalog.update.microsoft.com/Search.aspx?q=KB4041687
I understand it that Microsoft patches the issue with the October 2017 updates, and that you don’t need to install another patch.
OK, understand. I was a bit confused because the following site posted the vulnerability dated October 16 stating that Microsoft had issued a patch: https://www.securitytracker.com/id/1039572
I assumed that to mean it was a new patch since in the previous Patch Tuesday summary there was no mention of it anywhere: https://www.securitytracker.com/archives/summary/9000.html
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-13080
When did Microsoft release the security updates to address this vulnerability?
Microsoft released security updates on October 10, 2017 as part of Update Tuesday to resolve this vulnerability in all affected editions of Windows. Customers who have Windows Update enabled and who applied the latest security updates are protected automatically. The Security Update Guide was updated on October 16, 2017 to provide full disclosure on this vulnerability in accordance with a multi-vendor coordinated disclosure.
List of affected routers and the current patch status is here:
https://www.kb.cert.org/vuls/byvendor?searchview&Query=FIELD+Reference=228519&SearchOrder=4
Thanks for posting. There are a couple of things to keep in mind with that list, however. First, I notice the “unknown status” entries in the bottom half of the list all show the same “date updated” as “date notified”. I’m assuming this means a lot of those devices are actually NOT updated.
Also, the fact that a company is listed as having released an update doesn’t mean they’ve released it for all their products. There are tons of out-of-support routers out there….
Hmmmm… ZTE doesn’t appear anywhere. Should I interpret that to mean my router isn’t vulnerable (?)
Thanks, that was what I was looking for…
When will be able to use this attack with aircrack-ng to get our neighbors wifi code? :D
would be nice if there was a list of vulnerable and patched devices to publicly shame and avoid manufacturers that don’t fix security holes. looks like Mikrotik is the only who has fixed it so far…
I don’t use Wi-fi much and connect the laptop using an Ethernet cable. I’m also using a VPN now having signed up to Mullvad recently.
My phone though is one of the budget type models which only gets updated once every five months. So although my bank badgers me repeatedly to install their mobile banking app, I’ve declined to do so because of the ongoing vulnerabilities which don’t get fixed quickly enough.
The PDF file Martin linked to points out that Android 6.0 is especially vulnerable to this kind of attack and although I have 6.0.1 the difference between them appears to be primarily cosmetic: http://pediaa.com/difference-between-android-marshmallow-6-0-and-6-0-1-2/
I guess I’ll have to be a little more frugal with my 3GB data package so that I can avoid using Wi-Fi, or at least until my ISP updates the router they provided me with as part of my contract.
>https://www.youtube.com/watch?v=Oh4WURZoR98&t=2m22s
>due to an implementation bug android and linux will use an all zero encryption key
Well at least WPA2 itself is not broken, just developers again not being able to write code according to specs. I hope they release the python attack script fast so I can pentest my OWN networks to see if I’m affected.
Best article in a while, thanks Martin!
Addendum:
Not broken in these sense that the original WPA2 password should remain safe. He basically just redirects you to his AP and other channel.
TLS, HSTS and DNSSEC should keep people safe even if they browse a different network than their own. The sslstrip against some poorly configured website doesn’t scare me much. He won’t be able to strip the “lock icon” off a Google site, not on my phone.
@Richard Allen:
>lowly Cat5e
Please elaborate why people would call 1Gbit/s ethernet lowly? Wifi is the inferior type of connecting devices.
And yes I see what you are getting at, but he cannot penetrate the original network. That is all I care for. As long as the WPA2 password is not compromised, all he can do is listen to un-ecrypted traffic of poorly configured websites. Certainly not Google and not Paypal.
@Richard Allen:
Touché Allen and thanks for the follow-up :)
My biggest beef with wifi is the poor range on the empty 5GHz band, and the speed loss due to too many devices on the more popular 2.4GHz band.
I’m still trying to see how this could hurt a person with Chrome / Firefox for Android. They are both very safe mobile browsers. A cool, but impossible attack vector would be pushing fake updates to a phone, but I’m sure the playstore is completely over HTTPS.
So unless you send passwords over plain HTTP, or use some terribly old websites that are vulnerable to HTTPS-Downgrade-Attacks you should be cool.
Mentioning again: https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
“The HSTS Policy helps protect web application users against some passive (eavesdropping) and active network attacks.[13] A man-in-the-middle attacker has a greatly reduced ability to intercept requests and responses between a user and a web application server while the user’s browser has HSTS Policy in effect for that web application.”
So yeah it is a client side security “disaster”, but other layers of security *should* give you an extra layer of protection making the damage zero.
Example of a good website with HSTS:
http://www.ghacks.net:HSTS 0 17455 1539699349950,1,0,2
Sorry, one more observation. :-D “he cannot penetrate the original network”
“The attack allows a third-party to eavesdrop on WPA2 traffic, but if the WiFi network is configured to use WPA-TKIP or GCMP encryption for the WPA2 encryption, then the attacker can also inject packets into a victim’s data, forging web traffic.” – bleeepingcomputer
“the lowly Cat5e†is sarcasm. When I bought my desktop the summer of 2016 it seemed like it was the only desktop on planet Earth without Wi-Fi and Bluetooth. Having a wireless desktop is not something I was concerned about or even desired. Besides, 2′ of cable is all I need for a connection.
Another quote I found by Kevin Beaumont @ doublepulsar[.]com
“It is patchable, both client and server (Wi-Fi) side.
Linux patches are available now. Linux distributions should have it very shortly.
The attack doesn’t realistically work against Windows or iOS devices. The Group vuln is there, but it’s not near enough to actually do anything of interest.
There is currently no publicly available code out there to attack this in the real world — you would need an incredibly high skill set and to be at the Wi-Fi base station to attack this.
Android is the issue, which is why the research paper concentrates on it. The issue with Android is people largely don’t patch.â€
@HK-Rapper
‘Because the vulnerability in establishing the WPA2 handshake affects the protocol itself, even devices with a perfect protocol implementation are affected.” – bleepingcomputer
As it turns out I blundered into making a good choice when I decided to use the lowly Cat5e on my desktop. ;)