vanhoefm/macstealerMacStealer: Wi-Fi Client Isolation Bypass
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.
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:
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.
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.
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.
