As far as I can tell, all of these attacks require the attacker to already be associated to a victim's network. Most of these attacks seem similar to ones expected on shared wifi (airports, cafes) that have been known about for a while. The novel attacks seem to exploit weaknesses in particular router implementations that didn't actually segregate traffic between guest and normal networks.
I'm curious if I missed something because that doesn't sound like it allows the worst kind of attacks, e.g. drive-by with no ability to associate to APs without cracking keys.
show comments
ProllyInfamous
>Unlike previous Wi-Fi attacks, AirSnitch exploits core features in Layers 1 and 2 and the failure to bind and synchronize a client across these and higher layers, other nodes, and other network names such as SSIDs (Service Set Identifiers). This cross-layer identity desynchronization is the key driver of AirSnitch attacks.
>The most powerful such attack is a full, bidirectional machine-in-the-middle (MitM) attack, meaning the attacker can view and modify data before it makes its way to the intended recipient. The attacker can be on the same SSID, a separate one, or even a separate network segment tied to the same AP. It works against small Wi-Fi networks in both homes and offices and large networks in enterprises.
----
I wardrove back in the early 2000s (¡WEP lol!). Spent a few years working in data centers. Now, reasonably paranoid. My personal network does not implement WiFi; my phone is an outgoing landline; tape across laptop cameras, disconnected antenna; stopped using email many years ago...
Technology is so fascinating, but who can secure themselves from all the vulnerabilities that radio EMF presents? Just give me copper/fiber networks, plz.
----
>the next step is to put [AirSnitch] into historical context and assess how big a threat it poses in the real world. In some respects, it resembles the 2007 PTW attack ... that completely and immediately broke WEP, leaving Wi-Fi users everywhere with no means to protect themselves against nearby adversaries. For now, client isolation is similarly defeated—almost completely and overnight—with no immediate remedy available.
show comments
jwr
Incidentally, this client isolation thing can be extremely annoying in practice in networks you do not control. Hardware device makers just assume that everything is on One Big Wi-Fi Network and all devices can talk to all other devices and sing Kum-Ba-Yah by the fire.
Then comes network isolation and you can no longer turn on your Elgato Wi-Fi controlled light, talk to your Bose speaker, or use a Chromecast.
show comments
sippeangelo
Bit of a sensational title? This doesn't "break WiFi encryption", only device isolation if the attacker is already in the same network.
show comments
economistbob
I just read the paper, and my take is that practically every home wifi user can now get pwned since most WiFi routers use the same SSID and 2.4 and 5Ghz. It can even beat people using Radius authentication, but they did not deep dive on that one. I am curious about whether the type of EAP matters for reading the traffic.
Essentially everyone with the SSID on multiple access point MAC addresses can get pwned.
Neighhood hackers drove me to EAP TLS a few years ago, and I only have it on one frequency, so the attack will not work.
The mitigation is having only a single MAC for the AP that you can connect to. The attack relies on bouncing between two. A guest and regular, or a 2.4 and 5, etc.
I need to research more to know if they can read all the packets if they pull it off on EAP TLS, with bounces between a 2.4 and 5 ghz.
It is a catastrophic situation unless you are using 20 year old state of the art rather that multi spectrum new hotness.
It might even get folks on a single SSID MAC if they do not notice the denial of service taking place. I need to research the radius implications more. TLS never sends credentials over the channel like the others. It needs investigation to know if they get the full decryption key from EAP TLS during. They were not using TLS because their tests covered Radius and the clients sending credentials.
It looks disastrous if the certificates of EAP TLS do not carry the day and they can devise the key.
That is my take.
show comments
jcalvinowens
This is a big deal: it means a client on one wifi network can MITM anything on any other wifi network hosted on the same AP, even if the other wifi network has different credentials. Pretty much every enterprise wifi deployment I've ever seen relies on that isolation for security.
These attacks are not new: the shocking thing here that apparently a lot of enterprise hardware doesn't do anything to mitigate these trivial attacks!
"If the network is properly secured—meaning it’s protected by a strong password that’s known only to authorized users—AirSnitch may not be of much value to an attacker."
show comments
zekica
This only works for one SSID. Even then, one thing that can mitigate this is using Private-PSK/Dynamic-PSK on WPA2, or using EAP/Radius VLAN property.
On WPA3/SAE this is more complicated: the standard supports password identifiers but no device I know of supports selecting an alternate password aside from wpa_supplicant on linux.
show comments
madjam002
Does anyone know of any good firewalls for macOS? The built in firewall is practically unusable, and if client isolation can be bypassed, the local firewall is more important than ever.
I often have a dev server running bound to 0.0.0.0 as it makes debugging easy at home on the LAN, but then if I connect to a public WiFi I want to know that I am secure and the ports are closed. "Block all incoming connections" on macOS has failed me before when I've tested it.
show comments
this-is-why
Even if they can rewrite the MAC and force a new one via ping, which are usually already disabled, they still can’t eavesdrop on the TLS key exchange. I fail to see how this is a risk to HTTPS traffic? It’s a mitm sure but it is watching encrypted traffic.
show comments
kevincloudsec
every tested router was vulnerable to at least one variant. that's what happens when a security feature gets adopted industry-wide without ever being standardized, not a bug.
blobbers
If you're a panicking IT guy, from the original paper:
"WPA2/3-Enterprise. These attacks generally do not work
against WPA2/3-Enterprise networks..."
So this is a protocol attack, not an encryption attack. If you're using proper encryption per client, there is no attack available.
show comments
mlhpdx
It seems like this attack would be thwarted by so called “multi PSK” networks (non-standard but common tech that allows giving each client their own PSK on the same SSID). Is that true?
show comments
sgalbincea
I'd like to see more enterprise-grade equipment tested.
ErneX
The attacker needs to be connected to a wireless network if I understood this correctly?
show comments
fabioyy
macsec can encrypt data in ethernet for lan, maybe it can solve this
api
Client isolation is helpful in the real world, but it's yet another band aid for the deeper more fundamental problem.
If a device is insecure when placed directly onto the Internet with no firewall, it is insecure. Full stop. Everything else is a hack around that fact. Sometimes you have to do that since you can't fix broken stuff, but it's still broken.
To prevent malicious Wi-Fi clients from attacking other clients on the same network, vendors have introduced client isolation, a combination of mechanisms that block direct communication between clients. However, client isolation is not a standardized feature, making its security guarantees unclear. In this paper, we undertake a structured security analysis of Wi-Fi client isolation and uncover new classes of attacks that bypass this protection. We identify several root causes behind these weaknesses. First, Wi-Fi keys that protect broadcast frames are improperly managed and can be abused to bypass client isolation. Second, isolation is often only enforced at the MAC or IP layer, but not both. Third, weak synchronization of a client’s identity across the network stack allows one to bypass Wi-Fi client isolation at the network layer instead, enabling the interception of uplink and downlink traffic of other clients as well as internal backend devices. Every tested router and network was vulnerable to at least one attack. More broadly, the lack of standardization leads to inconsistent, ad hoc, and often incomplete implementations of isolation across vendors. Building on these insights, we design and evaluate end-toend attacks that enable full machine-in-the-middle capabilities in modern Wi-Fi networks. Although client isolation effectively mitigates legacy attacks like ARP spoofing, which has long been considered the only universal method for achieving machinein-the-middle positioning in local area networks, our attack introduces a general and practical alternative that restores this capability, even in the presence of client isolation.
show comments
kittikitti
Other members of my household frequently invite people to my own place that have malicious intent against me. They don't like me for reasons like not being a fan of Trump, Drake, or N3on. Unfortunately, this is a risk that many people other than me have to face. This is an eye-opening article as I do provide my guest password to them.
I plan on disabling the guest network entirely and utilizing a completely different router for the guest network. As the paper states, an isolated guest network isn't standardized. I plan on revisiting my network security once it is.
iamnothere
Once again I feel justified in hard wiring all connections. I do have a wireless network for a couple of portable devices, but everything else has a plug and a VLAN.
It’s very difficult to have too much network security.
Has China become so prominent in security research?
bell-cot
On the one hand, a seems-solid article by an author I mostly trust.
OTOH... with the recent journalistic scandal at Ars Technica, perhaps Dan should have made sure that he spelled "Ubiquity" correctly? (5th para; it's correct further down.)
As far as I can tell, all of these attacks require the attacker to already be associated to a victim's network. Most of these attacks seem similar to ones expected on shared wifi (airports, cafes) that have been known about for a while. The novel attacks seem to exploit weaknesses in particular router implementations that didn't actually segregate traffic between guest and normal networks.
I'm curious if I missed something because that doesn't sound like it allows the worst kind of attacks, e.g. drive-by with no ability to associate to APs without cracking keys.
>Unlike previous Wi-Fi attacks, AirSnitch exploits core features in Layers 1 and 2 and the failure to bind and synchronize a client across these and higher layers, other nodes, and other network names such as SSIDs (Service Set Identifiers). This cross-layer identity desynchronization is the key driver of AirSnitch attacks.
>The most powerful such attack is a full, bidirectional machine-in-the-middle (MitM) attack, meaning the attacker can view and modify data before it makes its way to the intended recipient. The attacker can be on the same SSID, a separate one, or even a separate network segment tied to the same AP. It works against small Wi-Fi networks in both homes and offices and large networks in enterprises.
----
I wardrove back in the early 2000s (¡WEP lol!). Spent a few years working in data centers. Now, reasonably paranoid. My personal network does not implement WiFi; my phone is an outgoing landline; tape across laptop cameras, disconnected antenna; stopped using email many years ago...
Technology is so fascinating, but who can secure themselves from all the vulnerabilities that radio EMF presents? Just give me copper/fiber networks, plz.
----
>the next step is to put [AirSnitch] into historical context and assess how big a threat it poses in the real world. In some respects, it resembles the 2007 PTW attack ... that completely and immediately broke WEP, leaving Wi-Fi users everywhere with no means to protect themselves against nearby adversaries. For now, client isolation is similarly defeated—almost completely and overnight—with no immediate remedy available.
Incidentally, this client isolation thing can be extremely annoying in practice in networks you do not control. Hardware device makers just assume that everything is on One Big Wi-Fi Network and all devices can talk to all other devices and sing Kum-Ba-Yah by the fire.
Then comes network isolation and you can no longer turn on your Elgato Wi-Fi controlled light, talk to your Bose speaker, or use a Chromecast.
Bit of a sensational title? This doesn't "break WiFi encryption", only device isolation if the attacker is already in the same network.
I just read the paper, and my take is that practically every home wifi user can now get pwned since most WiFi routers use the same SSID and 2.4 and 5Ghz. It can even beat people using Radius authentication, but they did not deep dive on that one. I am curious about whether the type of EAP matters for reading the traffic.
Essentially everyone with the SSID on multiple access point MAC addresses can get pwned.
Neighhood hackers drove me to EAP TLS a few years ago, and I only have it on one frequency, so the attack will not work.
The mitigation is having only a single MAC for the AP that you can connect to. The attack relies on bouncing between two. A guest and regular, or a 2.4 and 5, etc.
I need to research more to know if they can read all the packets if they pull it off on EAP TLS, with bounces between a 2.4 and 5 ghz.
It is a catastrophic situation unless you are using 20 year old state of the art rather that multi spectrum new hotness.
It might even get folks on a single SSID MAC if they do not notice the denial of service taking place. I need to research the radius implications more. TLS never sends credentials over the channel like the others. It needs investigation to know if they get the full decryption key from EAP TLS during. They were not using TLS because their tests covered Radius and the clients sending credentials.
It looks disastrous if the certificates of EAP TLS do not carry the day and they can devise the key.
That is my take.
This is a big deal: it means a client on one wifi network can MITM anything on any other wifi network hosted on the same AP, even if the other wifi network has different credentials. Pretty much every enterprise wifi deployment I've ever seen relies on that isolation for security.
These attacks are not new: the shocking thing here that apparently a lot of enterprise hardware doesn't do anything to mitigate these trivial attacks!
Paper discussed in this article: https://www.ndss-symposium.org/ndss-paper/airsnitch-demystif...
Had to read through all the cruft to get:
"If the network is properly secured—meaning it’s protected by a strong password that’s known only to authorized users—AirSnitch may not be of much value to an attacker."
This only works for one SSID. Even then, one thing that can mitigate this is using Private-PSK/Dynamic-PSK on WPA2, or using EAP/Radius VLAN property.
On WPA3/SAE this is more complicated: the standard supports password identifiers but no device I know of supports selecting an alternate password aside from wpa_supplicant on linux.
Does anyone know of any good firewalls for macOS? The built in firewall is practically unusable, and if client isolation can be bypassed, the local firewall is more important than ever.
I often have a dev server running bound to 0.0.0.0 as it makes debugging easy at home on the LAN, but then if I connect to a public WiFi I want to know that I am secure and the ports are closed. "Block all incoming connections" on macOS has failed me before when I've tested it.
Even if they can rewrite the MAC and force a new one via ping, which are usually already disabled, they still can’t eavesdrop on the TLS key exchange. I fail to see how this is a risk to HTTPS traffic? It’s a mitm sure but it is watching encrypted traffic.
every tested router was vulnerable to at least one variant. that's what happens when a security feature gets adopted industry-wide without ever being standardized, not a bug.
If you're a panicking IT guy, from the original paper:
"WPA2/3-Enterprise. These attacks generally do not work against WPA2/3-Enterprise networks..."
So this is a protocol attack, not an encryption attack. If you're using proper encryption per client, there is no attack available.
It seems like this attack would be thwarted by so called “multi PSK” networks (non-standard but common tech that allows giving each client their own PSK on the same SSID). Is that true?
I'd like to see more enterprise-grade equipment tested.
The attacker needs to be connected to a wireless network if I understood this correctly?
macsec can encrypt data in ethernet for lan, maybe it can solve this
Client isolation is helpful in the real world, but it's yet another band aid for the deeper more fundamental problem.
If a device is insecure when placed directly onto the Internet with no firewall, it is insecure. Full stop. Everything else is a hack around that fact. Sometimes you have to do that since you can't fix broken stuff, but it's still broken.
I think this might be the repo?
https://github.com/zhouxinan/airsnitch
Edit: it’s the same repo as linked in the paper, so it seems likely to be the correct repo, though I didn’t originally find it via the paper.
The article is hot garbage, here's the abstract from the paper (https://www.ndss-symposium.org/ndss-paper/airsnitch-demystif...):
To prevent malicious Wi-Fi clients from attacking other clients on the same network, vendors have introduced client isolation, a combination of mechanisms that block direct communication between clients. However, client isolation is not a standardized feature, making its security guarantees unclear. In this paper, we undertake a structured security analysis of Wi-Fi client isolation and uncover new classes of attacks that bypass this protection. We identify several root causes behind these weaknesses. First, Wi-Fi keys that protect broadcast frames are improperly managed and can be abused to bypass client isolation. Second, isolation is often only enforced at the MAC or IP layer, but not both. Third, weak synchronization of a client’s identity across the network stack allows one to bypass Wi-Fi client isolation at the network layer instead, enabling the interception of uplink and downlink traffic of other clients as well as internal backend devices. Every tested router and network was vulnerable to at least one attack. More broadly, the lack of standardization leads to inconsistent, ad hoc, and often incomplete implementations of isolation across vendors. Building on these insights, we design and evaluate end-toend attacks that enable full machine-in-the-middle capabilities in modern Wi-Fi networks. Although client isolation effectively mitigates legacy attacks like ARP spoofing, which has long been considered the only universal method for achieving machinein-the-middle positioning in local area networks, our attack introduces a general and practical alternative that restores this capability, even in the presence of client isolation.
Other members of my household frequently invite people to my own place that have malicious intent against me. They don't like me for reasons like not being a fan of Trump, Drake, or N3on. Unfortunately, this is a risk that many people other than me have to face. This is an eye-opening article as I do provide my guest password to them.
I plan on disabling the guest network entirely and utilizing a completely different router for the guest network. As the paper states, an isolated guest network isn't standardized. I plan on revisiting my network security once it is.
Once again I feel justified in hard wiring all connections. I do have a wireless network for a couple of portable devices, but everything else has a plug and a VLAN.
It’s very difficult to have too much network security.
Tangentially, does anyone know why so many of the (enormous amount of) papers accepted at this San Diego conference is from Chinese researchers? (https://www.ndss-symposium.org/ndss2026/accepted-papers)
Has China become so prominent in security research?
On the one hand, a seems-solid article by an author I mostly trust.
OTOH... with the recent journalistic scandal at Ars Technica, perhaps Dan should have made sure that he spelled "Ubiquity" correctly? (5th para; it's correct further down.)
Original source (should replace the current link): https://www.ndss-symposium.org/wp-content/uploads/2026-f1282...
Summary: https://www.ndss-symposium.org/ndss-paper/airsnitch-demystif... (hat tip: https://news.ycombinator.com/item?id=47167975)