Serious flaws leave WPA3 vulnerable to hacks that steal Wi-Fi passwords | Hacker News Reader

Serious flaws leave WPA3 vulnerable to hacks that steal Wi-Fi passwords

arstechnica.com

130 pointseaguyhn37 comments

Downgrade attacks:

WPA3 has a transitional mode which allows legacy WPA2 clients to connect. In this mode legacy WPA2 security issues are still present. Is this really a discovery or a given? How is WPA3 supposed to protect against it without requiring either WPA2 clients to be upgraded to support WPA3 security fixes (in which case you don't need WPA2 support anymore anyways) or without dropping support for transitional mode? 802.11w fixes much of this but WPA2 didn't mandate support for this which is one of the big reasons WPA3 is so much better.

Dragonfly downgrade:

"The hack can force the access point to use a different curve, presumably one that’s weaker." note: not "The hack can force the access point to use a different curve, one that’s weak.".

Side channel leaks:

Are failures in implementations not WPA3. If you're allowing local timing attacks while generating your keys it doesn't really matter what protocol you're using you've just failed. A real discovery of things in the wild that need to be fixed but nothing to do with the security of the specification.

Denial of service:

It's far more effective and simple to DoS the air than to DoS the APs CPU anyways. Always has been always will be. Besides, would you rather it be faster and have the AP expose side channel attacks instead?

"dragonblood":

Makes me think some researchers were out for their 5 minutes of fame with a cool sounding "vulnerability". To be a little less critical the researches discovered in-the-wild side channel attacks on popular client implementations of the crypto (but that doesn't sound as cool as "serious flaws leave WPA3 vulnerable".

If we look at the paper then these remarks are all discussed:

- Defending against downgrade attack: "A client should remember if a network supports WPA3-SAE. That is, after successfully connecting using SAE [..] the client must never connect to this network using a weaker handshake". The Google Pixel 3 is thankfully already doing this, but others aren't. So perfectly preventable, and something the Wi-Fi Alliance could have included in their WPA3 specification.

- Side-channel leaks: "A backwards-compatible countermeasure is to replace the two vulnerable branches with a constant-time select utility, and use constant time Legendre symbol computation as defined in [73]". The WPA3 standard already contained certain side-channel defenses, but it was still vulnerable. They could've also included these new defenses in the WPA3 standard.

- Denial-of-Service attack: "... our attack is more efficient than a straightforward DoS where an attacker simply jams the channel." We only needed to inject 10 commit frames every second to overload a professional AP..

- Modern crypto standards should be written so the chance of implementation bugs is low. For example, the new hash-to-curve algorithms being standardized include side-channel defenses in the specification itself. See their usage of the CMOV instruction that provides a "Common software implementations of constant-time selects" https://tools.ietf.org/html/draft-irtf-cfrg-hash-to-curve-03

"A client should remember" just transfers things to first trust attacks, if you want to do it right you'd have to make sure you add the network to the device as WPA3 only from the get go.

Side channel attacks, sure, the standard could also have just said "don't be vulnerable to side channel attacks when generating secure data" along with everything else you should do to make a secure system.

Does it really matter how efficient the DoS attack is if any consumer gear can do the in efficient future proof version anyways? As far as intelligent attacks go isn't this yet again an implementation detail where the AP should rate limit responses to a particular client based on it's resources?

Sure, Greenfield things should be written the best they reasonably can be but not being the best something could be doesn't equate to insecure. It's a valid complaint about the standard but not an insecurity.

Again the paper had valid interesting findings in real world side channel attacks and some valid complaints that Dragonfly could have been implemented in better way but it's not focused on attacking those instead it's focused on making big noise about how bad running things in WPA2 mode is bad under the title of being about WPA3.

I again feel that most of these points are all discussed in the paper. Trust-on-first-usage is also used in SSH. Attack uses spoof MAC addresses, hard to rate-limit that. Modern crypto should be designed to reduce chance of implementation flaws. Paper concludes that WPA3 is still better than WPA2. Most attacks are on WPA3's Dragonfly. Etc. The most practical attacks are downgrades to WPA2 though, so the press might focus too much on that..

Hmm, so I can't have several APs sharing the same ESSID with the newer ones supporting WPA3 and the older ones WPA2?

The downgrade attack works even if both the AP and the device connecting to it are WPA3 capable, that part is not a given

"WPA3 capable" means nothing one way or the other about WPA3 if you are running it in WPA2 mode though. That's my point.

> Dragonfly downgrade:

When WPA3 was announced, some people here were very skeptical of the Dragonfly protocol:

* https://news.ycombinator.com/item?id=17402274

Preface: I am not at all an expert on WiFi

In WPA2 you can send deauthentication "frames" to clients to get them to disconnect from the access point. Later I was told these "control frames" can now be encrypted, with an extension/modification to WPA2 supported in the better consumer wireless routers like Linksys?

In response to your Denial of Service point: Does WPA3 make it harder to disconnect clients? (or are you talking about simply overwhelming the airspace with traffic/interference/jamming?)

There is only so much effort one can put into denial of service attacks in wireless. The fact that this involves radio frequencies means there is always a nuclear option: massive broadcasts of white noise. There is no way for wifi devices to adapt to such an attack. So the fact that some denial attacks can happen using exploits is moot. If the attacker really wants to hold your network down he isn't going to bother with tricky packets. He is going to jam the entire spectrum. Whether you are running WEP or some bleeding edge WPA5.7 implementation won't matter if all anyone can hear is white noise.

Yeah but if you're a sleazy hotel chain that simply wants people to use their crappy expensive wifi instead of personal hotspots then you can't use the "nuclear option" as the white noise will also fuck up your network.

This is the type of attack that is being defended against here, not white-noise bombs.

As dcbadacd described this protection capability (.11w) is mandatory to be WPA3 certified and when operating in WPA3 mode. Transitional mode (WPA2 compatible mode) doesn't mandate it's use because not all WPA2 clients are compatible with it.

The denial of service I'm talking about is as simple as setting up a virtual AP out of your laptop wifi adapter and constantly sending broadcast frames out at max rate. Similar to screaming loudly to interrupt a secret conversation rather than actually attacking the encoded language.

AFAIK WPA3 makes PMF (Protected Management Frames) mandatory.

At least with wpa2 there are devices that perform DOS by just telling devices to disassociate themselves from networks. These are (illegally) used by hotels to force you to use their paid Wi-Fi. Easier than filling all the channels or overloading an AP CPU.

For some reason I'm surprised we've had so many issues with Wi-Fi security.

I don't know if it was addressed in WPA3 (or if it would be addressed there), but my understanding is that a good chunk of the protocol isn't authenticated at all, such as the de-auth packets.

In a world with growing HTTPS support, OpenVPN, WireGuard, etc. and we can't secure a wifi network with a shared key?

The reason we have had so many problems is because these "standards" are not vetted by third-parties and therefore not allowed to test the security of these standards. The Alliance is a closed members-only committee, so yeah I don't doubt we will keep seeing these issues crop up.

Why is everyone using some proprietary standards body for something as important to humanity as a whole like wifi? That seems absurd.

Why hasn't someone like Apple or Google created an open standard and push adoption?

That's also my understanding. My understanding is that these specifications were not developed in the open, and thus there was no opportunity for external scrutiny before they were ratified. It's exactly the same reason previous similar specifications were so badly broken. Nothing has been learned.

I'm not going to get into the ideological debate of if the standards process is open enough or not but let me pose this: Is it not more likely the fact WPA2 was ratified in 2004 that it continues to be of questionable security to utilize in 2019?

No, because:

1. WPA3, which has only recently been created, is riddled with issues.

2. Many things much older than WPA2 are still used today without major issues e.g. AES and RSA.

The idea that standards processes aught to be open is not a ideological debate anymore. At this point it is a simple truth backed by overwhelming empirical evidence.

The process not being open != The process should have happened sooner

In regards to 2 I disagree, see tls 1.0 as an example. Also aes isn't a protocol, apples to oranges.

I mean AES was established in 2001, and that's obviously still considered secure.

Primitives vs Protocols.

Encryption primitives rarely fail. The protocols build on top of them seem to consistently fail.

The principle, the theory is always good. The protocols are implementations, and often implementations are badly done. See with all versions of SSL/TLS prior to TLS 1.3

There is no inherent reason that this is true, other than the fact that in order for primitives to be widely use they go through a open vetting process.

You get protected management frames with 802.11w, WPA3 has it by default. Vendor support for it, in my experience, has been pretty bad however.

I know that the 802.11 means it's a standard for a wireless communication protocol, but I'm only familiar with 802.11b/a/g/n/ac (because they are on the admin page of my router).

How do I now whether my WiFi supports 802.11w or any of the other countless 802.x family of standards that would be nice to have?

Are there any good overviews to these things?

You can search for "MFP", "PMF", "Management Frame Protection", or "Protected Management Frames" in your Wi-Fi router's settings. Second best way is to look up the chipset in your router online.

Going forward anything you buy with WPA3 will support this feature though as it is a requirement to be certified now.

You read the specs or manual for your access point/router. You could also look at beacons and your association request in wireshark, the AP will advertise what it supports. I don't think you'll find these features in consumer equipment, so your best bet is wpa3.

My dream is to eliminate PSK from all the networks I care about/am responsible for, but it's really challenging to deploy 802.1X in anything but a fully managed enterprise (and also hard when you also have random other IOT/etc. type devices; usually the "important" ones you can just put onto wired network, and the unimportant ones go onto dedicated psk, but it's still a pain.

Still hate it all less than captive portals (which I hate so so much), but it's pretty annoying.

Agreed all around, it'd be really nice if there were better general standards for friendly ways to deploy and utilize 802.1x. IOT is definitely a big hold up there, support is quite spotty even amongst new major device manufacturers. I recently was asked to deploy a bunch of Nest smoke alarms at a business for example (they are genuinely nice, and the testing I've seen indicate their dual wavelength photoelectric sensors do a very good job), and they don't support it. But even outside of IOT I'm quite surprised sometimes by mainstream devices that make it more of an effort then it needs to be, such as Chromebooks. I was surprised mainly because one place user/pass auth for WiFi isn't at all uncommon is colleges, and I'd have assumed students there were a significant enough general market to be worth more attention. On a Mac 802.1x is all a single flow at the simplest level, select the network, enter the credentials, it'll ask about the cert if it's self-signed, and that's it. Compare to the Chromebook procedure [1], it's not like it's horribly involved but why the whole separate cert procedure?

Granted, authentication in general remains a lot of spaghetti across the entire industry. I don't think there is a lot of relief overall on the horizon, though at least in some areas like with WebAuthn there is hopeful progress. Maybe progress in separate areas will ultimately make a foundation that can be further expanded.

1: https://support.google.com/chromebook/answer/1047420?hl=en

> and also hard when you also have random other IOT/etc. type devices

Chromecast and Apple TV can't do 802.1x at all, same for every brand of Smart TV I've encountered. Android is a hit and miss, while Samsung and HTC support tends to be decent, cheaper phones don't have it in their test paths.

IoT devices? Gotta be lucky if you can get normal WPA2 running stable against enterprise-class APs. That's a whole new house of cards.

At work I actually had to put up a completely separate wifi network including access points and DSL uplink. Crap gear bought for testing isn't going to get access to the corp network for security reasons anyway and we had lots of issues with using an alternative virtual network on the enterprise APs as most of it seems to be tested against consumer FritzBoxes and 20€ APs, not against Cisco stuff worth hundreds of €.

Aside: “A valid SSID is 0-32 octets with arbitrary contents”

An SSID is up to 16 bytes of arbitrary data e.g. 16 nulls is a valid SSID - I wonder how many UI flaws (or security flaws) result from that decision...

Why wouldn’t WPA3 introduce sane limitations on SSIDs?

>e.g. 16 nulls is a valid SSID - I wonder how many UI flaws (or security flaws) result from that decision...

How can you exploit this? If you put in null bytes, then in all likelyhood it will get truncated early. It's not going to cause an overflow or anything.

This is just a "maybe" idea. If there's any clients that crash when not expecting the nulls then you may be able to crash all effected devices within the area.

Depending on how hard they crash, this might be generally affective maybe.

Why can't a Wi-Fi encryption standard be developed in the open and added to IEEE 802.11 as another annex? Or at least what's to keep people like us from making our own standard in the open and implement it in our own systems at least?

The paper underlying this article : https://papers.mathyvanhoef.com/dragonblood.pdf

Reply on news.ycombinator.com