Introduction

April 2019 — Modern Wi-Fi networks use WPA2 to protect transmitted data. However, because WPA2 is more than 14 years old, the Wi-Fi Alliance recently announced the new and more secure WPA3 protocol. One of the supposed advantages of WPA3 is that, thanks to its underlying Dragonfly handshake, it's near impossible to crack the password of a network. Unfortunately, we found that even with WPA3, an attacker within range of a victim can still recover the password. If the victim uses no extra protection such as HTTPS, this allows an attacker to steal sensitive information such as passwords and emails. We hope our disclosure motivates vendors to mitigate our attacks before WPA3 becomes widespread.

The Dragonfly handshake is also used certain in enterprise Wi-Fi networks that require a username and password for access control. More precisely, Dragonfly is also used by the EAP-pwd protocol, and our attacks work against this protocol as well. For example, an adversary can use similar techniques against EAP-pwd to recover a user's password. We also discovered serious bugs in most products that implement EAP-pwd. These bugs allow an adversary to impersonate any user, and thereby access the Wi-Fi network, without knowing the user's password. Although EAP-pwd is used fairly infrequently in practice, these results illustrate the risks of incorrectly implementing the Dragonfly handshake.

Details behind our findings are explained in our paper Dragonblood: Analyzing the Dragonfly Handshake of WPA3 and EAP-pwd. This paper will be presented at the IEEE Symposium on Security and Privacy on 18-20 May 2020 in Oakland (San Francisco), and it will be presented at Black Hat USA on 7 August in Las Vegas.

Coordinated Disclosure

We collaborated with the Wi-Fi Alliance and CERT/CC to notify all affected vendors in a coordinated manner, and helped with implementing backwards-compatible countermeasures. Please check with your vendors for updates. The Wi-Fi Alliance has published a press release, hostap published advisories and patches, and we also provide an overview of known CVEs.

New Results

January 2020 — Note that the Wi-Fi Alliance released updated security recommendations late 2019. We briefly discuss these at the end of our Real-World Crypto presentation.

August 2019 — During our initial disclosure, the Wi-Fi Alliance privately created security recommendations to mitigate our attacks. In these recommendations, they claim that Brainpool curves are safe to use, at least if products securely implement Dragonfly's quadratic residue test (i.e. it must be implemented without side-channel leaks). However, we found that using Brainpool curves introduces a second class of side-channel leaks in the Dragonfly handshake of WPA3. In other words, even if the advice of the Wi-Fi Alliance is followed, implementations remain at risk of attacks. This demonstrates that implementing Dragonfly and WPA3 without side-channel leaks is surprisingly hard. It also, once again, shows that privately creating security recommendations and standards is at best irresponsible and at worst inept.

Fortunately, as a result of our research, both the Wi-Fi standard and EAP-pwd are being updated with a more secure protocol. Although this update is not backwards-compatible with current deployments of WPA3, it does prevent most of our attacks.

The new side-channel leak is located in the password encoding algorithm of Dragonfly. This algorithm first tries to find a hash output that is smaller than the prime of the elliptic curve being used. With the default NIST curves, such a hash output is practically always found immediately. However, with Brainpool curves, several iterations may have to be executed before finding a hash output smaller than the prime. The number of iterations that didn't have such a valid hash output depends on the password being used and on the MAC address of the client. Simplified, the resulting timing and execution differences can be measured by an adversary. For example, in Figure 1 below, we can see that for the blue and orange MAC addresses (i.e. clients) the desired hash output was, on average, found in different iterations.

Figure 1: Brainpool Timing Attack against WPA3

Figure 2: Timing Attack Against an EAP-pwd Client

We confirmed the new Brainpool leak in practice against the lastest Hostapd version, and were able to brute-force the password using the leaked information. Apart from this, we also discovered a new implementation-specific side-channel in the EAP-pwd implementation of FreeRADIUS. More worrisome, we found that the Wi-Fi firmware of Cypress chips only executes 8 iterations at minimum to prevent side-channel leaks. Although this makes attacks harder, it does not prevent them. This strengthens our hypothesis that the backwards-compatible countermeasures against our attacks are too costly for lightweight devices.

The following CVEs were allocated for our new findings:

  • CVE-2019-13377: Timing-based side-channel attack against WPA3's Dragonfly handshake when using Brainpool curves.
  • CVE-2019-13456: Information leak in FreeRADIUS' EAP-pwd due to aborting when needing more than 10 iterations.

In the meantime we also extended our research in the following directions:

  • We demonstrated that timing attacks against EAP-pwd clients are feasible in practice as well. For example, from Figure 2 above, we can easily see that the response times of the client leak the number of executed iterations.
  • By using Crosby's box test we can better handle noise in the timing measurements. This also means we require less timing measurements compared to our previous estimates, e.g. with less than 75 timing measurements per spoofed MAC address we can already recover the number of executed iterations.
  • We improved the cost estimation of the brute force attack using GPUs, and estimated the cost for several example dictionary sizes. This revealed that less than $1 is enough to brute-force the largest known dictionaries.
  • We audited and reverse engineered both EAP-pwd and SAE implementations. This revealed several vulnerabilities, including authentication bypasses against all EAP-pwd implementations and against one SAE client.
  • We discuss our novel Brainpool timing attack.
  • We employed MicroWalk to automatically (re)discover our side-channels. This gives a better guarantee that there are no additional (unknown) leaks.
  • We show that the group downgrade attack can be performed by using ModWifi to block commit frames.
  • Several other improvements were made such that results easier to understand (e.g. more explicit threat model).

Details

Flaws in WPA3

The design flaws we discovered can be divided in two categories. The first category consists of downgrade attacks against WPA3-capable devices, and the second category consists of weaknesses in the Dragonfly handshake of WPA3, which in the Wi-Fi standard is better known as the Simultaneous Authentication of Equals (SAE) handshake. The discovered flaws can be abused to recover the password of the Wi-Fi network, launch resource consumption attacks, and force devices into using weaker security groups. All attacks are against home networks (i.e. WPA3-Personal), where one password is shared among all users. Summarized, we found the following vulnerabilities in WPA3:

  • CERT ID #VU871675: Downgrade attack against WPA3-Transtition mode leading to dictionary attacks.
  • CERT ID #VU871675: Security group downgrade attack against WPA3's Dragonfly handshake.
  • CVE-2019-9494: Timing-based side-channel attack against WPA3's Dragonfly handshake.
  • CVE-2019-9494: Cache-based side-channel attack against WPA3's Dragonfly handshake.
  • CERT ID #VU871675: Resource consumption attack (i.e. denial of service) against WPA3's Dragonfly handshake.

The resulting attacks are efficient and low cost. For example, the downgrade attacks can be exploited using existing WPA2 cracking tools and hardware. The side-channel vulnerabilities can, for instance, be abused to carry out a brute-force attack using the largest known dictionaries with as little as $1 worth of Amazon EC2 instances.

Below we will give high-level descriptions of these attacks, and for the full technical details we refer to our paper.

Downgrade & Dictionary Attack Against WPA3-Transition

Our first attack exploits the backward compatibility of WPA3. To accommodate older clients that only support WPA2, and to motivate the transition towards WPA3, a transition mode was defined in the WPA3 specification. In this mode a Wi-Fi network supports the usage both WPA3 and WPA2 with an identical password. We found that an adversary can create a rogue network and force clients that support WPA3 into connecting to the rogue WPA2-only network. The captured partial WPA2 handshake can be used to recover the password of the network (using brute-force or dictionary attacks). No man-in-the-middle position is required to perform this attack.

Apart from the above design flaw, we also discovered that the Samsung Galaxy S10 and the iNet Wireless Daemon are affected by implementation-specific downgrades. Even when these clients connect with a WPA3-only network, an adversary can still force them into using WPA2. This allows an adversary to recover the network's password using brute-force or dictionary attacks.

Security Group Downgrade Attack

We also discovered a downgrade attack against the WPA3's Dragonfly handshake itself, where the victim can be forced to use a weak security group. The device that initiates the handshake (typically the client) sends a commit frame that includes the security group it wishes to use. If the AP does not support this group, it responds with a decline message, forcing the client to send a commit frame using another group. This process continues until a security group is found that is supported by both sides. An attacker can impersonate an AP and forge decline messages to force clients into choosing a weak security group.

Timing-Based Side-Channel Attack

With WPA3 it is considered infeasible for an adversary to recover the password of a Wi-Fi network. Unfortunately, we discovered that the amount of times it takes for an AP to respond to commit frames may leak information about the password. When the AP uses security groups based on NIST elliptic curves, which all WPA3 devices are required to support, no timing information is leaked. However, when the AP supports either Brainpool curves, or multiplicative security groups modulo a prime (MODP groups), the response time depends on the password being used. An adversary can abuse this information to perform a dictionary attack, by simulating how much time it would take for the AP to process each password, and comparing this to observed timings.

We remark that contrary to some claims, Dragonfly was indeed designed to support multiplicative security (MODP) groups. After all, the Dragonfly variant used in TLS-PWD includes a minor change such that these MODP groups can be safely used. Unfortunately those changes were not backported to the Dragonfly variant used in WPA3.

Cache-Based Side-Channel Attack

When an adversary is able to observe memory access patterns on a victim's device when it's constructing the commit frame of a Dragonfly handshake, these memory access patterns reveal information about the password being used. Observing these patterns is possible if the adversary controls any application on the victim's device, and may even be possible when the adversary controls JavaScript code in the victim's browser. The leaked patterns can be used to perform a dictionary attack, by simulating the memory access patterns associated to a guessed password, and comparing this to the measured access patterns.

We believe modern protocols should provide explicit guidance on how to prevent memory access patterns from leaking secret information. We therefore consider this to be a flaw in the specification of WPA3's Dragonfly handshake.

Denial-of-Service Attack

The device that initiates the Dragonfly handshake starts by sending a commit frame. Processing this frame and generating an answer is computationally expensive, especially if defenses against (already known) side-channel attacks are implemented. Although WPA3 contains a cookie-exchange method to prevent attackers from forging commit frames using fake MAC addresses, it is trivial to bypass. As a result, an attacker can overload Access Points (APs) by generating as little as 16 forged commit frames per second. This resource consumption attack causes a high CPU usage on the AP, drains its battery, prevents or delays other devices from connecting to the AP using WPA3, and may halt or slowdown other functionality of the AP as well.

Although the attack can be mitigated by processing the commit frame in a low-priority background thread, variants of the attack remain possible. Depending on the precise defense that vendors implement, it will either still be possible to trigger a high CPU usage on the AP, or it will be possible to prevent or delay other devices from connecting to the AP using WPA3.

Flaws in EAP-pwd

The EAP-pwd protocol internally also uses Dragonfly, and provides authentication based on a username and password in certain enterprise Wi-Fi networks. It is vulnerable to the same attacks that we discovered against WPA3. On top of that, all implementations of EAP-pwd that we tested were vulnerable to invalid curve attacks, which enable to adversary to completely bypass authentication. Most implementations were also vulnerable to reflection attacks. All combined, EAP-pwd implementations are affected by the following vulnerabilities:

  • CERT ID #VU871675: Overview of attacks specific to hostapd and wpa_supplicant (does not cover other implementations).
  • CVE-2019-9495: Cache-based side-channel attack against the EAP-pwd implementation of hostapd and wpa_supplicant.
  • CVE-2019-9497: Reflection attack against the EAP-pwd implementation of hostapd and wpa_supplicant.
  • CVE-2019-9498: Invalid curve attack against the EAP-pwd server of hostapd resulting in authentication bypass.
  • CVE-2019-9499: Invalid curve attack against the EAP-pwd client of wpa_supplicant resulting in server impersonation.
  • CVE-2019-11234: Reflection attack against the EAP-pwd implementation of FreeRADIUS.
  • CVE-2019-11235: Invalid curve attack against the EAP-pwd server of FreeRADIUS resulting in authentication bypass.

We remark that not all vulnerable products received a CVE identifier.

Our two side-channel attacks against EAP-pwd are similar to the timing-based and cache-based side-channel attacks against WPA3's Dragonfly handshake. Both these side-channel attacks are explained in our WPA3 summary. The timing attack is only applicable against EAP-pwd clients. The reflection and invalid curve attack are new implementation-specific attacks. Although these two attacks are not design flaws, nearly all implementations of EAP-pwd that we tested were vulnerable to them.

Invalid Curve Attack

By sending specially crafted elliptic curve points, the adversary can completely bypass authentication. This can be used against a server to connect to any Wi-Fi network that supports EAP-pwd. Against a client, an adversary can abuse this to act as a rogue Access Point.

The invalid curve attack can be prevented by discarding elliptic curve points that don't lie on the elliptic curve being used (and discarding the point at infinity).

Reflection Attack

The adversary can reflect the commit and confirm frame of the Dragonfly handshake back towards the server. Doing this is possible because the handshake is designed to be symmetric. This allows an adversary to authenticate with the network as another user. However, because the adversary will not learn the negotiated encryption key, they cannot perform any actions under that user.

The reflection attack can be prevented by comparing the scalar and element from the server and client, and aborting the handshake if either of them are the same.

Tested Implementations

The implementations of EAP-pwd that we tested are:

  • FreeRADIUS: we wrote patches to prevent invalid curve and reflection attacks. At the time of writing, the current version was still vulnerable to timing and cache-based side-channels.
  • Radiator: we inspected patches that prevent invalid curve and reflection attacks. At the time of writing, the current version was still vulnerable to timing and cache-based side-channels.
  • Aruba's EAP-pwd for Windows: we believe this product is no longer officially supported. Similar to other EAP-pwd implementations, it was vulnerable to all attacks.
  • iNet Wireless Daemon: we wrote patches to prevent invalid curve attacks. At the time of writing, the current version was still vulnerable to timing and cache-based side-channels.
  • Hostapd and wpa_supplicant: we wrote patches to prevent invalid curve and reflection attacks. The maintainer of this project also wrote patches to prevent the timing and cache-based side-channel attacks.

Paper

Our research paper behind the attack is titled Dragonblood: Analyzing the Dragonfly Handshake of WPA3 and EAP-pwd, and will be presented at the IEEE Symposium on Security and Privacy on 18-20 May 2020 in Oakland, San Francisco. Older revisions of the paper can be found on eprint.

Citation example and bibtex entry

You can use the following example citation or bibtex entry to reference our paper:

Mathy Vanhoef and Eyal Ronen. 2020. Dragonblood: Analyzing the Dragonfly Handshake of WPA3 and EAP-pwd. In IEEE Symposium on Security & Privacy (SP). IEEE.

@inproceedings{vanhoef-sp2020-dragonblood,
  author = {Mathy Vanhoef and Eyal Ronen},
  title = {Dragonblood: Analyzing the {Dragonfly} Handshake of {WPA3} and {EAP-pwd}},
  booktitle = {IEEE Symposium on Security \& Privacy (SP)},
  year = {2020},
  publisher = {IEEE}
}

Tools

All our tools are made available so other researchers can replicate our results. These tools are not designed to attack your neighbor's WPA3, and our hope is that vendors mitigate these attacks.

  • Dragonslayer: performs invalid curve attacks against EAP-pwd clients and server. These attacks bypass authentication: an adversary only needs to possess a valid username.
  • Dragondrain: this tool can be used to test wether, or to which extend, an Access Point is vulnerable to denial-of-service attacks against WPA3's SAE handshake.
  • Dragontime: this is an experimental tool to perform timing attacks against the SAE handshake if MODP group 22, 23, or 24 are supported. Note that most WPA3 implementations by default do not enable these groups.
  • Dragonforce: this is an experimental tool which takes the information recovered from our timing or cache-based attacks, and performs a password partitioning attack. This is similar to a dictionary attack.

In practice the main risks for WPA3 are downgrade attacks, and possible timing attacks against resource-constrained devices. The authentication bypass attacks against EAP-pwd that are implemented in Dragonslayer are also security critical in practice. Considering the other attacks are non-trivial in practice, and assuming vendors will implement defenses against them, we expect that your neighbour won't abuse them to attack you.

Q&A

Should I use WPA3?

If vendors don't come up with a better variant of WPA3, then you should switch to WPA3 once it is available. After all, we hope that vendors will mitigate most of our attacks, meaning WPA3 will still be an improvement over WPA2. However, there's still a risk that lightweight devices will be unable to implement all countermeasures due to their high overhead.

Was Dragonfly designed to be used with the vulnerable MODP groups?

Dragonfly was indeed designed to support multiplicative security (MODP) groups. After all, the Dragonfly variant used in TLS-PWD was made such that these MODP groups could safely be used. More technically, TLS-PWD prevents timing attacks when using MODP groups 22, 23, and 24, by avoiding extra loops when the password hash is bigger than the prime number of the security group being used. Unfortunately this defense was not backported to the WPA3's Dragonfly.

Are the (cache-based) side-channel attacks an implementation or design flaw?

When looking at other standards being created, some provide explicit guidance on how to avoid (cache-based) side-channel attacks, and others avoid those attacks in their design itself. Considering that the programmers which will implement Dragonfly may not be security experts, such advice is essential to assure implementations are secure. We therefore strongly believe that standards shoulds explicitly include a discussion of possible side-channel attacks.

Is the downgrade attack against transition mode a flaw in WPA3?

Yes. We expect that most WPA3 networks will operate in transition mode for many years to come. This means that, unless our downgrade attack is mitigated, WPA3 will not prevent dictionary attacks.

What if a network has both WPA3-capable APs and older WPA2-only APs?

We believe more openness during the creation of WPA3 would have allowed researchers to provide ideas on how to securely handle handle networks where not all APs support WPA3. For example, a flag could have been added to the RSNE to indicate whether all APs in a network support WPA3 or not. This will allow WPA3-capable clients to determine whether downgrades to WPA2 should be allowed or not: against networks where all APs support WPA3 downgrade attacks can be prevented, while downgrades to WPA2 are still allowed in networks that contain older WPA2-only APs.

Could the Wi-Fi Alliance have picked a different handshake than Dragonfly?

Other standardized handshakes exists that provide similar features as Dragonfly. For example, SESPAKE and J-PAKE are both specified in RFCs and provide similar security guarantees. But more importantly, minor changes to Dragonfly could have prevented most of our attacks. In fact, the CFRG repeatedly advised the designers to slightly change the design of Dragonfly. Had the designers incorporated these suggestions, most our attacks would have been mitigated.

How can I implement WPA3 to avoid cache attacks?

It's exceptionally hard to implement all parts of WPA3 without introducing side-channel leaks. The best approach to securely implement WPA3 that we encountered so far is the one of Microsoft: only support cryptographic group 19, and follow their techniques to implement the hunting and pecking algorithm.