Skip to content →

War Never Changes: Attacks Against WPA3’s “Enhanced Open” — Part 1: How We Got Here

This content was originally published on the SpecterOps blog. The original can be found here: https://posts.specterops.io/war-never-changes-attacks-against-wpa3s-enhanced-open-part-1-how-we-got-here-71f5a80e3be7

In early 2019, myself and fellow Denver-based researcher Steve Darracott (@theDarracottset out to answer the question — “is Opportunistic Wireless Encryption (OWE) susceptible to abuse and attack, and if so, how?”. Ultimately, we succeeded in implementing multiple working proof of concept attacks, which we demonstrated at the DEF CON Wireless Village last summer. This series of blog posts documents our research efforts and conclusions, and discusses how OWE fits into the current wireless threat model.

How to read this series

This collection of blog posts contains a lot of information. As such, I have broken it into three sections that are intended to satisfy the needs of both non-technical audiences and audiences of varying technical skill levels. These sections are as follows:

  • Part I: How We Got Here — Introductory post (you’re currently reading it). Historical context and background information that demonstrates why this research matters. Suitable for non-technical audiences and technical audiences that care about the bigger picture. This is arguably the most important post in the series.
  • Part II: Understanding OWE — Technical deep-dive into the nuts and bolts of OWE and OWE Transition mode. Suitable for technical audiences.
  • Part III: Proof of Concept Attacks and Key Takeways— Technical demonstrations and walkthroughs of our proof-of-concept attacks. Note that this section will be relatively short and anticlimactic, since we literally just repurposed existing wireless attacks for use against OWE. We also talk about what OWE gets right — namely the requirement that devices use PMF.

Please do not feel obligated to read all of these sections, although if you do I recommend that you read them in order.

Introduction

In January 2018, the Wi-Fi Alliance announced the upcoming release of WPA3 [1]. One of the key features disclosed as part of this announcement was support for individualized data encryption, which would resolve the long-standing security issues that affect open wireless networks [1]. It was widely speculated that Opportunistic Wireless Encryption (OWE) would be used to implement this feature, and this was later confirmed when WPA3 certification began in June 2018 [2].

By early 2019, WPA3’s implementation of OWE had been rebranded as “Wi-Fi Certified Enhanced Open” and converted to a separate and optional standard to be released alongside WPA3 [3]. Yet in spite of its status as an optional requirement for hardware certification, OWE was still a major source of excitement among wireless professionals and enthusiasts alike. Multiple major device manufacturers announced current or future support for OWE by the Spring of 2019, including Samsung, Cisco, and Aruba Networks [4][5][6][7]. A contributor to the Aruba Networks blog went so far as to name OWE “the most important feature related to WPA3” [3].

With the hype surrounding OWE beginning to trickle into mainstream tech publications, both myself and Denver-based security researcher Steve Darracott became intrigued by the question — “is OWE susceptible to abuse and attack, and if so, how?”. We decided to team up in search of an answer.

Our initial question quickly lead to a second, more rudimentary one — what is OWE anyways? We began by conducting some fairly extensive background research in an attempt to understand OWE at a technical level, along with the problems it is meant to address. Due to a shortage of publicly available written documentation, this initially translated into hours spent watching thinly veiled vendor pitches on YouTube (time that we’ll never get back). After about a week of this with no real progress, we decided that the best option was to actually act like “real” researchers and read the RFC (and so we did).

The RFC ultimately turned out to be the most useful source of information about the protocol, although we also took insight from some comments made about OWE by Dr. Mathy Vanhoef during his recent research publications about WPA3 [8][9][10]. From these last two sources, we were finally able to arrive at a working hypothesis — that since OWE does not provide a means of verifying the access point’s identity, wireless networks protected by OWE are susceptible to the same rogue AP attacks that have affected open networks for the past 20 years.

Some say he’s still searching for an answer to this day

Please note that we were not the first to arrive this hypothesis — the potential for these security issues is actually conceded in the RFC itself, under a section titled “Security Considerations” [10]. Dr. Vanhoef seemed to share these concerns as well, and mentions them briefly in his blog post “WPA3: Technical Details and Discussion” [8]. The fact that he did not pursue these concerns further is telling — he clearly had better things to do with his time.

Yet to the best of our knowledge, no one had ever actually attempted to test this hypothesis by creating a working proof of concept attack. We figured that doing so would be a good place to start.

Ultimately, we succeeded in implementing multiple working proof of concept attacks (all of these involve the abuse of 802.11’s roaming and network selection functionality):

  • Open Evil Twin Against OWE: We demonstrate that it is possible to coerce client devices that use wpa_supplicant to connect to a rogue open access. At this time we are unsure if this an implementation-specific issue or a problem with the protocol itself.
  • OWE Evil Twin Against OWE: We demonstrate that it is possible to coerce client devices that use wpa_supplicant to connect to a rogue OWE access point.
  • OWE Transition Mode Attacks: We demonstrate that OWE Transition mode is susceptible to attacks from transition mode and open APs, but not OWE APs.

We also confirmed that the use of Protected Management Frames (PMF), which is mandated by OWE, makes rogue AP attacks more difficult to execute. However, we point out that the introduction of mandated PMF will invalidate current threat containment methods as well.

How We Got Here

OWE ultimately turned out to be a disappointment — not because it fails to solve the problem it’s supposed to solve, but because it attempts to address the wrong problem. In order to understand what I mean by this, we really need to have a discussion about the current wireless threat model. This is something that a lot of people get wrong: there’s a lot of outdated information out there, and a lot of misconceptions as to what modern wireless tradecraft looks like.

To understand the threat model, we need to understand the history that molded the current landscape into what it today. I realize you may want to skip to the gory technical details (and you probably can). But with your permission, I ask that you accompany me on a brief history lesson before we do that.

Hacking WiFi: A Brief History

The 802.11 standard was released in 1999 [11]. Within a year, it had been adopted by multiple major device manufacturers. Consequently, it was adopted by the general public shortly afterwards [12][13]. This first iteration of the standard came with two initial revisions: 802.11a and 802.11b.

Initially, wireless security came in two flavors: unencrypted “open” networks and networks protected by Wired Equivalent Privacy (WEP) [14][15]. Interestingly, out of these two initial options, only open networks are still in use today [14][15]. This seems counterintuitive, since “open” networks are less secure than WEP even by today’s standards. Why is this the case?

The answer to this question has as much to do with psychology as it does security. Specifically, this is a human factors engineering problem. Both WEP and WPA/2 (its successor) were designed for encrypting network traffic. Yes, we also use them as authentication mechanisms, but that’s only because there aren’t any better options available (you “authenticate” to WiFi networks by successfully encrypting and decrypting traffic).

Both WEP and WPA/2 require users to authenticate in order to establish encrypted connections [15][16]. Using HTTPS as analogy, imagine if users had to authenticate in order to load web content over encrypted HTTPS. Put more clearly: imagine if you had to enter a password each time you wanted to use encrypted HTTPS to access a new website, such as Google or Buzzfeed. Clearly if this was the case, most people would gravitate towards plaintext HTTP out of convenience. But because HTTPS is able to provide encryption in a manner that is completely transparent to the user, its adoption has become widespread.

OWE was developed to address a similar need. The vast majority of public wireless networks are not protected by encryption, because historically it was impossible to encrypt wireless traffic in a transparent and unobtrusive manner. If open networks can be compared to HTTP, then OWE is the IEEE’s answer to HTTPS for wireless networks.

More on this later.

Initial Threat Model (1999 to early 2000s)

Let’s rewind a bit and examine some of the security issues that surfaced when 802.11 was released in 1999. It didn’t take long before offline password / data sniffing became a serious problem. As we mentioned, using WEP to provide public networks with encryption didn’t make sense from a usability perspective. Consequently, most of the era’s public wireless traffic was transmitted in the clear. Remember that WiFi traffic is ultimately a form of radio communication, and when you transmit WiFi packets, they can be captured by anyone nearby if they’re listening. Without encryption, anyone who captures these packets can also view the data being transmitted. This includes passwords, credit card details, and other sensitive information. Eavesdropping attacks were rampant during 802.11’s early years.

By 2002, attackers had figured out that 802.11 provided virtually no guidance for how access point selection should occur [18]. Instead, the implementation of this process was left up to individual device manufacturers. The algorithms that were developed to fulfill this purpose provided no real means of verifying the identity of nearby access points, making access points prone to impersonation attacks known as Evil Twins [18]. In an Evil Twin, an adversary impersonates a trusted access point in order to force nearby wireless devices to connect to the attacker’s hardware. This creates a Person-In-The-Middle (PITM) scenario, which can be leveraged by the attacker to intercept and tamper with network traffic [18].

For more details about rogue AP attacks, see: https://posts.specterops.io/modern-wireless-attacks-pt-i-basic-rogue-ap-theory-evil-twin-and-karma-attacks-35a8571550ee

Initial Application Layer Mitigations (early 2000s to circa 2012)

These early wireless attacks, along with other common PITM attacks of the time period (such as ARP Cache Poisoning) served as catalysts for the widespread adoption of application layer encryption. Simply put: the state of unauthenticated wireless security was not going to improve anytime soon, so application developers took it upon themselves to implement on their own encryption deployed at higher layers of the protocol stack.

By the early 2000s, the use of encrypted application layer protocols (such as SSH and HTTPS) had become accepted best-practices within the technology sector. Widespread adoption of application-layer encryption soon followed, effectively ending the golden age of passive sniffing attacks [19].

These application layer mitigations resolved the threat of Evil Twin attacks as well, at least for the time being. However, Evil Twin attacks reemerged as as a problem by 2009 following the discovery of Moxie Marlinspike’s HTTP Downgrade Attack [20]. This technique allows adversaries to use Evil Twin attacks to downgrade HTTPS connections to plaintext HTTP, and remained a serious and widespread threat for at least half a decade [20].

To learn about HTTP Downgrade attacks in detail, please refer to Moxie’s original BlackHat presentation: https://youtu.be/MFol6IMbZ7Y

Mid-Stage Application Layer Mitigations (circa 2012 to circa 2016)

Rogue AP attacks remained the primary threat to open wireless networks until at least 2012, when HTTP Strict Transport Layer Security (HSTS) was introduced [21]. In reality, HSTS did not become widespread until much later. Adoption of Certificate Pinning became widespread at this time as well.

To learn about HSTS in detail, please refer to the relevant section in the following writeup: http://solstice.sh/workshops/advanced-wireless-attacks/iv-wireless-man-in-the-middle-attacks/

The Current Wireless Security Threat Model

This brings us to the present day. Most public networks still use open WiFi. Passive sniffing attacks haven’t worked since circa 2005. HTTP Downgrade attacks are largely irrelevant due to the widespread use of HSTS by high value targets such as online banking, email providers, and generally anyone with an even moderately-sized security budget.

Let’s talk about what still works against open networks, from an attacker’s perspective:

  • Static-content injection: The attacker uses a rogue AP to establish a PITM, and injects payloads into static web content. The attacker does not even attempt to downgrade HTTPS, and does not need to — mixed content issues are a rampant problem.
  • Captive Portal Attacks: The attacker uses a rogue AP to send the victim to a captive portal page. The attacker then uses the captive portal to serve malware or to capture credentials using social engineering.

That’s basically it, unless the attacker can trick the user into installing a rogue CA cert (which can be startling simple: https://sensepost.com/blog/2016/too-easy-adding-root-cas-to-ios-devices/). However, this attack can be mitigated with Certificate Pinning.

And finally, after 20 years, the WiFi Alliance decides to roll out a means for encrypting public WiFi traffic [1]. They call this new protocol Opportunistic Wireless Encryption (OWE).

Conclusion

The next two posts of this series will examine how OWE works at a technical level, discuss our research methodology, and demonstrate our proof of concept attacks against OWE.

References

[1] https://www.wi-fi.org/news-events/newsroom/wi-fi-alliance-introduces-security-enhancements

[2] https://www.networkworld.com/article/3247658/wi-fi-alliance-announces-wpa3-to-secure-modern-networks.html

[3] https://blogs.arubanetworks.com/solutions/a-look-into-whats-behind-wpa3/

[4] https://www.cisco.com/c/dam/en/us/td/docs/wireless/controller/technotes/8-8/Cisco_Catalyst_9800_Series_Wireless_Controllers_WPA3.pdf

[5] https://www.cisco.com/c/en/us/td/docs/wireless/controller/release/notes/crn810.html

[6] https://wificoops.com/2019/08/05/wi-fi-security-enhancements-part-2-enhanced-open-owe/

[7] https://www.arubanetworks.com/assets/wp/WP_WPA3-Enhanced-Open.pdf

[8] http://www.mathyvanhoef.com/2018/03/wpa3-technical-details.html

[9] https://www.mathyvanhoef.com/2018/06/wpa3-missed-opportunity.html

[10] https://tools.ietf.org/html/rfc8110

[11] https://web.archive.org/web/20090903004711/http://www.wi-fi.org/organization.php

[12] https://www.nytimes.com/1999/07/22/business/apple-offers-imac-s-laptop-offspring-the-ibook.html?

[13] https://www.nytimes.com/1999/11/25/technology/state-of-the-art-not-born-to-be-wired.html?pagewanted=all&mtrref=en.wikipedia.org&mtrref=www.nytimes.com&gwh=4D7B8F50DE532C0B8708577807BADB90&gwt=pay

[14] https://standards.ieee.org/standard/802_11a-1999.html

[15] https://standards.ieee.org/standard/802_11b-1999.html

[16] https://ieeexplore.ieee.org/document/1318903

[17] https://dl.acm.org/citation.cfm?id=1360099

[18] https://blog.gdssecurity.com/labs/2017/8/31/whitepaper-the-black-art-of-wireless-post-exploitation-bypas.html

[19] https://books.google.com/books?id=FLvsis4_QhEC&pg=PA344#v=onepage&q&f=false

[20] https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf

[21] https://tools.ietf.org/html/rfc6797

Published in Wireless

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *