Key Reinstallation Attacks – Breaking WPA2 by Forcing Nonce Reuse | Hacker News Reader

Key Reinstallation Attacks – Breaking WPA2 by Forcing Nonce Reuse

krackattacks.com

1,371 pointsfanfantm411 comments

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

> Representation of the 4-way handshake from the paper by He et al. Yes, I know you’re like “what?“. But that’s why people who do formal verification of protocols don’t have many friends.

+1 for a good read, really enjoyed his writing style.

For those unfamiliar, Matthew Green is a cryptography researcher and professor at Johns Hopkins.

Edit: TIL John's' Hopkins ty /u/dEnigma

It's actually "Johns Hopkins". The story behind the name is somewhat interesting:

http://www.hopkinsmedicine.org/about/history/history1.html

"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's been years since I was involved with the organization side of the Standards Association, but there was a lot of frustration among staff because the vendors (and stakeholders in general) often had a vested interest in keeping the process broken. IEEE as a whole had a weird relationship with Standards as well. A somewhat related example is that it took staff years to get permission from all the vendors to release the full MAC address allocation database after agreeing to keep it non-public. In general you can probably assume that people who work for Standards are even grumpier about the whole nightmare than people outside the process. It's sort of a perverse form of regulatory capture where the "agency" is still trying to do the right thing, but they're locked in by their constituency.

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.

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.

This is one of those things that should be better with modern handsets and the security patch level for Android. Hopefully a fix for this is included in the November set.

In general most bigger manufacturers have been somewhat decent in updating their flagship devices. With a Sony flagship from the last 18 months for example, you usually won't run more than two months behind on security updates. Samsung is similar if I remember correctly. Hopefully a big exploit like this will be enough of a kick in the butt to get manufacturers releasing security updates faster.

I have a HTC 10, a flagship device that's barely a year old the fact that I now have to wait a couple a months for a patch to what is clearly a critical vulnerability is just ridiculous. The fact that anyone without a flagship device should now throw that phone away because it will probably never be patched is despicable.

I totally agree with your hope that this will kick both the manufacturers and Google in the butt enough to get something done about this. I don't like our chances though!

To underline your point, even my Nexus 5 (_from Google_), which is a little less than 3 years old, will never receive security updates. And one of the main reasons I chose the Nexus was to be sure to get updates on time. Except for the security vulnerabilities, everything of the device is totally fine. It's such a waste of resources… (In this case I at least have an alternative in the form of Lineage OS, which will only cost me time and nerves for the migration.)

The Nexus 5 was released 4 years ago. At the same time the iPhone 5C was released. The 5C also won't receive a patch for this.

There is a problem with handset abandonment, but this is true across all vendors, and it does not underline sequence7's claim that this is solely an Android problem.

Last I checked, LineageOS for the Nexus 5 is still vulnerable to CVE-2017-9417 (Broadpwn). LineageOS might work for keeping the userspace up-to-date, but their kernels are still largely dependent on the upstream vendors. If the problem is in a firmware blob, as is the case with Broadpwn, you are pretty much guaranteed to be SOL without vendor support.

You'd expect better from the horse's mouth, but most other companies are worse. I got a Fairphone 2 and my partner a Wileyfox Swift 2X. Both have very good software support thus far. Near monthly updates. Wileyfox phone is a bit new, but they got a good track record. Nokia (HMD) also seems to be back, this time with good software support (thus far). Compare that to Motorola.

Hopefully Android Orea 8 with Project Treble will stop this ridiculous trend for the rest of us. Together with the smartphone market being saturated (budget phones of 200 EUR are very decent these days), we may end up with long term support on older yet still decent devices.

On the bright side, Nexus 5 has a lot of community support. So, as you've stated, there are decent ROM alternatives like LineageOS that are actively maintained to implement these patches.

Fortunately the term "flagship" doesn't promise anything about support, patches or security.

It's just a word that means you paid more for having all the bells and whistles that the OEM could offer at the time, instead of going for the next-best model or such.

Fortunately, whether you can afford the best of the best with all the optional extras or a cheaper second-tier model doesn't affect the security of the device. And it shouldn't, because if you can't afford a "flagship" device, doesn't mean you can afford to get hacked either.

Unfortunately, while the security-update frequency ought to be comparable, it turns out that it's mainly comparably bad :-/

LineageOS has got your back:

https://download.lineageos.org/pme

this is why I am rooting for initiatives like PostmarketOS [0] and similar initiatives in the hopes ot break this mentality that every year we need to buy new hardware in order to stay secure.

[0] https://www.postmarketos.org/

"With a Sony flagship from the last 18 months for example, you usually won't run more than two months behind on security updates."

That's still truly terrible compared to Apple's legacy device support. iOS 11 and future patches still support even the iPhone 5s, a phone from 2013.

According to https://char.gd/blog/2017/wifi-has-been-broken-heres-the-com... it will be in the November 6 Android patch level.

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.

Pray for a vendor patch. The fix landed today in the hostap repository:

https://w1.fi/cgit/hostap/commit/?id=a00e946c1c9a1f9cc65c729...

Does this resolve the issue on the AP side of things? Could I theoretically have an AP update that would resolve this with no need to update clients?

Both APs and clients need to be patched[0]. Mitigations are possible on AP side if no updates are available[1].

[0]: "Finally, although an unpatched client can still connect to a patched AP, and vice versa, both the client and AP must be patched to defend against all attacks!"

[1]: "you can try to mitigate attacks against routers and access points by disabling client functionality (which is for example used in repeater modes) and disabling 802.11r (fast roaming)."

Unfortunately no, from what I understand this is primarily an attack against clients.

Ah yes, I see now that the patch is actually to wpa_supplicant.

Well, hopefully this means no kernel patch will be needed.

I know it's not ideal nor user friendly, but you can get a device that is supported by lineage os.

You get updates every week.

Since this is fixed by a patch to wpa_supplicant LineageOS does fix it, but it is pointed out elsewhere in this thread that Lineage is still vulnerable to older hacks like broadpwn on many devices since they have a hard time patching kernel-level vulnerabilities without vendor participation.

Your advice is valid, but it’s important to not have a false sense of security.

I wasn't aware of that, thanks

You should be good if you’re up to date as of November 6th (I think, it may be November 8th) Swiftonsecurity tweeted this out, it’s a description of KRACK and various devices affected by it. Apparently google already fixed it on android? Also it says that iOS is rumored to be protected against this since iOS 11 but it’s not confirmed. Nobody has put out an official statement yet. What’s weird is that commercial vendors like Ubiquiti UniFi (I use them myself) have already released fixes for their APs but the paper says that clients should be the priority and get fixed from KRACK ASAP. And it’s weird because I don’t know of any client-side fix released in the wake of KRACK being public. https://char.gd/blog/2017/wifi-has-been-broken-heres-the-com...

October 6th/8th, you mean?

I found it interesting that, in his article, he said: "With our novel attack technique, it is now trivial to exploit implementations that only accept encrypted retransmissions of message 3 of the 4-way handshake. In particular this means that attacking macOS and OpenBSD is significantly easier than discussed in the paper"

but elsewhere it said recent versions of OS X and iOS are not impacted. I wonder if the "safe" OSes are only vulnerable to the blocking/replay but not the decryption of data?

My UniFi AP-PROs show up today so I'll make sure to update them first thing.

Also, I'm having a bit of a hard time understanding the attack. It sounds like he forces them to connect to his AP, performs the attack, then allows them to connect to the intended network with the zeroed key, THEN is able to sniff that client's traffic because he knows their key? If I understand correctly, this means he cannot sniff the whole network's traffic, only the traffic between the attacked client and the AP? This makes me wonder about the meaning of a pre-shared key, but I'm guessing the PSK is only used to setup the relationship between client and AP, and then after the initial connection/pairing the pre-shared key is no longer used...

> Also, I'm having a bit of a hard time understanding the attack.

He forces them to connect to his own AP and forwards all traffic to the destination so that the client is unaware it has been redirected.

He then forces the client to re-install the key which (on anything that is derived from wpa_supplicant e.g. Linux, Android, etc) the client has blanked out after first use, so the key it reinstalls is now all zero bytes.

He can continue to forward the traffic to the destination so that the client gets responses, but now he can decrypt all of the traffic too.

For clients that re-install the correct key (which the account does not recover in any way) the attacker has to rely on snooping enough encrypted data in order to perform a birthday attack as the key re-installation also resets the frame counters which leads to nonce-reuse which is a problem in ciphers like AES-GCM.

This blog post explains it a bit:

https://blog.cryptographyengineering.com/2017/10/16/falling-...

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.

This is about WiFi "protected" with WPA2: basically treat it as suspiciously as you would any public WiFi.

If you choose not to use public WiFi because you can't "trust" it, then you now need to stop using your private WiFi too (until your systems get appropriate patches).

Don't forget the fact that carriers are now snooping your 4G data and selling it to advertisers. It has been a bad week for privacy.

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

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

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.

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 :)

How would you make sure that apps use TLS for comunication? In the browser it's easy to see, but in apps those details are hidden away from the user.

Sniff the apps, uninstall if they don't, it's just plain unacceptable at this point. If there's something you really need that doesn't, set up a VPN.

Use a VPN, a commercial one that actually works, like F-secure Freedome.

I orded a librem5 for this among other reasons. https://puri.sm/shop/librem-5/

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

This issue is two-fold right. You can install plugins that force SSL client side (on the main site and any AJAX calls thereafter) but like you said you have no idea what calls that site is making server side. They could be sending everything you send them over plaintext after the initial TLS secured request. Rough times.

Luckily, the servers past the initial SSL link won’t be using wifi, so at least you won’t be any worse off than before.

Or using a VPN.

It was quite nice to let a wifi router be the VPN client to offload it from all your laptops/phones/etc. and better guarantee "VPN always on".. so much for that.

Too bad DNS doesn't fall under properly protected against local attacks.

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.

Fail-safe is indeed the preferred option here, yet the resulting Denial of Service is still unpleasant.

Install one of the major ROMs like AOSP or LineageOS. Relying on your vendor for software or purchasing a device that forces you to isn't the best idea these days.

> Relying on your vendor for software or purchasing a device that forces you to isn't the best idea these days.

Relying on the efforts of unpaid volunteers doing their best to hack together binary blobs is also not the best idea...

Not all devices are supported by major ROM distributors, nor is the support guaranteed to be endless or current... (even some devices as major as the Galaxy S6 for example)

Only so much depends on those binary blobs though and changes to, for example, wpa_supplicant, happen at a much higher level.

Agreed, but unfortunately if the difficulty of maintaining/backporting/forward-porting binary blobs means that nobody will release ROMs for your device (anymore), your point is pretty much irrelevant. ;-)

Ubiquity just released a patch for KRACK and soon others will I imagine. From a client perspective, same as always, wait for a patch from your OS vendor. edit: it seems this patch only handles modes where the AP is a client like a bridge or site-to-site. Its still a client-side fix and patching AP's used traditionally won't fix this.

In practice, everything of value should be going over TLS. If you're worried you should be using a VPN on untrusted networks. This attack, if I'm reading it right, doesn't do anything someone on your wlan or lan can't do right now via ARP poisoning and other attacks. So being on that work connection or restaurant wifi is almost the same risk level of this attack.

The thing is, not every protocol offers TLS. Take SMB (network shares) for example... encryption is only offered as of v3 and if a company/university wants to allow Windows 7 clients, they're capped to SMB v2.1.

That's a good example. I guess there's other mitigation at work here. In my case if I'm in a public wifi area and connecting to my work PC then I'm using VPN to access smb. Smb just isn't open to the wifi attacker.

In a case that it is, its curious how you would inject data into a smb stream and not fail checksums from client-side chechking. Maybe its trivial to deal with this, not sure.

If the WPA2 protected wifi network is using AES, which is the most common in my experience, then they won't be able to inject any data. From the Krack website:

If the victim uses either the WPA-TKIP or GCMP encryption protocol, instead of AES-CCMP, the impact is especially catastrophic. Against these encryption protocols, nonce reuse enables an adversary to not only decrypt, but also to forge and inject packets.

True, but what I'm getting at is watching (not injecting/modifying) the username and password fly across the campus airwaves.

Use an always-on VPN?

Always using a VPN should be a mitigation until a patch is released. Should only be a couple weeks out for Pixel devices.

Ditch wifi, go 4G only!

I'm not convinced 4G is more secure.

It does have higher barriers to entry, and penalties for broadcasting unlicensed. Granted, that's both more of an obfuscation than anything else.

Regarding mobile data in the US: https://news.ycombinator.com/item?id=15477286

There are many places indoors where I can get a WiFi signal but no cellular service.

or waiting (hopelessly) for a patch from my vendor

If this is an actual in the wild exploitable issue, there will be patches very quickly for handsets in the support period, as quickly as there is for iOS. This has been the case repeatedly before as well.

What a weird post in general. Maybe wait to complain about this a month down the line or so? Instead it's just effectively noisy rhetoric.

The support period for an iPhone is at least 3 years of regular patches and feature updates. Most Android phones on the market will have a 'support period' of 12 months if you're lucky. My point is that the roll-out of updates to Android is unacceptably poor and inconsistent and relies on optimism on the part of the user.

The use of the word hopelessly was probably unnecessarily dramatic I agree but I'll leave it there so your comment makes sense.

There's a patch for iOS? Wonderful! Oh wait, there isn't.

Did you intend to post that reply to me? Because of course there isn't a patch for iOS yet, and when there is it will leave out hundreds of millions of devices that no longer receive patches. My point was that if one wants to stomp their feet and do the easy "Damn Android" complaint, at least wait until the basis is sound.

Ah, you're right, sorry: that was intended one reply up, where the poster seems to claim that iOS is already patched.

Correct me if I am wrong but basically the attack is against clients, not access points which means simply patching the AP will not do, one would have to patch all of the clients. And the AP patches that are now coming in are probably for client mode, so they fix a certain scenario when the AP is a client which is far from the common one?

Correct for 98%. Clients are the weakest point in the scenario.

Finally a way to get all IoT devices connected to WiFi!

Remember, 'S' in IoT is for Security.

> Remember, 'S' in IoT is for Security.

One of the best quotes I've heard in a while.

Stop panicking (unless you need your daily dose of the End of the World drama).

From the source: In general though, you can try to mitigate attacks against routers and access points by disabling client functionality (which is for example used in repeater modes) and disabling 802.11r (fast roaming).

For ordinary home users, your priority should be updating clients such as laptops and smartphones.

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

Some people don't want read all the articles and tend to panic. It's why if there's any security issue we need a list about action to reduce risk, when, how, etc. otherwise people still we dispute about it's feasible or not and then finally the journalist will explain how to fix the risk. I like to read the whole article but then sometimes it's very hard to check if it's truly feasible or it's just a panic mode, for example when wannacry come out the information was a mess.

What's the practical impact here? What do I do with a normal house with routers, laptops, smartphones etc?

Are manufacturers like linksys, d-link issuing patches now or will it be enough to have windows/os x/iOS/android updates enabled? Or do I need both?

Await your client to be patched. Routers are not so much the problem (unless in Range Externder modus).

„submitted for review on 19 May 2017“ ... „OpenBSD was notified of the vulnerability on 15 July 2017“

Can anyone explain the timeline of releasing such significant security findings? Why is it disclosed to the public 1/2 year after submitting to review? I'd guess the (publicly funded) research behind it is a lot older than that.

For a vulnerability of this magnitude, it's not unusual for a responsible disclosure to have a five month review window.

e.g. Dan Kaminsky's discovery of DNS cache poisoning had a 5 month responsible disclosure embargo.

The intent is to have as many fixes available as possible at the time knowledge of the flaw becomes widespread.

Of course.

From my understanding of research at public institutions there is a long period of time and steps between finding something interesting and submitting a paper for review.

Why not disclose the vulnerability first to concerned parties and then write up a fancy research paper? Why the other way round?

Only two explanations I could come up with: Either there must be a very short time frame between identification of the vulnerability and writing of the paper or there was further research needed. Or....I don't know

July => October.

It's 3 month. It's a reasonable delay if you have to alert lots of manufacturer and they need time to roll out critical patches to lots of devices.

Full disclosure is reasonable, and the only truly effective methodology. Anything else just allows vendors to delay or ignore.

> OpenBSD was notified of the vulnerability on 15 July 2017, before CERT/CC was involved in the coordination. Quite quickly, Theo de Raadt replied and critiqued the tentative disclosure deadline: “In the open source world, if a person writes a diff and has to sit on it for a month, that is very discouraging”. Note that I wrote and included a suggested diff for OpenBSD already, and that at the time the tentative disclosure deadline was around the end of August. As a compromise, I allowed them to silently patch the vulnerability. In hindsight this was a bad decision, since others might rediscover the vulnerability by inspecting their silent patch. To avoid this problem in the future, OpenBSD will now receive vulnerability notifications closer to the end of an embargo.

I'm not convinced it was a bad decision. Why would you want to leave your users vulnerable? It's possible that this has been exploited in the wild.

Seems rather prisoner-dilemma-ish[1].

Up until now, there were no indications that this was being exploited publicly. After a flaw like this gets known (whether through a coordinated disclosure or through OpenBSD's early patch) you can be assured people will be exploiting this.

Do you both stay silent and take the minor risk of your users being vulnerable for a short time longer whilst patching and disclosure is being coordinated with all parties (-1/-1), or do you "betray party B" but get your own users secured as soon as possible (-3, 0).

I think coordination makes more sense in a flaw as big as this.

1: https://en.wikipedia.org/wiki/Prisoner%27s_dilemma

And be sure to note the iterated version which is where things get interesting https://en.wikipedia.org/wiki/Prisoner%27s_dilemma#The_itera... You can already see it in this case, where Theo "defecting" leads to less cooperation in future rounds.

I don't think it is just your users vs. all other users. Why are other vendors not patching as quickly?

In this case, it was not a short time.

This probably hasn't been exploited in the wild. Anyway the point of coordinating disclosure is to leave fewer people vulnerable overall. If one team releases a patch early, attackers can analyze the patch and start using the vulnerability against unpatched systems. Waiting for everyone to patch at once closes that window.

How can you state that it probably hasn't been exploited in the wild with any degree of confidence? It's possible that the same flaw was found and exploited years ago by black hat hackers and/or state security services. We have no way to know whether this actually happened, or even estimate the probability.

Is there a way I can install an open source phone OS on my old Android phones to keep them patched? I'm not prepared to keep buying new phones just because manufacturers only provide intermittent updates for a year or two.

Anyone got any suggestions for options?

> I'm not prepared to keep buying new phones just because manufacturers only provide intermittent updates for a year or two.

You could just ... buy an iPhone and get timely security updates for years.

EDIT: Downvote if you want, but if iOS 11 contains this security fix exclusively and not iOS 10, then an iPhone 5s bought on 20 September 2013 is going to get this fix. If Apple release an iOS 10 update and you bought an iPhone 5 on 21 September 2012 you're covered too.

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.

and force me to use some propietary-built webkit? Nah, thank you.

Having switched to an iPhone recently it does bother me that you can't download iOS updates via 4G. When this gets fixed I need to turn on wifi first (or install iTunes).

LineageOS has a moderately large selection of supported phones for a custom ROM and it has weekly updates. My two and a half year old Moto E has the October 5th security patches for Android.

> My two and a half year old Moto E has the October 5th security patches for Android.

But it has very few kernel security patches: https://cve.lineageos.org/android_kernel_motorola_msm8610

Unfortunately, Google has given app developers a quite powerful tool to disable the use of their apps on non-official OS images, in the form of SafetyNet. So even if you can install an open source version of Android expect a bunch of stuff to no longer work afterwards.

Magisk (/system/less root) currently passes the SafetyNet checks and it, and it's MagiskManager App, are both FL/OSS and hosted on github [0] as well as pre-built images linked from XDA [1].

I'm using it successfully with LineageOS 14.1 (Android 7.1.2).

[0] https://github.com/topjohnwu

[1] https://forum.xda-developers.com/apps/magisk

SafetyNet doesn't actually detect custom ROMs, a stock LineageOS will pass it on most devices at least.

It attempts to detect root or modifications to the ROM by malicious software.

Certain newer devices have secure boot attestation that may cause SafetyNet to fail unless spoofed to be a different device which does not have such attestation.

SafetyNet is not about "official" status, it's about security checks.

I'm actually persuaded that I don't need terminal root access on a device (except for system debugging), but rather a firmware signed with my own release keys, and apps that need privileged access baked in.

I'm using https://lineageos.org/ (previously known as CyanogenMod) on most of my older Devices. I think this is as close to an open source OS as you can get right now.

Depends on the phone. I'm using a ~ 4 year old phone with LineageOS. I also have a Russian phone whose userland source code was never released, and no open source ROM exists; this phone is swimming in vulnerabilities and languishing in Android 6.

Another option is OmniROM: http://www.omnirom.org/

Also fairly actively developed and supports a wide range of devices.

The Wi-Fi Alliance has published an official statement:

'There is no evidence that the vulnerability has been exploited maliciously […].'

That is probably about to change …

https://www.wi-fi.org/news-events/newsroom/wi-fi-alliance-se...

That is very strange for them to say. Unless someone is sitting around collecting full take packet captures of everything going on around them and looking through it all, there would be no way to be aware of this.

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

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

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

Just the traffic between the impacted client and the network, right? Because each client is using a different key (has to be, if we're able to reset just one client's key to all zeros)

> This can be abused to steal sensitive information such as credit card numbers, passwords, chat messages, emails, photos, and so on.

... if transmitted over plaintext http

Note that in the demo video they use SSLStrip to cancel attempts of websites to switch to https.

The only protection here is HSTS (which is not enabled by most websites, but major ones like banks will usually have them) and manually typing https:// in your address.

I'm seeing HSTS on 0/3 of Australian banks (I'm even seeing RC4 on one of them).

https://www.ssllabs.com/ssltest/analyze.html?d=commbank.com.... https://www.ssllabs.com/ssltest/analyze.html?d=nab.com.au&s=... https://www.ssllabs.com/ssltest/analyze.html?d=westpac.com.a...

You can (and should) also be using HTTPS Everywhere: https://www.eff.org/https-everywhere.

This only applies to websites which land on a plain HTTP page and then load links to HTTPS pages. Entering “ https:// “ explicitly before any URL accessed will fully mitigate this.

Exactly, this particular sentence seems to overly dramatise the situation.

Is this issue any different to using open wifi at a cafe, which many many people do, relying on HTTPS for their security? (This is an honest question)

At its worst, this attack reduces a protected network to an open wifi, yes.

The risk is that you may do things on a protected network assuming it really is protected - this is more of a thing for organisations rather than consumers, for example organisations might have unprotected services accessible over their office wifi.

Or if combined with some other vulnerabilities...

Somewhat pointless remark as WPA only protects up to the access point. Any vulnerability after that has wider implications regardless of the WPA status.

"Our attack is especially catastrophic against version 2.4 and above of wpa_supplicant, a Wi-Fi client commonly used on Linux. Here, the client will install an all-zero encryption key instead of reinstalling the real key. This vulnerability appears to be caused by a remark in the Wi-Fi standard that suggests to clear the encryption key from memory once it has been installed for the first time."

"Because Android uses wpa_supplicant, Android 6.0 and above also contains this vulnerability. This makes it trivial to intercept and manipulate traffic sent by these Linux and Android devices. Note that currently 41% of Android devices are vulnerable to this exceptionally devastating variant of our attack."

Some resources for those who want to keep updated on vendor patch status:

https://www.reddit.com/r/KRaCK/comments/76pjf8/krack_megathr...

https://github.com/kristate/krackinfo

What's the general approach to the fix? Insist on a new handshake if a client sees a duplicate message #3? Just keep going with the old sequence number?

It seems like vendors need to eventually come to some consensus on how to change the protocol instead of each fixing it in their own way.

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.

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.

Those running the popular ESP8266 and ESP32 boards for various IoT devices: a fix has been published for the RTOS running on those boards. If you're building devices on these platforms, try to get this out to your customers as soon as possible.

http://espressif.com/en/media_overview/news/espressif-releas...

> how did this attack slip through, despite the fact that the 802.11i handshake was formally proven secure?

So, we cannot trust even formal verification?

> it’s a factual statement. In formal analysis, definitions really, really matter!

If lack of definition implies flaws in formal verification, does that mean we need an additional formal verification of formal verification?

Update:

> We need machine-assisted verification of protocols, preferably tied to the actual source code that implements them.

Haskell, here is your opportunity :-)

> So, we cannot trust even formal verification?

it's explained in the article, 2 unit tests, 0 integration tests. The formal verification appears to prove correctness of the 2 pieces independently, but not of the composition.

> Haskell, here is your opportunity :-)

you're just moving the problem to the correctness of the compiler.

> you're just moving the problem to the correctness of the compiler

But it would be a huge leap forward.

Formal verification all the way down.

I'm a complete layman in this field, but mustn't it bump against the Incompleteness Theorem at some point? There's no way to prove your definitions.

The critical point is specification vs. implementation. Any difference creates a loophole which can be abused.

> For example, an attacker might be able to inject ransomware or other malware into websites.

A reason to use https even for the most basic websites, including the ones embedded in IoT devices on local networks.

Quick googling found out that at least one guy did come very close to realizing that 4-way handshake should have hard replay protection: http://slideplayer.com/slide/5762070/

On page 30 of the presentation: "Authenticator may (or may not) re-use ANonce"

    Wonderfully Poetic Acronym
    ---

    WPA Privacy Attack!

    Wi-Fi Protected Access
    Wasn’t Programmed Appropriately
    Wads of Potential Attacks
    Wireless Public Access
    Without Prior Allowance
    Well, Pretty Apocalyptic
    WoPA!

    When Patches Arriving?
    Wardrivers, Present Arms!
    Weaponized Privacy Assault
    Wardriving’s Productive Again
    Wide-open Point of Access
    Wrecks Privacy Automatically
    Welcome, Protocol Attackers

    Where Patches, Admin?
    Worthless Privacy Attempt
    Wrong Protocol, Admin
    Won’t Protect Anything

    Weak Privacy Attempt
    Waste of Precious Attention
    Wins Prying Award

    Wired Past, Again

Does anyone know if Apple release security fixes for Airport? I know it isn’t actively developed, but you’d hope they’d release critical security fixes as they still sell them.

The main attack targets 4-way handshakes, so doesn't target access points. You should worry about updating your clients, not your AP.

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

Fortunately most access points will be fine, but those performing client functions (eg repeaters) will need updating.

"This is achieved by manipulating and replaying cryptographic handshake messages." so that means that the mac address has been spoofed to make the AP think that he is always talking to the same mac address.

If I'm plugged into the router directly then i should be good because it eliminates the wifi handshake. So even though other devices on the wifi network could be affected, the node that is plugged in is safe against this?

> If I'm plugged into the router directly then i should be good because it eliminates the wifi handshake.

Eh, yes, if you're plugged in you're good because it eliminates Wifi, period.

For that one client, anyway.

Well yeah, you'd always be safe against these types of attacks if you're wired in. Even on Ethernet.

So if i use my wired in node as an ssh tunnel out to the "internets" to tunnel all traffic from my wifi connected nodes then this mitigates the issue till updates come through?

*even on WEP Is what I meant to say. Haven't had coffee yet, sorry.

Do we now need WPA3?

No, luckily implementations can be patched in a backwards-compatible manner.

It's a pity this didn't completely break WPA2 like how WEP was broken, now it will be years before there's any new security developments. Things like management frame authentication and dynamic client keys for open networks would be big improvements for the majority of use cases.

The problem is that tons and tons of devices will not receive update until they die.

Don't you only need to patch one end of the communication? Eg if phones are patched, they're safe, even if the AP is not. Then again, I didn't read the attack fully, this might be a client-only problem.

You can mitigate with a vpn.

How many BT and Virgin home routers will be patched? Somewhere around 0?

Both Virgin & BT force upgrade consumer routers overnight.

Do I have to update the both the AP and the client or is one of them enough?

Client may be enough. Depends on the AP and only the manufacturer can accurately answer that question.

Anyone already posted "2 unit tests, 0 integration tests"? [1]. It's funny, because 4WS actually had security proofs, which considered all the pieces in isolation, but never in symbiosis.

[1] https://gfycat.com/HotOrangeCoypu

Here is the commit that landed the fix for LEDE today:

https://git.lede-project.org/?p=source.git;a=commit;h=bbda81...

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

3. Everything you care about _should_ be going over TLS, which mitigates all effects of this attack. If it isnt, fix it.

This is a great moment for you to fire up wireshark and audit the traffic going over your wireless link. If its not adequately protected and you care about it, fix it.

Special gear isn't all that expensive. From a cursory view of the video and a skim of the paper, they're using hostapd, which means that they simply need a wifi adapter with a sufficiently-good driver. Anything with the RTL8188CUS seems to be pretty nice (that's what I'm using in a raspberry pi project, myself).

So - I agree with you that there's a barrier to entry, but it's not that big of a barrier.

Agreed. Not specialized equipment. Just something that lets you shoot raw frames and run as a WiFi AP. I have 2 such USB WiFi dongles in my bag for setting up such environments.

Give: http://www.tp-link.com/us/products/details/cat-5520_TL-WN722... a shot. It will let you setup an AP in a VM easily, etc. It is our currently anointed dongle for VM hosted MiTM setups.

I haven't tested it, but it should work fine if they are just using mods to hostapd.

Note that there are two versions of that dongle. The version 1 has Atheros Chip[1] with the best wi-fi support but version 2 has a Realtek chip[2] with subpar support. AFAIK it isn't possible to get version 1 of the dongle today.

My suggestion is Alfa AWUS036NHA (The last three letters are important!) which has AR9271 chip with great support with the ath9k driver.

[1]: https://wikidevi.com/wiki/TP-LINK_TL-WN722N

[2]: https://wikidevi.com/wiki/TP-LINK_TL-WN722N_v2

[3]:http://www.ebay.com/itm/ALFA-AWUS036NHA-802-11n-Wireless-N-W...

On second read, timing requirements arent a thing if you are spoofing the network (obviously) so for that attack vector you don't need specialized hardware. (wont let me edit :( )

I do think it's an end-of-the-world type vulnerability, at least as far as Wi-Fi goes.

1) The paper claims confidentiality compromise allows the attacker to hijack a tcp connection: "allow an adversary to decrypt a TCP packet, learn the sequence number, and hijack the TCP stream to inject arbitrary data", this on all cases, even in the cases where it doesn't allow forgery (CCMP)

2) There's no such claim on the paper and according to the researcher, exploiting this on Android and Linux is trivial. Apparently also macOS. Did you see the video on their website?

3) There's no way for you to control this (apps, https stripping, for instance). Most importantly, there's no way for the average user to control this, short than using a VPN.

Again, as far as Wi-Fi security goes, seems pretty end-of-the-world to me. I don't think the huge attention this is getting is unwarranted.

Sky-is-falling is FUD:

The attack is a standard break exiting secure TCP connection and trick the target to re-create it to a host controlled by the attacker via arp poisoning or route hijacking. After that either convince target to accept a bogus cert or redirect to insecure connection. In the former case the issue is that browsers have way too many root CAs included in them and those CAs can issue certs for any domain; the issue in the second case is that users are not being paranoid enough.

That's not the attack at all. And there's nothing standard about it.

The attack is the fact that someone couldn't do this you're describing on any WPA-2 protected Wi-Fi network before, and now they can.

You have two school of thought here... optimist vs pessimist.

Remember that the attack affects mostly client implementations therefore still needs proximity to victim(s), this makes most of the end-of-the-world type scenarios impractical (they even state these on their QA) and leaves exploitation to direct/APT-groups alone.

Well I did mention it's "an end-of-the-world type vulnerability, at least as far as Wi-Fi goes".

I don't think it's a lot of consolation saying something along the lines of "Wi-Fi security is broken, but it's not so bad because it's Wi-Fi"

You should read "Silence on the Wire: A Field Guide to Passive Reconnaissance and Indirect Attacks" by Michal Zalewski to expand your universe on things you should be afraid pal.

Interesting book that can really burst your bubble on how bad things are and yet we are still here.

> 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 doesn't change mid-session?

How many thousands of apps don't even have such an indicator to observe?

How many millions of phones and APs will never get patched?

This is a severe vulnerability.

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

> How many thousands of apps don't even have such an indicator to observe?

I honestly never considered that one...

No, you do not need expensive hardware such as SDR to carry the KRACK attacks. Most plain standard WLAN adapters support AP mode, which is all you need to simulate the rogue network, as demonstrated in the video.

You still need proximity to the client, a powerful SDR will definitely improve reliability on real-life environments.

I stand corrected. Rogue AP / MiTM only needs a AP with the ability to send raw packets, gotcha.

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.

As far as I can tell that’s dangerous misinformation.

Most IoT devices never get patched. With this vulnerability you can just drive around and spy on webcams. I mean, that's pretty bad. It's enough to make me want to build rpi wifi-wired bridges/gateways for every IoT I own (which, thankfully, isn't all that many, but enough to annoy me).

Don't forget about HSTS. The author demonstrates in the video that you can sometimes bypass TLS if HSTS is not set up.

Also doesn't it require the attacker to have access to your wifi already? If that's the case, it's a hazard for connecting in a Starbucks or on your mobile service wifi, but you would be safe on your home or corporate wifi (unless the attacker is a colleague or relative!).

> Also doesn't it require the attacker to have access to your wifi already?

No it doesn't. Watch the video. It creates a clone of your network and tricks the victim's software stack to connect into it.

Nope. The man-in-the-middle attack it uses involves forwarding and replaying encrypted packets without decrypting the contents, so all it requires is that the attacker be within range of your wifi; they don't need any of your keys or passphrases.

Totally safe, until your local war-driver sniffs out your insecure device and comes back at two in the morning to upload illegal content via your ISP.

Except the attack doesn't get you access to their wireless network. It allows you to redirect someone from their wireless network to your own (spoofed) wireless network and then you can snoop the traffic.

You're freaking me out with that scenario

So, even if I'm using the extension HTTPSEverywhere I'm safe?

HTTPSEverywhere will not magically upgrade a site that doesn't serve HTTPS to HTTPS. If you connect to a site that doesn't support HTTPS, you are vulnerable.

Oh I see, Thanks for the answer! For what is useful the extension then?

Theoretically. The extension can refuse to load sites that aren’t using HTTPS, but the real flaw is sites that use SSL instead of TLS. Attackers can reject SSL but they can’t do anything about TLS, so the security of your browsing would be affected by the website’s HTTPS configuration, and whether they use SSL, TLS, or both (the only 100% safe method is TLS only). I know for most people disabling SSL and going TLS-only isn’t high on their list of priorities so I expect this attack to be very successful on the internet as it is right now.

tcpdump -nw - | strings -n 6

Credit to https://twitter.com/marcan42

What exactly should a person who uses this command be seeing or looking for that would indicate a problem or not?

Linux patches are out https://twitter.com/vanhoefm/status/919853110700531712

I'd assume that all vendors would be busy getting KRACK fixes out, but instead ASUS focuses on adding Facebook functionality to their routers..

https://www.asus.com/Networking/RTAC68U/HelpDesk_BIOS/

There is a lot of talk along the lines of "at least important things use HTTPS now." Well, for WAN traffic, that's largely true. For corporate/university intranets, not so much. For example, SMB (network shares) only supports encryption as of version 3.0, and a server admin who disables handshaking below v3.0 is disallowing Windows clients below 8.

    if (win7 && smb && wpa2) then vulnerable to password theft

the post https://www.theregister.co.uk/2017/10/16/wpa2_inscure_kracka... mentions:

> As Hudson notes, the attacker would have to be on the same base station as the victim, which restricts any attack's impact somewhat.

If I understand it correctly then there has to be a connection already present for the attack to work?

> For ordinary home users, your priority should be updating clients such as laptops and smartphones.

So even if you patch all the devices in your house/company/whetever you can't be safe... Then yours aunt's un-patched android connects into your wifi and put all your network in risk. Or maybe that not-so-old security camera or SmartTV that will never be patched.

Time to move all those guys to an isolated vlan...

The WPA key is not recovered so it should only affect the unpatched client.

I wasn't even thinking about the key. I was thinking about compromising a device using a targeted tcp hijack. And then using that device to compromise the rest of the network. Long shot tough.

Sure that might be possible, for example to serve some malware to that device. More likely is that a device you allow onto your wifi already have some malware from earlier.

This might be a good time to switch off main SSID and exclusively use Guest SSID which is a feature in many routers. At least it would help to isolate wired computers away from the common wifi network. One could then safely use weird computers for sensitive communication.

It might also be a good time to invest in NIC dongle manufacturers considering how many systems only ship with wifi.

This once again shows why complexity is evil in cryptography. The likelihood of a vulnerability in a cryptosystem increases exponentially with the number of state transitions it has.

http://cr.yp.to/talks/2015.10.05/slides-djb-20151005-a4.pdf

Can somebody explain why replay attack protection of WPA2 is not working in this case? Aren't any out of order packets thrown away?

I'm not sure I understand the concern with breaking WiFi. Okay, so you're vulnerable to snooping and injection by people in the same coffee shop or your neighborhood. But you're already vulnerable to that from anybody on the Internet between you and the site. HTTPS solves both of these.

Am I missing something?

There's a treasure-trove of data and metadata in your DNS requests, destination IP addresses, and traffic analysis. You're not just vulnerable to snooping either, but also traffic injection. You're exposing a much larger attack surface by losing the layer of security provided by WPA2.

Lots of sites aren't on https yet. Some never will be. Additionally there could be intranet communications no one bothered to secure, so maybe the company email's POP server was never configured to send text encrypted.

Yeah, Intranet is a good example.

In practice, the points where you're most susceptible to MITM/interception are the initiation and termination endpoints. Most of these connections terminate in a data center/hosting providers, which should generally have decent security and plenty of disincentives for snooping.

However, homes, coffee shops, airports, etc -- those are places where someone could execute this attack successfully.

You're right that any transit router could intercept your connection and do these things but in practice those routers are "reasonably" well secured.

I don't think that I have ever seen any colo-provider which did any meaningful monitoring of traffic on their datacenter-wide customer facing ethernet networks. Usually they struggle to sort out operational issuess caused by misconfigured customer hardware (eg. duplicate IPs or non-converging STP due to incompatible configuration of customer's switch), much less have capability do detect or even prevent targeted attack.

Security in layers, and because locally-hosted content may not always be sent over HTTPS (because people love to cut corners).

How encrypted is your average home network, really?

Yes, you miss ssl stripping.

Some details here on the hostapd security disclosure page: https://w1.fi/security/2017-1/wpa-packet-number-reuse-with-r...

Looks like mikrotik already fixed theirs a couple of weeks ago as well: https://forum.mikrotik.com/viewtopic.php?f=21&t=126695

How are fullmac devices patched? Don't they require firmware flashing or some sort?

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?

This project seems to enable the same thing on commodity hardware:

https://github.com/moha99sa/EvilAP_Defender/wiki

Setup some RPis with WiFi dongles and you can likely make a perimeter defense. IANAL and I do not know how the FCC would view this, although I imagine it is not worse than the Ruckus APs that can do this, yet still passed their certification.

This is not a substitute for patching devices, but it might help somewhat with devices that will never be patched.

So is there any precautions I should take with my macbook and iphone?

Not really just use LAN over WLAN and wait for patches for both of your devices

Now, the OS of processor management units like Intel AMT and the AMD equivalent also incorporate wireless stacks. What are the chances of them becoming effectively fixed?

Can I use MAC whitelisting to mitigate the attack?

Not really. As far as I can tell, the attack basically requires spoofed MACs anyway because the keys are derived in part from the MACs, so whitelisting won't get you much benefit if any at all.

No. You can't even use MAC white-listing to prevent unauthorized devices from connecting to your access point.

MACs are easily spoofed.

Nope,

This will fool your client (eg: your phone) to connect to it, before it reaches your access point, then forward packets to your AP (basic man in the middle).

On the other hand, I am wondering if it manages to correctly forward packages back to the AP if that has MAC filtering on...

Only against an incompetent fool.

Interestingly, the paper mentions that CCMP is affected less than TKIP/GCMP, but not the FAQ.

One thing to clarify, does the attack require the attacker to be already connected to the AP?

No, that was explained in the demonstration video.

Already patched in Arch linux. Just updated all my systems.

This was fixed in OpenBSD back in August.

Assuming neither client and router is upgraded, can this be mitigated my making the SSID hidden, so the attacker wouldn't know which AP to spoof?

The attack doesn't need to know the SSID to find and replay the affected packet.

hidden APs can be easily seen

Thanks, didn't know that :)

Is it possible to adapt these attacks to HTTPS protocol?

Oh goodie.

So how will this be fixed?

It seems that OpenBSD already patched their source code and that wasn't to the likings of the researcher. In the future he will now delay notifying OpenBSD of vulnerabilities.

Why did OpenBSD silently release a patch before the embargo?

OpenBSD was notified of the vulnerability on 15 July 2017, before CERT/CC was involved in the coordination. Quite quickly, Theo de Raadt replied and critiqued the tentative disclosure deadline: "In the open source world, if a person writes a diff and has to sit on it for a month, that is very discouraging". Note that I wrote and included a suggested diff for OpenBSD already, and that at the time the tentative disclosure deadline was around the end of August. As a compromise, I allowed them to silently patch the vulnerability. In hindsight this was a bad decision, since others might rediscover the vulnerability by inspecting their silent patch. To avoid this problem in the future, OpenBSD will now receive vulnerability notifications closer to the end of an embargo.

This feels like some kind of prisoner's dilemma game theory problem. By defecting from the embargo, OpenBSD gained potential security for its users at the expense of all other users. Overall, this is a loss, unless you use OpenBSD. I have to agree with the researchers on this one; OpenBSD acted selfishly here.

Read that again. We asked to commit without revealing details, he said yes, that's what happened. I guess he changed his mind about that after the fact, but nobody promised not to commit. We didn't "defect" from an embargo unilaterally.

Perhaps "defect" is the wrong word given the circumstances, but the result is the same. There's a good reason for the embargo: this all takes cooperation, as it's not a Nash equilibrium. I still agree with their decision not to include OpenBSD so early in further disclosures, given Theo's short-sighted statement.

From what I've read, I don't see why everyone is giving you a hard time about this. It sounds like you did exactly what he agreed you could do, and then he changed his mind.

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

It's a loss, even if you use openbsd. If you break the embargo, you won't be notified in advance anymore. Basically, you get an advantage once but will get several losses for a very long time. Overall it's bad, even for OpenBSD users.

The researcher's reaction is correct. OpenBSD maintainers' lack of patience may have led to this vulnerability being discovered and exploited by other people.

The researcher’s lack of full disclosure may have lead to this vulnerability being discovered and exploited by other people.

Also an embargo lasting months seems excessive.

You also can not guarantee me that no one who gets this information early is not working for a bad actor.

I wonder when the NSA and CIA was responsibly informed about this vulnerability.

As far as I understood, this attack has no client-side mitigation that could be employed other than treating every wifi as an open network. The attack might already be known to hostile actors or may have become known during the embargo, but full disclosure without an embargo would guarantee that clients are at risk without mitigation. An embargo at least gives time to prep patches and protect at least a portion of the clients.

You got everything wrong. If big vendors are unable to patch their proprietary products in an acceptable time, that shouldn't put others at risk. Users shouldn't choose their products...

Think about it in a different way: What if a vulnerability was discovered in TLS and FOSS implementations patched it, but there is an embargo for supposedly protecting some banking software? What if NSA/CIA/other agencies find out about it (they would know immediately) and use it to target users/activists?

This is why embargoes have deadlines. To make the necessary trade-off between "patch as soon as you can, potentially jeopardising the safety of users -- even users of non-proprietary projects" and "wait for everyone to be ready before you patch -- which also jeopardises users". The embargo system deals with this by forcing everyone to agree on a date, and if someone patches after that date then too bad. You may disagree that the deadline was so long, and that could be a fair criticism.

But pretending as though co-ordination of any kind is somehow bad (and then resorting to emotional arguments and so on) is pretty reckless.

What if [...] is FUD. What if Theo de Raadt works for the FSB? We need to work with the facts.

If you don't agree with an embargo and decide to break it, that's on you. But the consequence is that you shouldn't be surprised if next time you're informed later, or not at all. What OpenBSD proponents and developers are doing right now, is damage control. It may work this time, it may work next time, but it won't keep working every time so pick your fights right. It isn't the first debacle OpenBSD has with full disclosure either (hint: OpenSSH).

There are also millions upon millions of devices which won't get patched. Given the vulnerability is apparently the most vulnerable on Linux and hence Android, do you think all the smartphones running Android 4.3, 4.4, 5.0, and 6.0 will be patched [1]?

[1] https://en.wikipedia.org/wiki/Android_(operating_system)#Pla...

But have the other OS makers released patches already?

For reference, the OpenBSD patch in question released on August 30: https://ftp.openbsd.org/pub/OpenBSD/patches/6.1/common/027_n...

On GitHub, appears at [0] with comments coming in today at [1].

0 - https://github.com/openbsd/src/commit/2e40dd69ac29d6a858309b... 1 - https://github.com/openbsd/src/commit/cc66e8f557d6f3d4dea5ea...

tedunangst: "We asked to commit without revealing details, he said yes" "I guess he changed his mind about that after the fact."

The patch has obviously an explicit description:

"State transition errors could cause reinstallation of old WPA keys."

It's true, however, that anybody who analyzes the diffs would eventually figure that out, as Theo de Raadt argued.

My conclusion is also that the real error was even wanting to give the details to him at that moment, as there's apparently a history of him not respecting embargoes.

Oh, that's the problem? That's too much information? Well, shit.

I still fail to get what you wanted to express with your comment here. I've just quoted two sentences from another comment of yours on the same page, have you understood something else?

Not the first time OpenBSD does not respect embargoes, for example https://lwn.net/Articles/726585/ and https://lwn.net/Articles/726580/

"As a compromise, I allowed them to silently patch the vulnerability." The way I read that they broke no embargo

They were pressured by OpenBSD to do so, and regret it. That doesn't mean they broke embargo, but it also doesn't reflect well on them. Do you think Theo would've respected the embargo if they had said "no, do not patch until the embargo date?"

A bunch of dudes on a linux mailing list lack the authority to prevent openbsd from fixing things.

True, they don't. However, this researcher has the authority to not notify the openbsd team in advance any more and he already announced that he'll keep his cards closer next time. What happens if sufficient researchers come to the same conclusion?

Sounds like the researcher is at fault for putting OpenBSD on their list. If you cut a deal with someone who serially defects, at a certain point the onus shifts from them to your lack of foresight.

The problem isn't a "fool me once shame on...fool me you don't get fooled again", because the problem is one unscrupulous party is unscrupulous to different parties and the different parties at different times are unaware of it.

As a user I am completely fine with that.

Even when the author states that now as a result of that selfishness OpenBSD won't get notified about vulnerabilities until well after everyone else?

Author doesn't know what FreeBSD, Debian and OpenBSD people cooperate and share knowledge, so most probably OpenBSD developers will know about the issues, just not from an "official" email.

Furthermore by not even attempting to include OpenBSD in some embargo agreement, there's no reason for OpenBSD to not patch as soon as they hear about it. Indeed that's what seems to have happened on the linked 'evidence' about them not respecting an embargo of a linux distro group they're not part of.

i don't get how they can run a mitm attack without knowing the secret passphrase, can someone explain this in laymans terms?

Because you are replaying the packet, which doesn't need the key.

thanks that makes sense

This is too big, I doubt it's not a backdoor.

"This can be abused to steal sensitive information such as credit card numbers, passwords"

This really isn't true (because that kind of information is protected by TLS) and the article is highly disingenuous to not say so.

Nobody has trusted WiFi encryption as protection for sensitive information for more than a decade.

Demonstration video has the researcher sniff passwords from match.com, which uses TLS. The catch is they aren't using HSTS and so they are vulnerable to sslstrip.

True, using a vpn gives you control over "an" encryption layer for your traffic, relying on the sites https will always be less ideal.

Did you watch the demo video[1]? Apparently some sites (Vanhoef’s example was Match.com) are suspectible to MITM by using Moxie Marlinspike’s sslstrip tool[2].

[1] https://youtu.be/Oh4WURZoR98 [2] https://github.com/moxie0/sslstrip

"This can be abused to steal sensitive information such as credit card numbers, passwords, chat messages, emails, photos, and so on."

As much as this is a scare tactic to get people to demand vendor patches, it's been true for https for a while.

Browsers don't have any trick (that I know of) to enforce https on first connection. HSTS is defeated by simply rejecting connections to https - the user will retry the site from different devices and destroy their hsts cache in order to reach the site. Assuming the site used hsts.

All major browsers implement a HSTS preload list[1] to get around the first connection problem. Manually deleting the HSTS pin for a site is quite involved and not something I'd expect most users to do.

[1]: https://hstspreload.org/

Preload lists are not a realistic solution (you can't preload the whole internet) and a sufficiently complicated site will be subverted due to 3rd party dependencies. And does uninstalling a browser not clear the hsts cache?

Perfect is the enemy of good. A large portion of sensitive traffic is protected by HSTS today, and the preload list compresses well. By the time it'll become a problem, we'll hopefully be at the stage where HTTP is treated as insecure anyway.

I'm not certain if uninstalling a browser clears the cache (do uninstalled browsers retain their profiles?), but preloaded sites would not be affected - they're included in the browser binary. Either way, let's not act like there's a massive hole in HSTS because there's a possibility that users might go as far as reinstalling their browser to visit a not-preloaded HSTS-enabled site that's being targeted.

> you can't preload the whole internet

"You wouldn't HSTS the whole internet, would you?"

Google: "Hold my beer..."

https://nakedsecurity.sophos.com/2017/10/03/google-is-making...

Right now it's mostly unimportant new domains, but it's a start, and they could convince other domain registrars to follow-suit.

You can't preload the whole internet, but by getting the top xx thousand you get 99% of all Chrome users traffic. Its not perfect, but it is very, very effective.

Reply on news.ycombinator.com