Dragonblood Vulnerabilities Disclosed in Wi-Fi WPA3 Standard (zdnet.com) 46
Two security researchers disclosed details this week about a group of vulnerabilities collectively referred to as Dragonblood that impact the Wi-Fi Alliance's recently launched WPA3 Wi-Fi security and authentication standard. From a report: If ever exploited, the vulnerabilities would allow an attacker within the range of a victim's network to recover the Wi-Fi password and infiltrate the target's network. In total, five vulnerabilities are part of the Dragonblood ensemble -- a denial of service attack, two downgrade attacks, and two side-channel information leaks.
While the denial of service attack is somewhat unimportant as it only leads to crashing WPA3-compatible access points, the other four are the ones that can be used to recover user passwords. Both the two downgrade attacks and two side-channel leaks exploit design flaws in the WPA3 standard's Dragonfly key exchange -- the mechanism through which clients authenticate on a WPA3 router or access point. In a downgrade attack, Wi-Fi WPA3-capable networks can be coerced in using an older and more insecure password exchange systems, which can allow attackers to retrieve the network passwords using older flaws.
While the denial of service attack is somewhat unimportant as it only leads to crashing WPA3-compatible access points, the other four are the ones that can be used to recover user passwords. Both the two downgrade attacks and two side-channel leaks exploit design flaws in the WPA3 standard's Dragonfly key exchange -- the mechanism through which clients authenticate on a WPA3 router or access point. In a downgrade attack, Wi-Fi WPA3-capable networks can be coerced in using an older and more insecure password exchange systems, which can allow attackers to retrieve the network passwords using older flaws.
Re: (Score:3)
Let me guess ... (Score:2, Interesting)
Let me guess ... one of the members insisted on a stupid feature that the marketing department wanted which utterly broke security.
It seems like as we try to build in new things the time until we find out how flawed the system is keeps dropping.
All software seems to be shit these days, especially where security is concerned.
Re: (Score:2)
They probably had no real security expert in the design group in the first place. After all, security is easy, right?
Re: (Score:3)
At least one of them is the same f-up as IKEv2 still has... they don't double-check that the initial negotiation was MITM-free later on into the process. Really you have to take a portion of the keying material and use it to verify the very first packets without exposing the rest of the keying material, then if and only if you have not detected too many "doorknob twists" on that process, continue using the rest of the keying material for the actual session key negotiation.
For example, say a client supports the elliptic curves P-521 and P-256, and prefers to use them in that order. In that case, even thoug the AP also supports the P-521 curve, an adversary can force the client and AP into using the weaker P-256 curve. This can be accomplished by jamming the messages of the Dragonfly handshake, and forging a message that indicates certain curves are not supported.
...which of course can be mitigate
wpa_supplicant has patches, but not Debian (Score:3)
wpa_supplicant recently got patches for CVE-2019-9494 [w1.fi], 9495 [w1.fi], 9496 [w1.fi], and 9497 through 9499 [w1.fi].
They don't apply to the Debian 9 "stretch" package of wpa_supplicant [debian.org] because the fixes "heavily depends on the code added after wpa 2.4 release, so porting it is not practical." [debian.org] The maintainer recommends using a strong password until someone finishes a stretch-backports package.
No Public Reviews (Score:2, Interesting)
This is what happens when you don't open source your crypto, dipshits.
In other news, all of the problems for secure wireless have basically been solved. How to exchange an ephemeral key, how to encrypt a block of bytes, how to initialize an IV, all of it. Quit trying to implement QUIC or whatever-other Google-sponsored fucking backdoor adware shit Hitachi fucking wants. Do the right thing and be done with this bullshit.
Vulnerabilities in key exchange (Score:4, Interesting)
Re:Vulnerabilities in key exchange (Score:5, Insightful)
thousands of people representing multiple large organizations came together to produce a closed source standard everyone hates.
Re: (Score:2)
thousands of people representing multiple large organizations came together to produce a closed source standard everyone hates.
How does the IEEE allow the WiFi Alliance to keep developing these things in secret?
Re: (Score:3)
Because they don't have anything to do with one another.
The IEEE's purpose is to create the standard for wireless networking, aka the 802.11 standards set. It initially specified an encryption system called WEP as part of it, but given its vulnerabilities, it dropped it and the IEEE decided to not ha
Re: (Score:3)
Re: (Score:1)
Re: (Score:2, Interesting)
for the lazy:
https://www.schneier.com/blog/archives/2018/07/wpa3.html
https://www.mathyvanhoef.com/2018/06/wpa3-missed-opportunity.html
basically; not enough mandatory security features allows downgrade attacks.
this in turn will make a nightmre for security minded admins. fking please, just choose a strong suite and make it all mandatory: ala TLS 1.3
https://en.wikipedia.org/wiki/Transport_Layer_Security#Key_exchange_or_key_agreement
Re: (Score:2)
Someone more familiar with cryptography, could you please explain why WPA3 didn't use known-good key exchange methods implemented and tested in modern protocols and instead appears to chose its own method that was found to be vulnerable?
Fundamentally I don't understand how it is even possible to prevent downgrade attacks given set of facts applicable to this situation. I know of no other protocol capable of achieving this. On its face it appears to be fundamentally impossible.
With WPA3 initially password is the entire basis of the trust relationship. How do you support automatic backwards compatibility with PSK method from WPA2 subject to offline attack when everything you see upon connecting can be a lie and there is no basis upon whic
Re: (Score:2)
Dysfunctional organizations at work. No surprise.
Re: (Score:3)
Indeed back in the day when WEP was your only choice and it was broken bad I knew of sites that basically said you know what the WiFi is going to be free access, but once you have connected the *ONLY* think you can talk to is the VPN server, so until you have brought up a IPSEC VPN you can't actually do anything useful. Looks like that approach is still legitimate more than a decade later.
Re: (Score:2)
No. It is not to ditch. The point is to communicate.
Or haven't you seen firefox or chome recently absolutely refusing to go to an http-only site? Or its cert is self-signed?
Re: (Score:2)
Incompetent design team. That is pretty much the only explanation, besides "management" pushing things in there against expert advice.
Re: (Score:2)
Make sense. Reactive protocol design is pretty much an assured failure.