New WiFi Authentication Vulnerabilities Discovered

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.^[1]

The wpa_supplicant software 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 the wpa_supplicant vulnerability 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 for wpa_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.

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.

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

1. The attacker needs to know the SSID of the target Enterprise WPA2/3 network
2. 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
3. wpa_supplicant must 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.

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.

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.

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.

^{[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/ ↩}