Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Key Reinstallation Attacks – Breaking WPA2 by Forcing Nonce Reuse

krackattacks.com

Post reply on HN
Print view View original

381–390 of 424 posts

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

#381

Post by CapacitorSet »

g-clef wrote: post #244
andygambles wrote: post #193

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…

>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.

How would you drop packet 3 without a new AP?

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

#382

Post by twitchyliquid64 »

panarky wrote: post #287
twitchyliquid64 wrote: post #162

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…

> 3. Everything you care about _should_ be going over TLS, which mitigates all effects of this attack. This is probably the biggest misconception. Many, many websites and APIs don't have HSTS enabled to force all connections to use TLS. The author demonstrates using sslstrip to downgrade the connection of match.com to steal credentials. How many people watch the green "secure" indicator in the URL bar to ensure it do…

> Many, many websites and APIs don't have HSTS enabled to force all connections to use TLS.

True. Yet another reason for us to push for it.

I have a chrome extension that sets the background-color of all form fields to red if the site it was served on or the ACTION attr are not https.

That said, pretty much every website in my day except for casual reading is pinned to TLS. APIs are the notable exception you pointed out, but otherwise HSTS is quite widely used, and especially effective with preload lists.

> How many thousands of apps dont have this indicator to observe?

Sure there will be some, but your standard Java apache client (along with 99% of the libraries used in Apps) dont have this kind of downgrade behaviour. If they expect validated https, they will fail without it.

> This is a severe vulnerability.

Yepp :D Not the end of the world. I think the main fallacy here is the implicit assumption that the link layer is secure. That has never really been the case and a broken wifi model is merely one more testament to this fact.

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

#383

Post by ryao »

Just a FYI. Certain enterprise access points that implement counter measures against rogue APs should be able to thwart this attack. Here is a link to documentation of the feature in one such vendor’s products:

https://docs.ruckuswireless.com/unleashed/200.5/t-EnablingDi...

The AP will begin broadcasting deauth frames against the rogue AP as long as it sees it. There are probably some edge cases, but I would expect either the rogue and real APs will fight over the clients indefinitely (thwarting information leaks) or the attack code will trigger an exception and crash because what programmer would expect the client to immediately disconnect?

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

#384

Post by firewall-bad »

krrrh wrote: post #375
firewall-bad wrote: post #348

Earlier quoted context omitted.

"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." Using a VPN is the best way to mitigate this until your device is patched, assuming you trust your VPN provider or run your own VPN. Edit: Actually, even if you don't trust your VPN provider, you'll be protected against this attack (KRACK), given their client is implemented…

> given their client is implemented properly. Unfortunately this is a big part of trusting your VPN provider. It’s shocking how bad the situation is, especially it seems on those marketed via Android apps. [1] [1] https://arstechnica.com/information-technology/2017/01/major...

Well the VPN ecosystem has an enormous long tail - the paper you cite tested 283 (!) apps. It's unfortunate but somewhat expected that a significant number, especially the ones that haven't been around for long, would have issues.

I'm sure, given the size of that list, that they tested some of the biggest players on the VPN space. I think it'd be good to know which apps were tested and didn't show any issues, especially in light of Krack and the Android bug on wpa_supplicant.

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

#385

Post by ghettoimp »

trustzone wrote: post #276

Matthew Green's blog on why it happened and how it escaped detection is a really good read. https://blog.cryptographyengineering.com/2017/10/16/falling-...

"One of the problems with IEEE is that the standards are highly complex and get made via a closed-door process of private meetings. More importantly, even after the fact, they’re hard for ordinary security researchers to access."

While I'm sure this can't take much of the blame, it sure strikes a chord. The IEEE standards process seems insanely archaic and broken in the open-source era.

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

#386

Post by yuhong »

dfox wrote: post #313
SaltySolomon wrote: post #74

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?

I'm not sure that there even is "Windows implementation" of this. For a long time each driver implemented it's own 802.11 stack.

I believe that the code for the 4-way/group key handshakes etc is part of Windows even in XP, though there was the option of using your own supplicant before Vista.

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

#387

Post by foobaw »

sequence7 wrote: post #102

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.

Disclaimer: Used to work for an OEM

With critical bugs like these, it's certain Google will require recent devices that have enough affected users to be updated ASAP. Expect an update within in a few weeks.

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

#388

Post by rphlx »

ghettoimp wrote: post #385
trustzone wrote: post #276

Matthew Green's blog on why it happened and how it escaped detection is a really good read. https://blog.cryptographyengineering.com/2017/10/16/falling-...

"One of the problems with IEEE is that the standards are highly complex and get made via a closed-door process of private meetings. More importantly, even after the fact, they’re hard for ordinary security researchers to access." While I'm sure this can't take much of the blame, it sure strikes a chord. The IEEE standards process seems insanely archaic and broken in the open-source era.

It is, arguably, pretty broken even in some closed-source arenas. For instance if your objective is to have the IEEE first define thorough, carefully reviewed standards which are then closely and widely implemented throughout an entire industry, 25G and 50G Ethernet were abject failures.

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

#389

Post by rphlx »

foobaw wrote: post #387
sequence7 wrote: post #102

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.

Disclaimer: Used to work for an OEM With critical bugs like these, it's certain Google will require recent devices that have enough affected users to be updated ASAP. Expect an update within in a few weeks.

The problem is that "recent" seems to mean <3 years old, and often, <2 years old. But there are still millions of active Galaxy S3s, S4s, S5s, etc.

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

#390

Post by willstrafach »

mceachen wrote: post #345
pnutjam wrote: post #204

Earlier quoted context omitted.

Any https traffic is going to be safe from this attack, a VPN would also protect you.

From TFA: Although websites or apps may use HTTPS as an additional layer of protection, we warn that this extra protection can (still) be bypassed in a worrying number of situations. For example, HTTPS was previously bypassed in non-browser software, in Apple's iOS and OS X, in Android apps, in Android apps again, in banking apps, and even in VPN apps.

This only applies to apps which screw up validation of TLS certificates. There is an unfortunate amount of them, but certainly does not apply to all apps (and not an issue for websites).

Either way, this disclosed vulnerability only involves link layer man-in-the-middle in order to collect traffic. Active manipulation of traffic (Required for TLS intercept) is more complicated.

Post reply on HN