Hacker News new | past | comments | ask | show | jobs | submit login
Predicting, Decrypting, and Abusing WPA2/802.11 Group Keys [pdf] (usenix.org)
243 points by hadronzoo on Oct 15, 2017 | hide | past | web | favorite | 49 comments



WPA2 is toast.

Ref to the CVEs that will make a lot of network admins hate Monday: https://twitter.com/nick_lowe/status/919527451570638848

And some background: https://eprint.iacr.org/2016/475.pdf


Also worth nothing that the attack in the OP is on TKIP, but the KRACK attack that will be revealed tomorrow is based upon problems with the RNG (the example RNG, which apparently everyone used, is trivial to break and the protocol is also kind enough to provide you with a huge chunk of the entropy used in seeding the RNG. D'oh!)


This comment should be made the top comment. Thanks for the information.

I guess this implies not "only" passive eavesdropping but also network access in environments without a MAC address filter (not that these can't be spoofed regardless)?


Spoofed yes but they're hard to guess in advance without prior knowledge of the device's MAC address.


MAC addresses are broadcast in the clear regularly, so any device doing that without some randomization is ripe for the picking.


Worth noting also: You vannot randomize it when connected to a Wi-Fi network.


WPA2 in general, or just WPA2-TKIP?


WPA2 in general. The 4-way handshake is vulnerable. Might be patchable, but there is a ton of embedded stuff out there that will never get updated...


It has already been patched by some vendors, but you're right, if the IoT has given us anything, it's tonnes of unpatchable consumer gear.


I guess the question is whether only the AP needs to be patched or the client as well.


In fact it is only clients that need patching. However, sometimes AP's are also clients. Disable any such features if you have them and are not depending on them.


> WPA2 is toast. No it is not. It is "just" one part of the 4 way handshake.

Source: https://www.krackattacks.com/


"We initialize the random number generator with the system uptime, then use it to make crypto keys" - really?!?

"We also publish the system uptime in an unencrypted broadcast message to save you the effort of even bruteforcing it".

Does nobody do security reviews on this stuff, or are these weaknesses there deliberately?

The line between incompetence and malice really is thin here...


And on a device equipped with a radio, it's not very hard to generate entropy.


The radio might not be exposed to the OS. If it's a Fullmac device, you usually don't have access to the radio stuff. Even with Softmac, there's not a guarantee.


I am sure that's a problem on the client, but on the AP, the manufacturer controls both the hardware and the OS.


Not necessarily. Again with fullmac devices you don't control the complete hardware.


Yeah but if you are Cisco, Netgear or DLink, and tell your supplier that you want a function to access noise in the signal, or you want to get a true random number based on that noise, I am sure they could accommodate in future generations of their chip at an insignificant cost.


This is a 2016 paper. Tomorrow's details are apparently about forcing nonce reuse in most WPA2 implementations. Don't let the date fool you into thinking it's old news being discussed!


Details for tomorrow's WPA2 attack will be published to: https://www.krackattacks.com/


Here is a good summary of the situation right now: https://www.alexhudson.com/2017/10/15/wpa2-broken-krack-now/


I understand that the info to answer my question may not be public yet. I would greatly appreciate an an answer by someone who can explain when it is.

If an attacker had recorded encrypted WiFi traffic in the past and then performed one of these attacks could they see the traffic? (I know TLS is used for a lot of traffic, but in time that will be broken too.)

It seems to me that a patient attacker could gain a lot of sensitive info given enough time. Is this assumption flawed? I would love to hear why/why not. (Nonces make decryption of large amounts of TLS traffic impractical?) What about the impact of just knowing DNS lookups? (Real world info on DNS caching? Does DNSSEC stop this? Is it widely implemented?) What if a data broker recorded a lot of encrypted WiFi traffic at a public place like a mall? (Could they learn MAC addresses? mDNS device names? DNS lookups? I bet a lot of tracking cookies and other advertiser tokens don’t bother with TLS which could get them emails and more.)

Someone recording encrypted WiFi traffic from a sensitive network may have enough motive to do something this long-term and the attack would be (electronically) undetectable. Most people rarely change their passwords and at a minimum this would give an attacker knowledge of the internal network, intranet sites, and services used by targets.


I expect they could, yes; WPA2 doesn't offer forward secrecy.

But WPA2 never offered much anyway. If you're on mall wifi, you can already see unencrypted traffic for everyone else, because the client keys are derivable from the shared passphrase (which presumably everyone at the mall has been told) and overhearing the four-way handshake when someone joins. And! You can even fake a disconnect message that forces the four-way handshake to happen again, if you weren't around when the client originally joined.

All of which is to say, WPA2 in passphrase (PSK) mode never actually provided meaningful encryption against other people on the network. :( Someone forgot to tell the protocol designers that Diffie-Hellman exists. Using Diffie-Hellman would achieve both removing the exploit where you observe the four-way handshake, and providing for forward secrecy too.


> * If you're on mall wifi, you can already see unencrypted traffic for everyone else*

Without contradicting your observation, I want to mention that virtually anything important you do on the Internet these days--from online banking to Google searches to reading Hacker News--is protected by a second independent layer of encryption: HTTPS. I'm not excusing the WPA2 flaws, but I do think that your bank info, web searches, and Hacker News comments are secure even at the mall.

If someone can offer a credible explanation of why online banking or other HTTPS activity is insecure on public wifi, I'd like to hear it please.


If you don't have extensions that force HTTPS on all content, you could, for example, get served a malicious image file.

from the article:

> they won’t be able to pretend to be a secure site like your bank on the wifi, but they can definitely pretend to be non-secure resources


You're right, though you're being a little rose-tinted about the situation. I think amazon.com shopping turned on redirects from HTTP to HTTPS last year sometime -- before that they would even redirect from HTTPS to HTTP. That means that until last year, in most instances, your coworkers or your fellow coffee shop customers could see which items you were considering buying online on Amazon. That's really, really bad!

Also, HTTPS doesn't protect domain names. If you're making TLS connections to (e.g.) a porn site over WiFi, the other people sharing your connection don't need to decrypt your traffic to know what you're doing.


Update: It looks like the General answer is no, these attacks require interaction with the client at the time of exploitation to defeat the crypto. (I could be totally wrong however as I don’t understand the crypto.)

Update 2: Apparently anything captured along with the device handshake can be decrypted after the fact if the attacker learns the password used at that time. (Source: https://www.google.com/amp/s/mrncciew.com/2014/08/16/decrypt...) So to decrypt all traffic an attacker would only need to compromise any machine which has the password saved. (Assuming they see the handshake for the device connection.) This indicates that regularly rotating the password (To something unpredictable) has some limited value.


The article says that only WPA2-TKIP is vulnerable to the downgrade, therefore running WPA2 with only AES should be fine.


Stay tuned for tomorrow's KRACK announcement, then.


Here's the CCC talk with the author of this white paper: https://www.youtube.com/watch?v=KJWd-_BDC_g


There are also a BlackHat Europe 2017 paper that is apparently a strong foreshadowing on the attack.



Well, if there's one piece of (somewhat) good news around this and https://www.krackattacks.com/, it's that TLS and VPNs will become even more common.

Where did WEP and WPA2 come from, anyway? What's the historical reason we aren't all using TLS to connect to our APs?


> What's the historical reason we aren't all using TLS to connect to our APs?

Because it’s insanely impractical for home use? Hey, here’s your new WiFi router. Just install this new root CA on all your devices, create a device cert for each machine and install that very as well, and don’t forget you need to re-do this every year...


Trust keys on first use. Like SSH.

https://www.tedunangst.com/flak/post/moving-to-https

"So how does one verify that the downloaded cert is the original? The same way the CAs do. Perform a DNS lookup, make a web request, trust the result. The addition of HPKP would indicate that people find the CA model untrustworthy, solving the problem with trust on first use key continuity. Why not cut out the middle man? Protesting the CAs is admittedly pretty futile, but if I can’t do it, who can?"


The router isn’t the issue here the clients are.


I'm thinking of a mechanism where the router obtains a trusted cert automatically, like Plex does (https://blog.filippo.io/how-plex-is-doing-https-for-all-its-...), and then asks users to authenticate by password over TLS before allowing access to network resources.


that only works because there's a central registar of plex users. im not sure how this can be done ad-hoc for APs. anyone can choose any ssid, so you'll need a global registar of ssids. The system will inevitably need to charge for registrations, otherwise bad actors would squat short and memorable ssids. a preshared key is much more feasible.


My guess is that for most people, provisioning a wireless network using a shared secret (or just a button press, ala the broken WPS) is easier than having to setup a CA and sign/distribute certificates. (Not defending WEP or WPA in anyway)


Ignoring the real concern about certificates, and if tls is appropriate for a packet oriented unreliable transport (maybe dtls, then?) consider what version of openssl (or an embedded tls stack) was available when your access point entered development; is that version considered secure today, does it support any ciphers that are considered good practices or even acceptable today?


The only reason TLS works is because of CAs. What could be the CAs for APs?


WPA2 Enterprise use a central RADIUS server for authentication, with separate credentials for each user, and a (separately-distributed) certificate for the server.

It's just not practical for consumer and small-business setups.


Somewhat true. Setting up a Freeradius is not hard. Problem is that you need another device that is running 24/7.


The RADIUS server can run on the router/AP without compromising practical security in most cases.


The bit that's less practical for consumer setup is more the cert distribution and setup of separate credentials for each user. (The RADIUS server could even be built into the router in a consumer product.)


That's not needed, trust on first connect.


and what do you do if the certificate mismatches? 99% chance the average person will click through the warning because they want internet now.


Correct. You can't solve every problem with technology.


Because WEP and WPA were designed to provide (just) encryption but to provide access control.

The problem with TLS is that it’s client authentication kinda sucks and isn’t easy to manage.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: