35 | Introduction
64 |April 2019 — 65 | Modern Wi-Fi networks use WPA2 to protect transmitted data. 66 | However, because WPA2 is more than 14 years old, 67 | the Wi-Fi Alliance recently announced the new and more secure WPA3 protocol. 68 | 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. 69 | Unfortunately, we found that even with WPA3, an attacker within range of a victim can still recover the password. 70 | If the victim uses no extra protection such as HTTPS, 71 | this allows an attacker to steal sensitive information such as passwords and emails. 72 | We hope our disclosure motivates vendors to mitigate our attacks before WPA3 becomes widespread. 73 |
74 | 75 |76 | The Dragonfly handshake is also used certain in enterprise Wi-Fi networks that require a username and password for access control. 77 | More precisely, Dragonfly is also used by the EAP-pwd protocol, 78 | and our attacks work against this protocol as well. 79 | For example, an adversary can use similar techniques against EAP-pwd to recover a user's password. 80 | We also discovered serious bugs in most products that implement EAP-pwd. 81 | These bugs allow an adversary to impersonate any user, and thereby access the Wi-Fi network, without knowing the user's password. 82 | Although EAP-pwd is used fairly infrequently in practice, these results illustrate the risks of incorrectly implementing the Dragonfly handshake. 83 |
84 | 85 |86 | Details behind our findings are explained in our paper Dragonblood: Analyzing the Dragonfly Handshake of WPA3 and EAP-pwd. 87 | This paper will be presented at the IEEE Symposium on Security and Privacy on 18-20 May 2020 in Oakland (San Francisco), 88 | and it will be presented at Black Hat USA on 7 August in Las Vegas. 89 |
90 | 91 |Coordinated Disclosure
92 |93 | We collaborated with the Wi-Fi Alliance and CERT/CC to notify all affected vendors in a coordinated manner, 94 | and helped with implementing backwards-compatible countermeasures. Please check with your vendors for updates. 95 | The Wi-Fi Alliance has published a press release, 96 | hostap published advisories and patches, 97 | and we also provide an overview of known CVEs. 98 |
99 | 100 | 101 | 102 | 103 |New Results
104 | 105 |January 2020 — 106 | Note that the Wi-Fi Alliance released updated security recommendations late 2019. 107 | We briefly discuss these at the end of our Real-World Crypto presentation. 108 |
109 | 110 |August 2019 — 111 | During our initial disclosure, the Wi-Fi Alliance privately created security recommendations to mitigate our attacks. 112 | In these recommendations, they claim that Brainpool curves are safe to use, 113 | at least if products securely implement Dragonfly's quadratic residue test (i.e. it must be implemented without side-channel leaks). 114 | However, we found that using Brainpool curves introduces a second class of side-channel leaks in the Dragonfly handshake of WPA3. 115 | In other words, even if the advice of the Wi-Fi Alliance is followed, implementations remain at risk of attacks. 116 | This demonstrates that implementing Dragonfly and WPA3 without side-channel leaks is surprisingly hard. 117 | It also, once again, shows that privately creating security recommendations and standards is at best irresponsible and at worst inept. 118 |
119 | 120 |121 | Fortunately, as a result of our research, 122 | both the Wi-Fi standard 123 | and EAP-pwd are being updated with a more secure protocol. 124 | Although this update is not backwards-compatible with current deployments of WPA3, 125 | it does prevent most of our attacks. 126 |
127 | 128 |129 | The new side-channel leak is located in the password encoding algorithm of Dragonfly. 130 | This algorithm first tries to find a hash output that is smaller than the prime of the elliptic curve being used. 131 | With the default NIST curves, such a hash output is practically always found immediately. 132 | However, with Brainpool curves, several iterations may have to be executed before finding a hash output smaller than the prime. 133 | 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. 134 | Simplified, the resulting timing and execution differences can be measured by an adversary. 135 | For example, in Figure 1 below, 136 | 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. 137 | 138 |
139 | 140 |
143 | Figure 1: Brainpool Timing Attack against WPA3
144 |
147 | Figure 2: Timing Attack Against an EAP-pwd Client
148 |152 | We confirmed the new Brainpool leak in practice against the lastest Hostapd version, 153 | and were able to brute-force the password using the leaked information. 154 | Apart from this, we also discovered a new implementation-specific side-channel in the EAP-pwd implementation of FreeRADIUS. 155 | More worrisome, we found that the Wi-Fi firmware of Cypress chips only executes 8 iterations at minimum to prevent side-channel leaks. 156 | Although this makes attacks harder, it does not prevent them. 157 | This strengthens our hypothesis that the backwards-compatible countermeasures against our attacks are too costly for lightweight devices. 158 |
159 | 160 |The following CVEs were allocated for our new findings:
161 |-
162 |
- CVE-2019-13377: Timing-based side-channel attack against WPA3's Dragonfly handshake when using Brainpool curves. 163 |
- CVE-2019-13456: Information leak in FreeRADIUS' EAP-pwd due to aborting when needing more than 10 iterations. 164 |
167 | In the meantime we also extended our research in the following directions: 168 |
169 |-
170 |
- We demonstrated that timing attacks against EAP-pwd clients are feasible in practice as well. 171 | For example, from Figure 2 above, we can easily see that the response times of the client leak the number of executed iterations. 172 |
- By using Crosby's box test we can better handle noise in the timing measurements. 173 | This also means we require less timing measurements compared to our previous estimates, 174 | e.g. with less than 75 timing measurements per spoofed MAC address we can already recover the number of executed iterations. 175 |
- We improved the cost estimation of the brute force attack using GPUs, 176 | and estimated the cost for several example dictionary sizes. 177 | This revealed that less than $1 is enough to brute-force the largest known dictionaries. 178 |
- We audited and reverse engineered both EAP-pwd and SAE implementations. 179 | This revealed several vulnerabilities, 180 | including authentication bypasses against all EAP-pwd implementations 181 | and against one SAE client. 182 |
- We discuss our novel Brainpool timing attack. 183 |
- We employed MicroWalk to automatically (re)discover our side-channels. 184 | This gives a better guarantee that there are no additional (unknown) leaks. 185 |
- We show that the group downgrade attack can be performed by using ModWifi to block commit frames. 186 |
- Several other improvements were made such that results easier to understand (e.g. more explicit threat model). 187 |
Details
194 |Flaws in WPA3
195 | 196 |The design flaws we discovered can be divided in two categories. 197 | The first category consists of downgrade attacks against WPA3-capable devices, 198 | and the second category consists of weaknesses in the Dragonfly handshake of WPA3, 199 | which in the Wi-Fi standard is better known as the Simultaneous Authentication of Equals (SAE) handshake. 200 | The discovered flaws can be abused to recover the password of the Wi-Fi network, 201 | launch resource consumption attacks, 202 | and force devices into using weaker security groups. 203 | All attacks are against home networks (i.e. WPA3-Personal), where one password is shared among all users. 204 | Summarized, we found the following vulnerabilities in WPA3: 205 |
206 | 207 |-
208 |
- CERT ID #VU871675: Downgrade attack against WPA3-Transtition mode leading to dictionary attacks. 209 |
- CERT ID #VU871675: Security group downgrade attack against WPA3's Dragonfly handshake. 210 |
- CVE-2019-9494: Timing-based side-channel attack against WPA3's Dragonfly handshake. 211 |
- CVE-2019-9494: Cache-based side-channel attack against WPA3's Dragonfly handshake. 212 |
- CERT ID #VU871675: Resource consumption attack (i.e. denial of service) against WPA3's Dragonfly handshake. 213 |
215 | The resulting attacks are efficient and low cost. 216 | For example, the downgrade attacks can be exploited using existing WPA2 cracking tools and hardware. 217 | 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. 218 |
219 | 220 |Below we will give high-level descriptions of these attacks, and for the full technical details we refer to our paper.
221 | 222 |Downgrade & Dictionary Attack Against WPA3-Transition
223 |224 | Our first attack exploits the backward compatibility of WPA3. 225 | To accommodate older clients that only support WPA2, and to motivate the transition towards WPA3, a transition mode was defined in the WPA3 specification. 226 | In this mode a Wi-Fi network supports the usage both WPA3 and WPA2 with an identical password. 227 | We found that an adversary can create a rogue network and force clients that support WPA3 into connecting to the rogue WPA2-only network. 228 | The captured partial WPA2 handshake can be used to recover the password of the network (using brute-force or dictionary attacks). 229 | No man-in-the-middle position is required to perform this attack. 230 |
231 | 232 |233 | 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. 234 | Even when these clients connect with a WPA3-only network, an adversary can still force them into using WPA2. 235 | This allows an adversary to recover the network's password using brute-force or dictionary attacks. 236 |
237 | 238 |Security Group Downgrade Attack
239 |240 | We also discovered a downgrade attack against the WPA3's Dragonfly handshake itself, 241 | where the victim can be forced to use a weak security group. 242 | The device that initiates the handshake (typically the client) sends a commit frame that includes the security group it wishes to use. 243 | 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. 244 | This process continues until a security group is found that is supported by both sides. 245 | An attacker can impersonate an AP and forge decline messages to force clients into choosing a weak security group. 246 |
247 | 248 |Timing-Based Side-Channel Attack
249 |250 | With WPA3 it is considered infeasible for an adversary to recover the password of a Wi-Fi network. 251 | Unfortunately, we discovered that the amount of times it takes for an AP to respond to commit frames may leak information about the password. 252 | When the AP uses security groups based on NIST elliptic curves, which all WPA3 devices are required to support, no timing information is leaked. 253 | However, when the AP supports either Brainpool curves, or multiplicative security groups modulo a prime (MODP groups), 254 | the response time depends on the password being used. 255 | 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, 256 | and comparing this to observed timings. 257 |
258 |259 | We remark that contrary to some claims, Dragonfly was indeed designed to support multiplicative security (MODP) groups. 260 | After all, the Dragonfly variant used in TLS-PWD includes a minor change such that these MODP groups can be safely used. 261 | Unfortunately those changes were not backported to the Dragonfly variant used in WPA3. 262 |
263 | 264 |Cache-Based Side-Channel Attack
265 |266 | 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, 267 | these memory access patterns reveal information about the password being used. 268 | Observing these patterns is possible if the adversary controls any application on the victim's device, 269 | and may even be possible when the adversary controls JavaScript code in the victim's browser. 270 | The leaked patterns can be used to perform a dictionary attack, by simulating the memory access patterns associated to a guessed password, 271 | and comparing this to the measured access patterns. 272 |
273 |We believe modern protocols should provide explicit guidance on how to prevent memory access patterns from leaking secret information. 274 | We therefore consider this to be a flaw in the specification of WPA3's Dragonfly handshake.
275 | 276 |Denial-of-Service Attack
277 | 278 |The device that initiates the Dragonfly handshake starts by sending a commit frame. 279 | Processing this frame and generating an answer is computationally expensive, 280 | especially if defenses against (already known) side-channel attacks are implemented. 281 | Although WPA3 contains a cookie-exchange method to prevent attackers from forging commit frames using fake MAC addresses, 282 | it is trivial to bypass. 283 | As a result, an attacker can overload Access Points (APs) by generating as little as 16 forged commit frames per second. 284 | This resource consumption attack causes a high CPU usage on the AP, drains its battery, 285 | prevents or delays other devices from connecting to the AP using WPA3, 286 | and may halt or slowdown other functionality of the AP as well. 287 |
288 | 289 |290 | Although the attack can be mitigated by processing the commit frame in a low-priority background thread, 291 | variants of the attack remain possible. 292 | Depending on the precise defense that vendors implement, it will either still be possible to trigger a high CPU usage on the AP, 293 | or it will be possible to prevent or delay other devices from connecting to the AP using WPA3. 294 |
295 | 296 | 297 | 298 | 299 |Flaws in EAP-pwd
300 | 301 |302 | The EAP-pwd protocol internally also uses Dragonfly, and provides authentication based on a username and password in certain enterprise Wi-Fi networks. 303 | It is vulnerable to the same attacks that we discovered against WPA3. 304 | On top of that, all implementations of EAP-pwd that we tested were vulnerable to invalid curve attacks, 305 | which enable to adversary to completely bypass authentication. 306 | Most implementations were also vulnerable to reflection attacks. 307 | All combined, EAP-pwd implementations are affected by the following vulnerabilities: 308 |
309 |-
310 |
- CERT ID #VU871675: Overview of attacks specific to hostapd and wpa_supplicant (does not cover other implementations). 311 |
- CVE-2019-9495: Cache-based side-channel attack against the EAP-pwd implementation of hostapd and wpa_supplicant. 312 |
- CVE-2019-9497: Reflection attack against the EAP-pwd implementation of hostapd and wpa_supplicant. 313 |
- CVE-2019-9498: Invalid curve attack against the EAP-pwd server of hostapd resulting in authentication bypass. 314 |
- CVE-2019-9499: Invalid curve attack against the EAP-pwd client of wpa_supplicant resulting in server impersonation. 315 |
- CVE-2019-11234: Reflection attack against the EAP-pwd implementation of FreeRADIUS. 316 |
- CVE-2019-11235: Invalid curve attack against the EAP-pwd server of FreeRADIUS resulting in authentication bypass. 317 |
We remark that not all vulnerable products received a CVE identifier.
319 | 320 |321 | 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. 322 | Both these side-channel attacks are explained in our WPA3 summary. 323 | The timing attack is only applicable against EAP-pwd clients. 324 | The reflection and invalid curve attack are new implementation-specific attacks. 325 | Although these two attacks are not design flaws, nearly all implementations of EAP-pwd that we tested were vulnerable to them. 326 |
327 | 328 |Invalid Curve Attack
329 | 330 |331 | By sending specially crafted elliptic curve points, the adversary can completely bypass authentication. 332 | This can be used against a server to connect to any Wi-Fi network that supports EAP-pwd. 333 | Against a client, an adversary can abuse this to act as a rogue Access Point. 334 |
335 | 336 |337 | The invalid curve attack can be prevented by discarding elliptic curve points that don't lie on the elliptic curve being used 338 | (and discarding the point at infinity). 339 |
340 | 341 |Reflection Attack
342 | 343 |344 | The adversary can reflect the commit and confirm frame of the Dragonfly handshake back towards the server. 345 | Doing this is possible because the handshake is designed to be symmetric. 346 | This allows an adversary to authenticate with the network as another user. 347 | However, because the adversary will not learn the negotiated encryption key, they cannot perform any actions under that user. 348 |
349 | 350 |351 | The reflection attack can be prevented by comparing the scalar and element from the server and client, 352 | and aborting the handshake if either of them are the same. 353 |
354 | 355 |Tested Implementations
356 |357 | The implementations of EAP-pwd that we tested are: 358 |
359 |-
360 |
- FreeRADIUS: we wrote patches to prevent invalid curve and reflection attacks. 361 | At the time of writing, the current version was still vulnerable to timing and cache-based side-channels. 362 |
- Radiator: we inspected patches that prevent invalid curve and reflection attacks. 363 | At the time of writing, the current version was still vulnerable to timing and cache-based side-channels. 364 |
- Aruba's EAP-pwd for Windows: we believe this product is no longer officially supported. 365 | Similar to other EAP-pwd implementations, it was vulnerable to all attacks. 366 |
- iNet Wireless Daemon: we wrote patches to prevent invalid curve attacks. 367 | At the time of writing, the current version was still vulnerable to timing and cache-based side-channels. 368 |
- Hostapd and wpa_supplicant: we wrote patches to prevent invalid curve and reflection attacks. 369 | The maintainer of this project also wrote patches to prevent the timing and cache-based side-channel attacks. 370 |
Paper
376 | 377 |378 | Our research paper behind the attack is titled Dragonblood: Analyzing the Dragonfly Handshake of WPA3 and EAP-pwd, 379 | and will be presented at the IEEE Symposium on Security and Privacy on 18-20 May 2020 in Oakland, San Francisco. 380 | Older revisions of the paper can be found on eprint. 381 |
382 | 383 | 384 |Citation example and bibtex entry
385 |You can use the following example citation or bibtex entry to reference our paper:
386 |Mathy Vanhoef and Eyal Ronen. 2020. Dragonblood: Analyzing the Dragonfly Handshake of WPA3 and EAP-pwd. In IEEE Symposium on Security & Privacy (SP). IEEE.
388 |@inproceedings{vanhoef-sp2020-dragonblood,
389 | author = {Mathy Vanhoef and Eyal Ronen},
390 | title = {Dragonblood: Analyzing the {Dragonfly} Handshake of {WPA3} and {EAP-pwd}},
391 | booktitle = {IEEE Symposium on Security \& Privacy (SP)},
392 | year = {2020},
393 | publisher = {IEEE}
394 | }
395 | Tools
403 |404 | All our tools are made available so other researchers can replicate our results. 405 | These tools are not designed to attack your neighbor's WPA3, 406 | and our hope is that vendors mitigate these attacks. 407 |
408 |-
409 |
- Dragonslayer: performs invalid curve attacks against EAP-pwd clients and server. 410 | These attacks bypass authentication: an adversary only needs to possess a valid username. 411 |
- 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. 412 |
- Dragontime: this is an experimental tool to perform timing attacks against the SAE handshake if MODP group 22, 23, or 24 are supported. 413 | Note that most WPA3 implementations by default do not enable these groups. 414 |
- 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. 415 |
417 | In practice the main risks for WPA3 are downgrade attacks, and possible timing attacks against resource-constrained devices. 418 | The authentication bypass attacks against EAP-pwd that are implemented in Dragonslayer are also security critical in practice. 419 | Considering the other attacks are non-trivial in practice, and assuming vendors will implement defenses against them, 420 | we expect that your neighbour won't abuse them to attack you. 421 |
422 | 423 | 424 | 425 | 426 |Q&A
427 | 428 |-
429 |
- Should I use WPA3? 430 |
- Was Dragonfly designed to be used with the vulnerable MODP groups? 431 |
- Are the (cache-based) side-channel attacks an implementation or design flaw? 432 |
- Is the downgrade attack against transition mode a flaw in WPA3? 433 |
- What if a network has both WPA3-capable APs and older WPA2-only APs? 434 |
- Could the Wi-Fi Alliance have picked a different handshake than Dragonfly? 435 |
- How can I implement WPA3 to avoid cache attacks? 436 |
Should I use WPA3?
440 |441 | If vendors don't come up with a better variant of WPA3, then you should switch to WPA3 once it is available. 442 | After all, we hope that vendors will mitigate most of our attacks, meaning WPA3 will still be an improvement over WPA2. 443 | However, there's still a risk that lightweight devices will be unable to implement all countermeasures due to their high overhead. 444 |
445 | 446 | 447 |Was Dragonfly designed to be used with the vulnerable MODP groups?
448 |449 | Dragonfly was indeed designed to support multiplicative security (MODP) groups. 450 | After all, the Dragonfly variant used in TLS-PWD was made such that these MODP groups could safely be used. 451 | More technically, TLS-PWD prevents timing attacks when using MODP groups 22, 23, and 24, 452 | by avoiding extra loops when the password hash is bigger than the prime number of the security group being used. 453 | Unfortunately this defense was not backported to the WPA3's Dragonfly. 454 |
455 | 456 | 457 |Are the (cache-based) side-channel attacks an implementation or design flaw?
458 |459 | When looking at other standards being created, 460 | some provide explicit guidance on how to avoid (cache-based) side-channel attacks, 461 | and others avoid those attacks in their design itself. 462 | Considering that the programmers which will implement Dragonfly may not be security experts, 463 | such advice is essential to assure implementations are secure. 464 | We therefore strongly believe that standards shoulds explicitly include a discussion of possible side-channel attacks. 465 |
466 | 467 | 468 |Is the downgrade attack against transition mode a flaw in WPA3?
469 |470 | Yes. We expect that most WPA3 networks will operate in transition mode for many years to come. 471 | This means that, unless our downgrade attack is mitigated, WPA3 will not prevent dictionary attacks. 472 |
473 | 474 | 475 |What if a network has both WPA3-capable APs and older WPA2-only APs?
476 |477 | 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. 478 | For example, a flag could have been added to the RSNE to indicate whether all APs in a network support WPA3 or not. 479 | This will allow WPA3-capable clients to determine whether downgrades to WPA2 should be allowed or not: 480 | against networks where all APs support WPA3 downgrade attacks can be prevented, 481 | while downgrades to WPA2 are still allowed in networks that contain older WPA2-only APs. 482 |
483 | 484 | 485 |Could the Wi-Fi Alliance have picked a different handshake than Dragonfly?
486 |487 | Other standardized handshakes exists that provide similar features as Dragonfly. 488 | For example, SESPAKE and J-PAKE are both specified in RFCs and provide similar security guarantees. 489 | But more importantly, minor changes to Dragonfly could have prevented most of our attacks. 490 | In fact, the CFRG repeatedly advised the designers to slightly change the design of Dragonfly. 491 | Had the designers incorporated these suggestions, most our attacks would have been mitigated. 492 |
493 | 494 | 495 |How can I implement WPA3 to avoid cache attacks?
496 |497 | It's exceptionally hard to implement all parts of WPA3 without introducing side-channel leaks. 498 | The best approach to securely implement WPA3 that we encountered so far is the one of Microsoft: 499 | only support cryptographic group 19, 500 | and follow their techniques to implement the hunting and pecking algorithm. 501 |
502 | 503 | 504 |