Live data from Hacker News

Key Reinstallation Attacks – Breaking WPA2 by Forcing Nonce Reuse

krackattacks.com

241–250 of 424 posts

Re: Key Reinstallation Attacks – Breaking WPA2 by Forcing Nonce Reuse

#241

This is not an end-of-the-world type vulnerability. 1. Does not affect long-term credentials - certs, wifi passwords are still safe. Rather, confidentiality (secrecy) from client --> AP is affected, and in some cases packet forgery is possible (integrity). 2. Actually accomplishing this attack, for now, requires special and expensive hardware (med to high range SDR gear). Its also not that reliable outside of a lab e…

Where did you find the information that it needs SDR? I couldn't find it in the paper (but I didnt fully read it) or the website.

Speculating. I don't think SDR is needed. Logically, all you need is a WiFi card that lets you do fairly standard things with the WiFi frames.

Re: Key Reinstallation Attacks – Breaking WPA2 by Forcing Nonce Reuse

#242

As an Android user is there any mitigation for this other than ditching my handset and switching to an iPhone or waiting (hopelessly) for a patch from my vendor. This really does highlight the absolute disaster zone that the Android handset market has become as far as updates are concerned. I'm sure the Pixels will get a fix relatively quickly but almost every other Android user is going to be left in security limbo.

I appreciate this is coming from a UK perspective and that not everyone is this lucky, but I don't remember the last time I used public WiFi on my phone thanks to a general mistrust of it and the fact that 4G (or at least HSPA+) has very good coverage here.

Same here (Devon, UK) — although I do use the WiFi we have on buses here, and occasionally when in cafés.

Re: Key Reinstallation Attacks – Breaking WPA2 by Forcing Nonce Reuse

#243

Have I got this right in lay-mans terms. The client is forcibly disconnected from the WiFi network and reconnects to the attackers network instead. The attacker doesn't need to know the WPA2 password but it accepts the connection setting the encryption to zeros. The client thinks it is connected to the original wifi network and continues as normal. Wifi traffic is intercepted and unencrypted.

> The client is forcibly disconnected from the WiFi network and reconnects to the attackers network instead.

The client is tricked into moving to what it thinks is the same WiFI network running on a different channel, but is actually the attackers network instead.

> The attacker doesn't need to know the WPA2 password but it accepts the connection setting the encryption to zeros.

The attacked doesn't need to know the WPA2 password and (for Android and Linux clients) the client then defaults to an encryption key of all zero bytes.

> The client thinks it is connected to the original wifi network and continues as normal.

Yes.

> Wifi traffic is intercepted and unencrypted.

Wifi traffic is intercepted and can be decrypted (since the encryption key - all zero bytes - is now known).

Re: Key Reinstallation Attacks – Breaking WPA2 by Forcing Nonce Reuse

#244

Have I got this right in lay-mans terms. The client is forcibly disconnected from the WiFi network and reconnects to the attackers network instead. The attacker doesn't need to know the WPA2 password but it accepts the connection setting the encryption to zeros. The client thinks it is connected to the original wifi network and continues as normal. Wifi traffic is intercepted and unencrypted.

Not quite: The attacker watches for the initial client->AP encryption negotiation (or forces it by forcing a disassociate), records one step of that negotiation and replays it to the client. That has the side-effect of causing the client->AP traffic to re-use encryption keys. Since WPA2 encryption is a stream cipher, re-using keys opens it up to a known-traffic analysis attack, which allows a listener to decrypt the traffic. So, the user is still connected to their existing AP, but since they're re-using keys, attackers can decrypt the client->AP communication.

There's no need for a second AP in all this, just someone in range of the client who can replay packets to the clients.

(Good TLDR here: https://blog.cryptographyengineering.com/2017/10/16/falling-... )

Re: Key Reinstallation Attacks – Breaking WPA2 by Forcing Nonce Reuse

#245
post #37

Earlier quoted context omitted.

Sounds like a "we technically respected the embargo, just not in principle" sort of thing to me.

We're not mind readers. If he says it's ok, we think it's ok. If other vendors have fucked up months long patch cycles, that's their deal, not ours.

What part of this commit description is "not revealing details"? https://ftp.openbsd.org/pub/OpenBSD/patches/6.1/common/027_n...

Re: Key Reinstallation Attacks – Breaking WPA2 by Forcing Nonce Reuse

#246

Earlier quoted context omitted.

Currently the only mitigation is to constrain your browsing to properly configured https (SSL) web sites.

You can (try) to restrict your browsing to HTTPS sites only. But it's very difficult to ensure that all the communications your device is making (background services, vendor apps...) go through that channel.

If only there were some certification body that ran an App Store with rules against unencrypted traffic...

Re: Key Reinstallation Attacks – Breaking WPA2 by Forcing Nonce Reuse

#247

As an Android user is there any mitigation for this other than ditching my handset and switching to an iPhone or waiting (hopelessly) for a patch from my vendor. This really does highlight the absolute disaster zone that the Android handset market has become as far as updates are concerned. I'm sure the Pixels will get a fix relatively quickly but almost every other Android user is going to be left in security limbo.

As others suggested ensure that all communication uses TLS (be it https et al or tunnel traffic through a VPN). Also you could install a better version of Android on your phone rather than an outdated vendor version. That will probably fix more security related issues than just this one :)

Vendor version contains blobs (binary objects) for drivers which are most often than not a problem to deal with for OSS and cause various bugs. It's usually workable depending on vendor and hardware but not exactly a perfect solution either.

Re: Key Reinstallation Attacks – Breaking WPA2 by Forcing Nonce Reuse

#248
post #224

The research talks a lot about how it somewhat depends on the implementation of the wireless client, but only in regards to Linux and OpenBSD, anybody know what the status on the Windows implementation is?

>anybody know what the status on the Windows implementation is? Seconding this. I wonder if it is something fixable at the OS level, or if individual WiFi drivers need to be updated too. Would love to see someone throw together a list of OS', Routers, and other WiFi stuff that is known to be patched/unpatched/unknown.

Answering my own question: looks like someone is tracking it over here: https://char.gd/blog/2017/wifi-has-been-broken-heres-the-com...

Microsoft's status is unclear at the time of writing.

Re: Key Reinstallation Attacks – Breaking WPA2 by Forcing Nonce Reuse

#249
post #134

Earlier quoted context omitted.

Even for a more modern smartphone. I don't want to lose access to my 32bit apps by migrating to iOS 11. So I hope a patch for iOS 10 will be made available.

Out of interest, what apps are you using that are still 32bit only?

Not the OP, but I just lost access to FlightTrack which was an awesome flight search and status monitoring app that could even pull your itinerary from TripIt.

Re: Key Reinstallation Attacks – Breaking WPA2 by Forcing Nonce Reuse

#250
post #221

Earlier quoted context omitted.

Fortunately, SSL/TLS (with HSTS) does not depend on your local DNS resolver being secure.

HSTS only works if you have visited the site before or it is hard coded (see Chrome and Google services for example). Reality is that DNS remains and will continue to remain a giant hole in TLS.

All major browsers implement HSTS preloading, and getting added is quite simple. A very large percentage of your average internet user's traffic is covered by this.
Post reply on HN