MacStealer allows for WiFi client isolation bypasses (CVE-2022-47522)

MacStealer: Wi-Fi Client Isolation Bypass

1. Introduction

This repo contains MacStealer. It can test Wi-Fi networks for client isolation bypasses
(CVE-2022-47522). Our attack can intercept (steal) traffic toward other clients at the MAC layer,
even if clients are prevented from communicating with each other. This vulnerability affects Wi-Fi
networks with malicious insiders, where our attack can bypass client isolation, which is sometimes
also known as AP isolation. The attack can also be used to bypass Dynamic ARP inspection (DAI),
and can likely also be used to bypass other methods that prevent clients from attacking each other.
The attack is also known as the security context override attack, see Section 5 of our
USENIX Security ’23 paper (repo).

Concrete examples of possible affected networks are:

• Enterprise networks where users may distrust each other, and where techniques such as client isolation
  or ARP inspection are used to prevent users from attacking each other. For instance, company
  networks with accounts for both guests and staff, networks such as eduroam and govroam, etc.

• Public hotspots protected by Passpoint (formerly Hotspot 2.0).
  These are hotspots that you can automatically and securely connect to. For instance,
  it can seamlessly authenticate you using your phone’s SIM card.

• Home WPA2 or WPA3 networks that have client isolation enabled. This includes networks with
  a separate SSID for guests or for insecure (IoT) devices. It also includes networks where
  multiple passwords are used to further isolate devices, which is also known as
  Multi-PSK,
  Identity PSK,
  per-station PSK,
  or EasyPSK.
  See the threat model discussion for extra info.

• Public hotspots based on WPA3 SAE-PK.
  These are hotspots protected by a shared public password, but where an adversary cannot
  abuse this publicly-known password.

We remark that our attack cannot bypass VLANs. In other words, based on current experiments,
our attack cannot be used to exploit a device in another VLAN.

The repository of other results in our USENIX Security ’23 is also available.

2. Vulnerability details

The core idea behind the attack is that the manner in which clients are authenticated is unrelated to
how packets are routed to the correct Wi-Fi client. Namely, authentication is done based on passwords,
usernames, 802.1X identities, and/or certificates, but once the client has connected the routing of
packets is done based on MAC addresses. A malicious insider can abuse this to intercept data towards
a Wi-Fi client by disconnecting a victim and then connecting under the MAC address of the victim
(using the credentials of the adversary). Any packets that were still underway to the victim,
such website data that the victim was still loading, will now be received by the adversary instead.

More precisely, attack consists of three steps:

1. Letting the victim request data: The adversary first waits until the victim (client)
   establishes a Wi-Fi connection with the vulnerable Access Point (AP). We assume the victim
   will then send a request to a server on the Internet. For instance, the victim may send a
   HTTP request to the (plaintext) website example.com. The goal of the adversary is to
   intercept the response that will be sent by the website.

2. Connecting under the victim’s MAC address: After the victim requested data, for instance
   by sending a HTTP Request packet, the adversary will forcibly disconnect the victim from the
   network before the response arrives at the
   vulnerable AP. In our example, this means the victim is disconnected before the response from
   example.com arrives at the AP. Once the victim is disconnected, the adversary spoofs
   the MAC address of the victim and the adversary will connect to the network using their own
   credentials. This means the adversary is a malicious insider that can connect using their own
   credentials to the network, for instance, using their own username and password in an
   Enterprise Wi-Fi network.

3. Intercepting the response: Once the adversary connected under the MAC address of the victim,
   the AP will associate the adversary’s newly generated encryption keys with the victim’s MAC address.
   As a result, when the response from the server arrives at the Wi-Fi network, or any incoming traffic
   towards the victim in general, the router will forward these incoming packets to the victim’s
   MAC address. In our example, this means the response from example.com is forwarded by the router
   to the victim’s MAC address. However, the adversary is now using this MAC address. This means the
   AP will encrypt the response using the keys of the adversary. In other words, the adversary will
   now recieve any pending traffic that is still underway the victim.

We remark that intercepted traffic may be protected by higher-layer encryption, such as TLS and HTTPS.
Nevertheless, even if higher-layer encryption is being used, our attack still reveals
the IP address that a victim is communicating with. This in turn reveals the websites that a victim
is visiting, which can be sensitive information on its own.

By default, the attack does not intercept traffic sent by the victim, but can only intercept
traffic sent towards the victim. However, an adversary can attempt subsequent attacks to also
intercept traffic sent by the victim. In particular, by intercepting a DNS reply to the victim,
the adversary can spoof a DNS reply and intercept all IP traffic both sent towards and sent by
victim.

Performing the above attack only makes sense when client isolation is enabled in the target network.
Otherwise, if client isolation is disabled, a malicious insider can just directly attack other
clients using techniques such as ARP spoofing (see the
client isolation tests).

The attack is identical against Enterprise WPA1, WPA2 and WPA3 networks. This is because the attack
does not exploit any cryptographic properties of Wi-Fi, but instead abuses how a network determines
to which client packets should be sent, i.e., routed, to.

For extra details on the attack, see the security context override attack (Section 5) in our paper
Framing Frames: Bypassing Wi-Fi Encryption by Manipulating Transmit Queues.

3. Possible mitigations

3.1. Preventing MAC address stealing

To mitigate our attack, an AP can temporarily prevent clients from connecting if they are using
a MAC address that was recently connected to the AP. This prevents an adversary from spoofing a
MAC address and intercepting pending or queued frames towards a victim. When it can be guaranteed
that the user behind a MAC address has not changed, the client can be allowed to immediately reconnect.
Note that this check must be done over all APs that are part of the same distribution system, and
more specifically, over all APs that clients can roam between while keeping their current IP address.

To securely recognize recently-connected users, an AP can store a mapping between a client’s MAC
address and their cached security associations (e.g., their cached PMK). A client can be allowed
to immediately (re)connect under a recently-used MAC address by proving that they posses the cached
security association linked to this MAC address, e.g., by connecting using the correct cached PMK.

When using multi-PSK, which is also known as per-station PSK
or Identity PSK,
the AP can keep a mapping of recently connected MAC addresses and the (unique) password that they used.
When a client connects, the AP checks whether its MAC address was recently used. If it isn’t, or if it
is and the client is using the same password as before, the client can connect as normal. However,
if the same MAC address is used with a different password, the client is forced to wait a predefined
amount of time before being able to successfully connect.

When using SAE-PK to secure hotspots, the only method that we are aware of to securely recognize
that a MAC address is being reused by the same user as before, is by relying on cached security
associations (e.g., the cached PMK linked to the MAC address).

The above defenses assume that, after a certain delay, no more pending packets will arrive for the
victim. To prevent leaks beyond this delay, clients can use end-to-end encryption (such as TLS)
with the services they communicate with.

3.2. 802.1X authentication and RADIUS extensions

Another method to securely recognize recently-connected users is based on the EAP identity they
used during 802.1X authentication. An AP can securely learn the EAP identity from the RADIUS server
that authenticated the client, and can keep a mapping of recently connected MAC addresses
and their corresponding EAP identity. When a client connects, the AP checks whether its MAC address
was recently used. If it isn’t, or if it is and the client is using the same EAP identity as before,
the client can connect as normal. However, if the same MAC address is used under a different EAP
identity, the client is forced to wait a predefined amount of time before being able to connect
successfully.

One challenge is that the AP may not always know the 802.1X identity of a client due to privacy
concerns. For instance, this information may only be available at the home AAA server, and the AP
will only receive a Chargeable User Identity from the RADIUS server. This identity does not allow the
AP to recognize two associations of the same device/credentials because its value may constantly
change. The AP does receive the anonymous identity in the EAP-Response/Identity, such as anonymous@realm,
and can rely on that to at least recognize users from different realms.

To prevent users in the same realm from attacking each other, without revealing a client’s
identity to the AP, cooperation and changes to the RADIUS server are needed. In particular,
the RADIUS server can be updated to help detect if the MAC address was recently being used by
another user in the same realm (in the given local network). The RADIUS server would then need
to be informed when a client disconnects, so it knows when a MAC address was last being used by
one of its users, and needs to be informed of the MAC address of any client that is trying to connect.

3.3. Protecting the gateway’s MAC address

Important to note is that our attack is not limited to intercepting packets going to
Wi-Fi clients. An adversary could also try to associate with a MAC address of a default
gateway or another server in the local network. To prevent such attacks, the AP or
controller can prohibit clients from using a MAC address equal to the default gateway.
More generally, duplicate MAC address detection can be used when a Wi-Fi client is
connecting to the network, to prevent Wi-Fi clients from using a MAC address that is
also in use by other devices in the network.

3.4. Management Frame Protection (802.11w)

Using Management Frame Protection (MFP) would make the attack harder but not impossible.
In previous work, we found some ways
that clients can be disconnected/deauthenticated even when MFP is being used. Based on that
experience, there always appears to be some method to forcibly disconnect a client from the
network, even when MFP is being used. Put differently, it’s hard to completely prevent
disconnection and deauthentication attacks. That being said, MFP would be extra hurdle to
overcome when performing the attack in practice, so it can be useful mitigation to make the
attack harder (but not impossible) in practice.

3.5. Usage of VLANs

Based on preliminary experiments, the attack does not work across different VLANs. In other
words, the malicious insider that performs the attack must be in the same VLAN as the victim.
One mitigation is therefore to put different groups of users in different VLANs. However,
a malicious insider would still be able to perform the attack (i.e., bypass client isolation)
against other users in the same VLAN.

Note that when using multi-PSK (a.ka. per-station PSK or identity PSK), you can put clients
in different VLANs depending on the password that they use. In other words, you can use a VLAN
for each password. This prevents clients with different passwords from attacking each other.

4. Tool Prerequisites

The MacStealer tool works with any network card that is supported by Linux. We tested
MacStealer on Ubuntu 22.04. To install the required dependencies on Ubuntu 22.04 execute:

sudo apt update
sudo apt install libnl-3-dev libnl-genl-3-dev libnl-route-3-dev libssl-dev 
	libdbus-1-dev git pkg-config build-essential net-tools python3-venv 
	aircrack-ng rfkill

Now clone this repository, build the tools, and configure a virtual python3 environment:

git clone https://github.com/vanhoefm/macstealer.git macstealer
cd macstealer/research
./build.sh
./pysetup.sh

The above instructions only have to be executed once.

After pulling in new code using git you do have to execute ./build.sh and ./pysetup.sh again.
See the change log for a detailed overview of updates to the MacStealer
since the coordinated disclosure started.

5. Before every usage

5.1 Execution environment

Every time you want to use MacStealer, you first have to load the virtual python3 environment
as root. This can be done using:

cd research
sudo su
source venv/bin/activate

You should now disable Wi-Fi in your network manager
so it will not interfere with MacStealer. Optionally check using sudo airmon-ng check to see
which other processes might be using the wireless network card and might interfere with MacStealer.

5.2. Network configuration

The next step is to edit client.conf with the information of the network that you want to test.
This is a configuration for wpa_supplicant
that must contain two network blocks: one representing the victim and one representing
the attacker. An example configuration file to test the fictitious network kuleuven is:

# Don't change this line, other MacStealer won't work
ctrl_interface=wpaspy_ctrl

network={
	# Don't change this field, the script relies on it
	id_str="victim"

	# Network to test: fill in properties of the network to test
	ssid="kuleuven"
	key_mgmt=WPA-EAP
	eap=PEAP
	phase2="auth=MSCHAPV2"

	# Victim login: fill in login credentials representing the victim
	identity="th***********@******en.be"
	password="SuperSecret"
}

network={
	# Don't change this field, the script relies on it
	id_str="attacker"

	# Network to test: you can copy this from the previous block
	ssid="kuleuven"
	key_mgmt=WPA-EAP
	eap=PEAP
	phase2="auth=MSCHAPV2"

	# Attacker login: fill in login credentials representing the attacker
	identity="so**********@**************en.be"
	password="SomePassword"
}

In the part “network to test” you must provide the name of the network being tested and its
security configuration. See wpa_supplicant.conf for
documentation on to write/edit configuration files and for example network blocks for various
types of Wi-Fi networks. In the first network block, under “victim login”, you must specify
valid login credentials that represents the simulated victim. In the second network block,
you can provide exactly the same information under “network to test”, but you must provide
login credentials that represent the simulated attacker.

In the above example, MacStealer will test an attack where the adverary is so**********@**************en.be
and this adversary will try to intercept traffic sent towards the victim th***********@******en.be.

By default the script uses the configuration file client.conf. You can use a different
configuration file by providing the --config network.conf paramater, where you can replace
network.conf with the configuration file that you want to use.

This repository also contains the following example configuration files:

• multipsk.conf: A configuration file to test a network that
  uses multi-PSK where one password is used by trusted devices and a second password is
  given to guests.

• saepk.conf: A configuration file to test a public hotspot that
  uses SAE-PK.

Note that it is also possible to edit the network block(s) to test a specific AP/BSS.

5.3. Server configuration

By default, MacStealer will send a TCP SYN packet to 8.8.8.8 at port 443 in all tests, which is a
DNS server of Google. If you want to use a different server or port, you can provide one using
the --server parameter. For instance:

./macstealer.py wlan0 --server 208.67.222.222

You can also add the port that must be used in the TCP SYN packets:

./macstealer.py wlan0 --server 208.67.222.222:80

Replace wlan0 with the name of your Wi-Fi interface and the IP address with the server
that you want to use.
This server must retransmit TCP SYN/ACK replies and should, ideally, still send a retransmitted
SYN/ACK more than 10 seconds after MacStealer transmitted the initial TCP SYN. You can
test this retransmission behaviour using the --ping parameter as follows:

./macstealer.py wlan0 --server 208.67.222.222 --ping

MacStealer will output the following in case the server has the required retransmission
behaviour:

./macstealer.py wlan0 --c2c-ip wlan1 [--flip-id]

...

network={
	# Don't change this field, the script relies on it
	id_str="victim"

	# Network to test: fill in properties of the network to test
	ssid="kuleuven"
	key_mgmt=WPA-EAP
	eap=PEAP
	phase2="auth=MSCHAPV2"

	# Victim login: fill in login credentials representing the victim
	identity="th***********@******en.be"
	password="SuperSecret"

	# This a specific AP/BSS
	bssid=00:11:22:33:44:55
}

...

# Don't change this line, other MacStealer won't work
ctrl_interface=wpaspy_ctrl

# WPA3/SAE: support both hunting-and-pecking loop and hash-to-element
sae_pwe=2

network={
	# Don't change this field, the script relies on it
	id_str="attacker"

	# Network to test - attacker login
	ssid="test-saepk"
	psk="7iip-ytnz-qa25"
	key_mgmt=SAE
	ieee80211w=2
}

network={
	# Don't change this field, the script relies on it
	id_str="victim"

	# Network to test - victim login
	ssid="test-saepk"
	psk="7iip-ytnz-qa25"
	key_mgmt=SAE
	ieee80211w=2
}