Slashdot Mirror

← Back to Stories (view on slashdot.org)

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

Posted by msmash on from the security-woes dept.

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.

11 of 46 comments (clear)

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

      --
      Someone had to do it.
  2. 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.

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

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

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

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

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

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