Slashdot Mirror


Dragonblood Vulnerabilities Disclosed in Wi-Fi WPA3 Standard (zdnet.com)

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.

46 comments

  1. Let me guess ... by Anonymous Coward · · Score: 2, Interesting

    Wi-Fi Alliance's recently launched WPA3 Wi-Fi security and authentication standard

    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.

    1. Re:Let me guess ... by Anonymous Coward · · Score: 0

      But now they can release the versions WPA3.1 Gen1, WPA3.1 Gen2, and then completely replace the earlier standards with WPA3.2 Gen 1x1, WPA3.2 Gen 1x2, WPA3.2 Gen 2x1 and WPA3.2 Gen 2x2.

    2. Re:Let me guess ... by Anonymous Coward · · Score: 0

      Let me guess

      Someone stole your sweet roll? ;-)

    3. Re:Let me guess ... by gweihir · · Score: 1

      They probably had no real security expert in the design group in the first place. After all, security is easy, right?

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    4. Re:Let me guess ... by skids · · Score: 2

      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 mitigated by NOT DOING THAT (in both cases). But then of course you have to either tell supplicants which don't support the stronger alg to go stuff it. or somehow segregate them into a lower security class if there's a point to letting them on at all.

      IIRC most of the SAE algorithms also demand some throttling be done and excesses on that throttling reported to the other side in order for both sides to require a password reset if someone has been aggressively on-line guessing. Not sure if that's required by the standard even though it is a countermeasure mentioned by authors of these crypto suites in the original papers that publish them. That in turn requires keeping state on peers long-term. How much you wanna bet client supplicants find way to fail to implement that?

  2. Is GNU/systemd/Linux vulnerable? by Anonymous Coward · · Score: 0

    Is the wireless networking functionality of GNU/systemd/Linux vulnerable? If it is, is there any way that I can protect my systems from these vulnerabilities? Do I need to go back to wired networking only?

    1. Re:Is GNU/systemd/Linux vulnerable? by Anonymous Coward · · Score: 0

      What Linux distro has WPA3?

      You might need to calm down.

  3. No Public Reviews by Anonymous Coward · · 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.

    1. Re:No Public Reviews by Anonymous Coward · · Score: 0

      Mod up!

  4. Vulnerabilities in key exchange by sinij · · Score: 3, Interesting

    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?

    1. Re:Vulnerabilities in key exchange by mwfischer · · Score: 4, Insightful

      thousands of people representing multiple large organizations came together to produce a closed source standard everyone hates.

    2. Re:Vulnerabilities in key exchange by Anonymous Coward · · Score: 0

      What is, because everyone wants their own piece of the action, Alex?

    3. Re:Vulnerabilities in key exchange by astrodoom · · Score: 2

      The vulnerability breakdown is 1 Denial of Service, 2 down-grades, and 2 side-channel attacks. Downgrade and side-channel attacks are prevalent where backward compatibility functionality exists.

    4. Re:Vulnerabilities in key exchange by plague911 · · Score: 0

      Standards are highly influenced by organizations which are motivated to ensure that the internet is not secure (CIA, FSB, Ministry of State Security) so they all intentionally influence them to ensure that they have advanced knowledge of what the keys to the kingdom are. People really need to stop overlooking the fact that the same people who write cryptographic techniques are the same people who are paid to break them later. This is an obvious conflict of interest that will not ever go away. TLDR the internet was never meant to be secure.

    5. Re:Vulnerabilities in key exchange by bill_mcgonigle · · Score: 1

      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?

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    6. Re:Vulnerabilities in key exchange by Anonymous Coward · · 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

    7. Re:Vulnerabilities in key exchange by Anonymous Coward · · Score: 0

      another comment:

      implementing a PAKE (Dragonfly) is fantastic step in the right direction. They just should have been better about it.

      PAKE implementations for all security usernme/password authetnication need to become a default 10 years ago....

      PAKE's would stop this nonsense of leaked password hashes/lists --- brute-forcing the hash and hitting other sites a user recycled said password on (or deravitive of it).

    8. Re:Vulnerabilities in key exchange by Anonymous Coward · · Score: 0

      because "good methods" in "modern" software is,... not even a misconception. Human monkey thingies can not write secure software, period. As for protocol design,... just forget it.

      There have never been a wireless standard that is secure. Maybe we should just switch to extreeeeemely ultra long wave instead of this ghz crap, eheheh. You never hear about those getting haxxored.

    9. Re:Vulnerabilities in key exchange by Anonymous Coward · · Score: 0

      The IEEE has no authority over WiFi Alliance.

    10. Re:Vulnerabilities in key exchange by WaffleMonster · · Score: 1

      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 which to know the difference?

      With TLS secure negotiation works by double checking initial set of parameters AFTER key exchange (typically RSA PKI) has occurred. If there is a discrepancy with before and after parameters the session is terminated. With TLS key exchange is safe.

      In the case of WPA3 "AFTER" exchange is too late given the damage is already done by the exchange itself. Using PSK exposed the users credentials to offline attack regardless of what happens next.

      It seems to be fundamentally impossible. There are schemes that can be used to mitigate the problem in the real world but they are usability tradeoffs, unrealistic and or don't offer full coverage:

      1. Manual levers where clients and servers declare level of security they are willing to accept. This seems to be the best option.

      2. Latches remembering previous sessions denying subsequent sabotage.

      3. Prefab lists and external trust relationships to secure exchange.

      Please don't get me wrong about my feelings about WPA3. They made terrible decisions chief among them was the selection of a balanced rather than augmented PAKE.

      Balanced precludes the possibility of storing passwords at rest in what is analogous to a one way hash format. The only option for protection is reversible encryption.

    11. Re:Vulnerabilities in key exchange by tlhIngan · · 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?

      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 have any encryption in the standard.

      The Wi-Fi Alliance is an industry group created to ensure interoperability of equipment. It's entirely possible to create hardware compliant with the standard but which cannot talk to each other, so to prevent this, they created the term "Wi-Fi" and a certification that ensures all Wi-Fi certified equipment will talk to each other.

      As part of that, they created the WPA security standards (again an interoperability issue) as well as test to ensure hardware will talk to each other.

      But primarily they are an industry group meant to promote wireless networking. The IEEE doesn't care what people do with the standard - as far as they're concerned, people are free to use or ignore their wireless networking standards and specifications. The Wi-Fi Alliance works to promote that standard (it benefits them when people buy Wi-Fi equipped hardware).

      And yes, both the IEEE and Wi-Fi Alliance, as standards groups, suffer from the same problem - politics. A lot of companies get together to hammer out the standards and a lot of horse trading goes on to ensure your patent and my patent get included, etc. etc. etc.

    12. Re:Vulnerabilities in key exchange by gweihir · · Score: 1

      Dysfunctional organizations at work. No surprise.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    13. Re:Vulnerabilities in key exchange by Anonymous Coward · · Score: 0

      But you can't get rich without making people hating you, it's part of the weird trick

  5. Side channel attacks are the hard ones by Anonymous Coward · · Score: 0

    The downgrade attacks should be fairly easy to solve in new devices (or with an update if possible), but the side channel attacks are a bitch. Probably going to need a WPA4 to solve those

    1. Re:Side channel attacks are the hard ones by Anonymous Coward · · Score: 0

      There are billions of devices out there that will probably never get an update to WPA 4. Better make sure it's backward-compatible with WPA 2 and 3.

  6. Just use IPSEC by Anonymous Coward · · Score: 0

    WiFi security is a fucking joke, first WEP was trivially broken, and now the latest standard also has huge flaws.

    We already know how to secure IP data over an unsecure channel, it's called IPSEC and has been standardized and studied it detail for decades. There's no excuse to keep developing broken standards.

    With some improvements to the user experience it could be just as easy as a WiFi password to deploy for securing your network. APs should firewall off any non-encapsulated traffic except for initial handshakes. Connection managers should let you just enter to passphrase (Pre-Shared Key) for consumer setups, and voila your data is secure.

    1. Re:Just use IPSEC by Anonymous Coward · · Score: 0

      IPSEC works on the wrong layer though. The 802.11 protocols work on the link layer. The problem sets are in fact a bit different. People who just wave their hands around saying use this other thing instead without a full understanding of what they're doing, well it leads to issues like Dragonblood here...

    2. Re:Just use IPSEC by Anonymous Coward · · Score: 0

      You don't need to secure the link layer if you secure the layer above it.

      People re-inventing the wheel thinking that their problem is a special snowflake unlike any other problem before it is what leads to things like Dragonblood.

      I'll re-iterate, we already know how to send data securely over an unsecure channel. If the link layer is left unsecure we can send data securely across it still by using things such as IPsec.

      What do you think you're protecting against by securing the link layer rather than the IP layer?

    3. Re:Just use IPSEC by jabuzz · · Score: 2

      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.

    4. Re:Just use IPSEC by Anonymous Coward · · Score: 0

      You don't need to secure the link layer if you secure the layer above it.

      There are two things here that you're doing with WPA MAC layer encryption.
      1. Encrypting the data between the client and the AP.
      2. Providing access control to the AP and any resources on the local network.

      IPSEC solves only the first issue. The second issue is just as important though. Consider that ARP, DHCP, IPv6 auto discovery, etc cannot be encrypted via IPSEC as they require properties of the link layer to work. It's really a different problem set. Without any sort of access control, well its not too hard to setup a bogus DHCP server, do ARP poisoning attacks etc.

  7. Good thing it wasn't TigerBlood! by Anonymous Coward · · Score: 0

    Imagine Charlie Sheen hacking you.

    It'd either be really great or really bad.

  8. Am I the Stupid One Here? by Anonymous Coward · · Score: 0

    If WPA3 is a brand new protocol, why are downgrade attacks possible? Isn't the point of a new standard to ditch the old and broken?

    How does a 0 day protocol have a 0 day downgrade attack?

    1. Re:Am I the Stupid One Here? by whitroth · · Score: 1

      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?

    2. Re:Am I the Stupid One Here? by Anonymous Coward · · Score: 0

      It's called backward compatibility, buttercup. You might want to Google that sometime.

    3. Re:Am I the Stupid One Here? by gweihir · · Score: 1

      Incompetent design team. That is pretty much the only explanation, besides "management" pushing things in there against expert advice.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    4. Re:Am I the Stupid One Here? by Anonymous Coward · · Score: 0

      I reckon that it wasn't so much incompetence as it was a knee-jerk reaction to KRACK. This is a perfect case study in reactive solutions versus proactive ones.

    5. Re:Am I the Stupid One Here? by gweihir · · Score: 1

      Make sense. Reactive protocol design is pretty much an assured failure.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  9. This is not news by Anonymous Coward · · Score: 0

    So, the fact that is has "backwards compatibility" with older protocols makes it vulnerable to the flaws of the older protocols.

    Wow. What a revelation. I'm glad you are here to tell us these things Chewy.

  10. WPA3 -- DO OVER!!!! by Anonymous Coward · · Score: 0

    They should withdraw the release of WPA3 and do a big do-over AND THIS TIME TEST IT before releasing it again.

  11. wpa_supplicant has patches, but not Debian by tepples · · Score: 2

    wpa_supplicant recently got patches for CVE-2019-9494, 9495, 9496, and 9497 through 9499.

    They don't apply to the Debian 9 "stretch" package of wpa_supplicant because the fixes "heavily depends on the code added after wpa 2.4 release, so porting it is not practical." The maintainer recommends using a strong password until someone finishes a stretch-backports package.

  12. Conveniently.... by Anonymous Coward · · Score: 0

    This requires new hardware.

    Coincidentally, WiFi hardware sales up 20% for quarter.

  13. Re:Dragonblood? by apparently · · Score: 2

    It's almost as if it's a play on the Dragonfly Key Exchange name that's being targetted.

  14. Easy Fix! by Anonymous Coward · · Score: 0

    All you need is a pinch of Dragonsbane plus a Druidic ceremony and your problem with Dragonsblood will be but a memory.