One vulnerability affects Android, ChromeOS and Linux devices connecting to enterprise WiFi networks, another affects home WiFi using a Linux device as a wireless access point.
Two new vulnerabilities in open-source WiFi software allow attackers to trick victims into connecting to malicious clones of trusted networks and intercept their traffic, and join otherwise secure networks without needing the password.
We worked with experienced security researcher Mathy Vanhoef, to discover the new WiFi authentication vulnerabilities and are publishing the details now that they have been patched and updated.
Summary of Findings
- Nature of vulnerabilities: Two authentication bypass attacks on modern WPA2/3 networks: one on users connecting to Enterprise WiFi, the other on existing home WiFi networks.
- Affected software: wpa_supplicant and Intel’s iNet Wireless Daemon (IWD), both of which are open-source wireless network management software.
- Affected platforms:
- wpa_supplicant: all Android devices and Linux distributions using default WiFi client, ChromeOS devices.
- IWD: available in package managers of numerous Linux distributions.
- Impact:
- wpa_supplicant: allows an attacker to trick a victim into connecting to a malicious clone of an Enterprise WiFi network and subsequently intercept their traffic.
- IWD: allows an adversary to gain unauthorized access to a protected home WiFi network, exposing existing users and devices to attack.
- Identifiers:
- wpa_supplicant: CVE-2023-52160
- IWD: CVE-2023-52161
Introduction – Bypassing WiFi Authentication
We worked with Professor Vanhoef to identify major security flaws in two instances of commonly-used open-source WiFi software that leave users exposed to traffic interception and other attacks.
The first attack is on users connecting to an Enterprise WiFi network, the second is an attack on an existing home network.
Our goal with publishing this research is to raise the standard of wireless network security by identifying serious software vulnerabilities so that vendors patch them and then make sure the public is informed.
We also want to raise public awareness about the risks inherent in using shared networks and share advice on how to protect against them.
What devices are affected?
The vulnerability affecting wpa_supplicant v2.10 and lower (CVE-2023-52160) is particularly concerning as this is the default software used in Android devices to handle login requests to wireless networks.
There are 2.3 billion Android users worldwide who could therefore be affected by this vulnerability.
Thewpa_supplicantsoftware is also found in almost all Linux devices, as well as in ChromeOS, the operating system used in Chromebooks, which are very popular in educational settings.
While thewpa_supplicantvulnerability only affects WiFi clients that aren’t properly configured to verify the certificate of the authentication server, recent studies show that this is unfortunately often the case, especially with the affected devices.[2]
The vulnerability in IWD v2.13 and lower (CVE-2023-52161) impacts fewer people as it’s Linux-only WiFi software. However it affects everyone using IWD as an access point, as the vulnerability does not rely on any misconfiguration.
Developed by Intel, IWD is intended as a comprehensive connectivity solution for Linux and an eventual replacement forwpa_supplicant.[3] It is available in the official package managers of all major Linux distributions.
What types of WiFi networks are at risk?
The vulnerability in wpa_supplicant affects WiFi networks using Enterprise mode of WPA2/3 rather than the less secure, personal mode more typical of home WiFi networks.
Ironically, the security flaw identified in this report relates to the potential for abuse of the mutual authentication process present only in Enterprise mode, which is generally recommended for use by larger businesses.
The IWD vulnerability, on the other hand, affects home WiFi networks.
How can these new vulnerabilities be exploited?
The wpa_supplicant vulnerability allows a bad actor to trick their victim into automatically connecting to a malicious clone of a trusted WiFi network in order to intercept their traffic.
As the attack requires no action by the victim, it’s likely the victim would be unaware they had been targeted.
All the attacker needs to exploit this vulnerability is the SSID of an Enterprise WPA2/3 network to which the victim has previously connected and also to be in range of the victim.
One possible such scenario might be where an attacker walks around a company’s building scanning for networks before targeting an employee leaving the office.
The IWD vulnerability is different in that it allows an adversary to gain full access to an existing protected WiFi network, exposing existing users and devices to attack.
The risks of such an attack, particularly to a small business using this kind of WiFi network, are significant and include:
- Interception of sensitive data
- Malware infections
- Ransomware attacks
- Business email compromise
- Password theft
How to defend against these attacks
Both vulnerabilities were reported to vendors, have been patched and are available as part of their public code repositories.
The usual advice about updating software and operating systems applies with IWD, as it releases frequent updates.
However, the OS you are using will determine how straightforward it is to make sure your devices are secured against the wpa_supplicant vulnerability.
ChromeOS users can simply update to the latest version as it has been patched since at least version 118.
Linux users however are reliant on their distribution providing a patched version of wpa_supplicant. This is not typically done by default, so maintainers will have to ensure the patch is backported into the provided wpa_supplicant version.
Android users unfortunately must wait on a new Android security update that includes the wpa_supplicant patch. This can unfortunately take a long time, from several months up to even years.
In the meantime, it’s critical therefore that Android users manually configure the CA certificate of any saved Enterprise networks to prevent the attack.
University students and staff connecting to eduroam can also can use the CAT tool to securely configure Android. On the latest Android devices, it’s also possible to use Trust-on-First-Use (TOFU) to automatically trust the CA certificate when connecting to the network for the first time.
A sensible precaution would also be to clean up any unused WPA2/3 enterprise networks and to toggle off automatic reconnection for any regularly used networks of that type.
As an additional defense, we recommend habitually using a VPN for public WiFi networks as this will at least prevent an attacker from intercepting your internet traffic, as it will be encrypted.
Take a look at our recommendations for the most reliable VPNs for Android and Linux. Our Android VPN recommendations also apply for ChromeOS users.
While a VPN will protect your internet traffic from bad actors, it can’t defend against every kind of attack arising from these or any future vulnerabilities.
In the following sections we go into more detail about the two vulnerabilities.
For a full technical analysis and all relevant background, download the Bypassing WiFi Authentication in Modern WPA2/3 Networks report authored by Mathy Vanhoef and Héloïse Gollier.
Vulnerability in wpa_supplicant
Prof. Vanhoef, together with Ms Gollier, discovered a flaw in the implementation of PEAP, which allows an attacker to skip the second phase of authentication when the target device has not been properly configured to verify the authentication server.
Note that PEAP is the most common authentication method for Enterprise networks.
The vulnerable code in the flawed implementation of PEAP in wpa_supplicant is shown below.
Vulnerable PEAPv1 code in wpa_supplicant.
By skipping Phase-2 authentication, it’s much easier for an attacker to create a rogue clone of a trusted WiFi network and trick the victim into connecting, all without knowing their password.
Typical Attack Prerequisites
- The attacker needs to know the SSID of the target Enterprise WPA2/3 network
- The attacker must be within range of their victim, who can be located anywhere, i.e. they don’t need to be in range of the network being impersonated during the attack
wpa_supplicantmust be configured to not verify the authentication server’s TLS certificate
These are not particularly onerous prerequisites for an attack.
It is trivial to harvest SSIDs from around office buildings or to advertise popular Enterprise network names such as eduroam, Vodafone Homespot, TelenetWiFree or Unitymedia WifiSpot for example, and simply wait for an unsuspecting victim to connect.
The misconfiguration of wpa_supplicant is unfortunately a known issue on many systems.
Proper configuration is a manual process, whose confusing and tedious nature prompts many users to skip it.
The resulting attack can be seen in the diagram below, where the Phase-2 authentication can be skipped by sending the EAP-TLV Success packet instead of starting Phase-2.
Once connected, the adversary can intercept and manipulate all internet traffic of the victim.
Details of exploit of wpa_supplicant vulnerability.
Vulnerability in IWD
The vulnerability in IWD stems from its implementation of the 4-way handshake, which is used when connecting to any protected WiFi network for the first time.
It is exploitable when IWD is operating in Access Point (AP) mode.
Vulnerable versions of IWD fail to verify in which order message 2 or 4 of the handshake are received, i.e. it fails to store or check what the expected next message should be in the handshake. Instead, IWD simply accepts any message.
In the code snippet below you can see that the vulnerability is in the function eapol_auth_key_handle, which is called whenever a 4-way handshake messages is received by the AP.
Vulnerable code in IWD.
In line 9 it checks whether the AP has already sent message 1 of the 4-way handshake, i.e. to verify that a handshake is in progress.
However, in lines 12-16 there is no check for whether the AP now expects message 2 or 4. Instead, whatever message arrives next is processed.
This means that when an attacker is connecting to an IWD network, they can skip message 2 and immediately send message 4 in order to gain full access to the network.
In the event of such an attack, IWD will still try to verify the MIC (Message Integrity Code) of the received message 4.
However, it falls back to using an all-zero PTK (Pairwise Transient Key), which is the default in the absence of a valid PTK derived on receipt of message 2, as that step has been skipped in this exploit.
So therefore all an attacker has to do is send a message 4 where the MIC is calculated using an all-zero PTK in order for it to be verified by IWD and the handshake completed.
From this point on, IWD will accept encrypted data frames from the attacker, which are also encrypted using the all-zero PTK, giving them full access to the WiFi network.
Below is an example of a successful attack where messages 2 and 3 are skipped, followed by the exchange of encrypted data frames.
Example of successful exploit of IWD vulnerability.
About Top10VPN’s Security Research
Mathy Vanhoef is a security researcher whose major discoveries have included Dragonblood, KRACK Attack and TunnelCrack.[4][5][6]
He is also a professor in the DistriNet (Distributed Systems and Computer Networks) research group of the Department of Computer Science at KU Leuven, Belgium.
At Top10VPN, we only work with carefully vetted external researchers and ensure the applicable parts of our Responsible Disclosure Policy are followed at all times.
Vulnerabilities identified in this report have been reported to vendors and patched prior to publication.
The authors of all our investigations abide by the journalists’ code of conduct.
References
[1] https://www.statista.com/topics/876/android/#topicOverview ↩
[2] https://dl.acm.org/doi/pdf/10.1145/3495243.3517026 p501-13 ↩
[3] https://www.linux-magazine.com/Issues/2021/243/iNet-Wireless-Daemon ↩
[4] https://www.zdnet.com/article/new-dragonblood-vulnerabilities-found-in-wifi-wpa3-standard/ ↩
[5] https://www.cloudflare.com/en-gb/learning/security/what-is-a-krack-attack/ ↩
[6] https://www.theregister.com/2023/08/10/tunnelcrack_vpn/ ↩
Source: