War Never Changes: Attacks Against WPA3’s “Enhanced Open” — Part 3: OWE Nearly Indistinguishable From Open Wireless In Terms of Risk
In early 2019, myself and fellow Denver-based researcher Steve Darracott (@theDarracott) set 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.
In Part I of this series, we provided historical context and background information that helps fit this research into the current wireless threat model. We then took a technical deep-dive into the technical intricacies of in Part II. If you haven’t read these posts yet, you can find them here:
- https://posts.specterops.io/war-never-changes-attacks-against-wpa3s-enhanced-open-part-1-how-we-got-here-71f5a80e3be7
- https://posts.specterops.io/war-never-changes-attacks-against-wpa3s-enhanced-open-part-2-understanding-owe-90fdc29126a1
In this third and final part of this series, we provide our conclusions about OWE’s ability to address the current wireless threat model, as well as our proof-of-concept attacks against the protocol.
OWE is nearly indistinguishable from open wireless in terms of risk
Our conclusion is that OWE is nearly indistinguishable from open wireless in terms of risk. Although this may seem harsh, recall that in Part I we established that the current wireless threat model rests on the following facts:
- Adoption of HTTPS is widespread. As a result, passive sniffing attacks haven’t worked reliably since circa 2005 [1].
- HTTP Downgrade attacks have become largely irrelevant due to widespread adoption of HSTS [1].
- Rogue AP attacks are still an issue, in that they can be used to perform captive-portal and static-content injection attacks (neither of which are mitigated by HTTPS) [1].
By design, OWE only addresses passive sniffing attacks, and does nothing to prevent rogue AP attacks [2]. We discuss this issue in the sections that follow, along with additional problems that we observed. We then provide a step-by-step walkthrough of our proof-of-concept attack against OWE, along with the results of both of successful and failed attempts to attack OWE Transition Mode.
Findings
Throughout the course of our research, we identified two major issues that affect OWE. These issues are described in the subsections that follow.
OWE does not provide a mechanism for validating the identity of the access point
As we mentioned in Parts I and II of this series, OWE was never intended as a mitigation for rogue AP attacks. This means that by design, it does not provide a mechanism for validating the identity of the access point. Although this hypothesis is not new, and is actually acknowledged in RFC 8110 [2], we provide concrete evidence of this in the Proof of Concept Walkthrough: OWE Evil Twin Attack section found later in this document.
RFC compliant supplicants actively prevent users from distinguishing between encrypted and unencrypted connections
Analysis of RFC 8110, which defines OWE’s technical specifications, reveals an interesting design decision. Per Section 6 of RFC 8110 [2]:
OWE is a replacement for 802.11 “Open” authentication. Therefore,
when OWE-compliant access points are discovered, the presentation of
the available SSID to users should not include special security
symbols such as a “lock icon”. To a user, an OWE SSID is the same as
“Open”; it simply provides more security behind the scenes.
Presumably, the idea is that since OWE will eventually replace open WiFi completely, it should be indistinguishable from open WiFi from an end-user perspective. The wisdom of this design decision is debatable — there’s no hard technical answer here, and there are respectable wireless SMEs on both sides of the debate.
It is my personal opinion that this is a problem — widespread adoption of OWE will take years, and if attempts at deprecating Wired Equivalent Privacy (WEP) are any indication of future success, it is unlikely that open WiFi will ever be completely phased out. There’s a reason why web browsers display a lock icon when connecting to a server over HTTPS — users should know when their data is being transmitted in cleartext.
A counterargument is that since RFC 8110 concedes that OWE does nothing to protect users against active attacks, that displaying a lock icon could be deceiving or confusing to users. Users who are unaware of OWE’s limitations could be lead to falsely believe that OWE offers reliable protection against modern wireless threats. On the other hand, users who are aware of OWE’s limitations could learn not to trust the lock icon (which presumably is shared among other protocols).
My response to this is that we need to decide whether OWE offers some advantage over open networks from a security standpoint. If it does, then users should be made aware of when these advantages are missing from the network they are connecting to. On the other hand, this entire discussion is meaningless if we decide that OWE offers no advantage over open WiFi from a security standpoint. In the second case, we should be asking ourselves why we are pushing to adopt this technology in the first place.
It seems as if device manufacturers have been taking this issue into consideration, going so far as to willfully disregard RFC 8110 by displaying a distinguishing icon anyways (although not necessarily a lock). For example, Android version 9 running on the Razer Phone 3 allows users to distinguish between open and OWE access points as shown in the following screenshot:
Regardless, it remains to be seen if this will be the case across all operating systems and devices.
Research Methodology and Results
When researching this topic, we did our best to stick to the scientific method:
- Question: Is OWE susceptible to abuse and attack, and if so, how?
- Background Research: we familiarized ourselves with any existing literature that we could find, and carefully analyzed RFC 8110 for potential security issues
- Hypothesis: OWE is susceptible to rogue access point attacks
- Experiment: We broke this into multiple phases that are described below
- Analysis: We analyzed the results of step 4
- Conclusion: Our conclusion is that the hypothesis is correct, and as such does not provide significant benefits over open wireless
Experimental Procedures
Phase 4 (Experiment) was broken into the following steps:
- Attempt to create a working OWE access point using hostapd
- Attempt to connect a station (wpa_supplicant) to the OWE access point
- Validate that the access point and station were correctly implementing OWE by using Wireshark to examine traffic between the two
- Attempt to execute proof of concept attacks against the OWE access point.
We followed the same procedures when evaluating OWE Transition mode.
Out of these four steps, the first three actually proved to be the most difficult and time consuming portion of the entire project, mainly due to lack of documentation. Recall that we began our research in April 2019. None of the configuration parameters necessary to create or connect to an OWE access point were publicly documented at the time. We actually ended up constructing working configuration files for hostapd and wpa_supplicant by reverse engineering the hostap’s test suite, which consisted of over 100,000 lines of Python code. We then verified that our configurations were correct by following a process similar to what is found in Part II of this series.
Yet once we managed to overcome these challenges, the actual proof of concept attacks turned out to be pretty anticlimactic — all we had to do was create a rogue AP that used OWE rather than open WiFi. In doing so, we were able to prove our hypothesis without having to develop any truly new techniques.
Proof of Concept Walkthrough: OWE Evil Twin Attack
In this section, we provide a complete walkthrough of our proof-of-concept attack against OWE. This walkthrough assumes you have already completed the lab setup steps found in Part II of this guide:
From your owe-lab directory, begin creating an OWE access point on wlan0 by passing the config file found at conf-files/hostapd-owe.conf to hostapd. Note that this is the same config file we used in Part II of this series. If you’re interested what this config file is doing, you can find a detailed explanation there.
./hostapd conf-files/hostapd.conf
Next, use confirm hostapd has correctly created an OWE access point as shown in the following screenshot (for a more detailed explanation of what we’re looking for with Wireshark, see Part II).
Next, pass the config file found at conf-files/wpa_supplicant-owe.conf to wpa_supplicant to connect wlan1 as a client device to the AP running on wlan0.
./wpa_supplicant -i wlan1 -c conf-files/wpa_supplicant-owe.conf
To verify that association, authentication, and key-exchange processes were completed correctly, use Wireshark with the following filter:
wlan.fc.type_subtype == 0xb || wlan.fc.type_subtype == 0x0 || wlan.fc.type_subtype == 0x1 || eapol
Next, use eaphammer to create an evil twin of our OWE access point that is running on wlan0(note that we’re using wlan2 to create our rogue AP).
./eaphammer -i wlan2 --captive-portal --auth owe --essid owe
Here comes the tricky part — getting the station running on wlan1 to connect to our rogue AP running on wlan2. Remember that there are two ways to execute a rogue AP attack:
- Abuse 802.11’s roaming process: This only works when the station is already connected to a legitimate AP. We entice the station to roam to the rogue AP by providing a superior signal, or we coerce the station to roam to the rogue AP by denying access to the legitimate AP [3]
- Abuse the network selection process: This works when the station is not currently connected to any wireless network. We entice the station to connect to the rogue AP by using an ESSID that is in the station’s Preferred Network List (PNL) [3].
For more information about this, see: https://posts.specterops.io/modern-wireless-attacks-pt-i-basic-rogue-ap-theory-evil-twin-and-karma-attacks-35a8571550ee
The target station is already connected to an access point, which means that abusing the 802.11 roaming process makes the most sense in this situation. However, OWE makes use of Protected Management Frames, which prevents us from forging deauthentication packets to coerce the station to roam [2]. As such, we are forced to entice the station to roam to us by providing a superior signal. This is where our simulated wireless environment begins to show its limitations — we can’t actually do this using the simulated hardware (it is possible to adjust the transmit power of the simulated AP to be inferior to the transmit power of the simulated rogue AP, but this won’t actually get the hardware simulator to initiate a roam).
The goal of this exercise isn’t to prove that 802.11’s roaming process can be abused in an evil twin attack (we’ve known this is possible for nearly two decades) [3]. With this in mind, we’re going to whitecard this portion of the experiment by simply shutting down the legitimate AP, which effectively mimics the effects of either jamming attack or what would occur if the station wandered out of range of the legitimate AP.
./hostapd conf-files/hostapd-owe.conf
With the legitimate AP no longer available, the station running on wlan1 begins to search for another AP with the same ESSID to connect to. Our evil twin running on wlan2 answers the call, and the station connects to it as shown in the next two screenshots.
./wpa_supplicant -i wlan1 -c conf-files/wpa_supplicant-owe.conf
./eaphammer -i wlan2 --captive-portal --auth owe --essid owe
Finally, we can verify with Wireshark:
(wlan.fc.type_subtype == 0xb || wlan.fc.type_subtype == 0x0 || wlan.fc.type_subtype == 0x1 || eapol) && wlan.bssid == 00:11:22:33:44:00
That’s it — we’ve successfully executed an evil twin attack against a network protected by OWE.
Proof of Concept Results: OWE Transition Mode
We also attempted similar attacks against OWE Transition mode. For the sake of brevity, a detailed walkthrough for these proof of concept attacks will not be provided. However, our results should be fairly simple to replicate by repurposing the steps described in the previous section. Additionally, the EAPHammer Wiki provides instructions for executing rogue AP attacks against OWE Transition Mode:
The following table summaries each of the approaches we took when attempting to attack OWE Transition Mode using an evil twin attack, along with the results of each of these approaches.
Conclusion
The introduction of OWE by the WiFi Alliance is a step in the right direction, in that it attempts to fill a need that is now two decades old — encryption support for unauthenticated wireless networks. However, by failing to provide a solution for validating the identity of access points, it fails to mitigate the threat of rogue access point attacks against open networks. By doing so, it fails to significantly reduce the risk posed by unauthenticated wireless communication, and seemingly ignores the context and landscape into which it is being introduced [1]. The fact that it makes the use of Protected Management Frames (PMF) mandatory is a slightly redeeming factor, in that it will make rogue AP attacks slightly more difficult to execute. However, this requirement will likely render current Wireless Intrusion Prevention Systems (WIPS) less effective as well, since these systems rely on deauthentication attacks to contain threats.
References
[2] https://tools.ietf.org/html/rfc8110
War Never Changes: Attacks Against WPA3’s “Enhanced Open” — Part 3: OWE Nearly Indistinguishable… was originally published in Posts By SpecterOps Team Members on Medium, where people are continuing the conversation by highlighting and responding to this story.