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.
Yeah, this is a much clearer source and the abstract gets pretty directly to the point. The first paragraph tells you pretty much everything you need to know before you read more. The Ars article took 4 paragraphs to mention "client isolation" and even longer to get into the meat.
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.
The attacker doesn't need to be connected to the victim's network, only to the same hardware, the hardware's loss of isolation is the unexpected problem.
Their University example is pertinent. The victim is an Eduroam user, and the attacker never has any Eduroam credentials, but the same WiFi hardware is serving both eduroam and the local guest provision which will be pretty bare bones, so the attacker uses the means described to start getting packets meant for that Eduroam user.
If you only have a single appropriately authenticated WiFi network then the loss of isolation doesn't matter, in the same way that a Sandbox escape in your web browser doesn't matter if you only visit a single trusted web site...
I should reinforce this point by saying that it's the default position for "guest" networks to be using the same hardware as "secure" office wifi and such.
It sounds like this attack would work in that scenario provided the attacker is able to connect to the guest access point.
I haven’t paid attention to one in a while but I seem to remember the need to authenticate with the guest network using Xfinity credentials. This at least makes it so attribution might be possible.
That's my read as well. It's bad for places that rely on client isolation, but not really for the general case. I feel like this also overstates the "stealing authentication cookies": most people's cookies will be protected by TLS rather than physical layer protection.
>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.
For a second I thought this was the Mel Gibson movie where he proves a Conspiracy Theory (1997)... but Gene Hackman, post-Watergate — with an ensemble cast of eavesdroppers?! — tonight's movie, decided.
Thank you for your recommendation - it be crazy up in here (head, country, world).
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 evvery enterprise wifi deployment I've ever seen does that.
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!
It's not a big deal because the Ars Technica summarisation is wrong. You can (and enterprise controllers do in fact) tie IPs and MACs to association IDs (8bit number per BSS) and thus prevent this kind of spoofing. I haven't had time to read the paper yet to check what it says on this.
Also client isolation is not considered "needed" in home/SOHO networks because this kind of attack is kinda assumed out of scope; it's not even tried to address this. "If you give people access to your wifi, they can fuck with your wifi devices." This should probably be communicated more clearly, but any claims on this attack re. home networks are junk.
you are definitely correct that it is potentially a big deal because it breaks expectation around network segmentation and isolation
however, most people will read "breaks wi-fi encryption" and assume that it means that someone can launch this attack while wardriving, which they cant.
>assume that it means that someone can launch this attack while wardriving, which they cant.
As a former wardriver (¡WEPlol!), it only makes this more difficult. In my US city every home/business has a fiber/copper switch, usually outside. A screw-driver and you're in.
Granted, this now becomes a physical attack (only for initial access) — but still viable.
----
>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.
----
I think the article's main point is that so many places have similarly-such-unsecured plug-in points. Perhaps even a user was authorized for one WiFi network segment, and is already "in" — bless this digital mess!
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.
Little Snitch is a user-friendly, software-level blocker, only – use with caution.
Just FYI: LittleSnitch pre-resolves DNS entries BEFORE you click `Accept/Deny`, if you care & understand this potential security issue. Your upstream provider still knows whether you denied a query. Easily verifiable with a PiHole (&c).
I liken the comparison to disk RAIDs: a RAID is not a true backup; LittleSnitch is not a true firewall.
You need isolated hardware for true inbound/outbound protection.
>Just FYI: LittleSnitch pre-resolves DNS entries BEFORE you click `Accept/Deny`, if you care & understand this potential security issue. Your upstream provider still knows whether you denied a query. Easily verifiable with a PiHole (&c).
This also feels like an exfil route? Are DNS queries (no tcp connect) logged/blocked?
When you see the LittleSnitch dialogue (asking to `Accept/Deny`), whatever hostname is there has already been pre-resolved by upstream DNS provider (does not matter which option you select). This software pares well with a PiHole (for easy layperson installs), but even then is insufficient for OP's attack.
"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."
IIUC the issue is, you could have a "secure" network and a guest network sharing an AP, and that guest network can access clients on the secure network. Someone did mention the xfinity automatic guest network, which might be a pain to disable?
This is likely not a big deal for your home network, if you only have one network, but for many enterprise setups probably much worse.
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.
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.
The Ars article mentions: “Even when HTTPS is in place, an attacker can still intercept domain look-up traffic and use DNS cache poisoning to corrupt tables stored by the target’s operating system.” Not sure, but I think this could then be further used for phishing.
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.
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.
Maybe I've just lost all patience for fluff, but I gave up trying to figure out what the attack was from the article pretty quickly where the abstract answered all my questions immediately.
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.)
I was indeed very surprised to see that it's from Dan Goodin
I only read his articles occasionally, but they always impressed me favorably; this one instead... the paper is probably clearer even for less technical people.
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.
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.
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)
@dang, can we get the link and title changed?
Yeah, this is a much clearer source and the abstract gets pretty directly to the point. The first paragraph tells you pretty much everything you need to know before you read more. The Ars article took 4 paragraphs to mention "client isolation" and even longer to get into the meat.
Ars is a very fitting name
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.
The attacker doesn't need to be connected to the victim's network, only to the same hardware, the hardware's loss of isolation is the unexpected problem.
Their University example is pertinent. The victim is an Eduroam user, and the attacker never has any Eduroam credentials, but the same WiFi hardware is serving both eduroam and the local guest provision which will be pretty bare bones, so the attacker uses the means described to start getting packets meant for that Eduroam user.
If you only have a single appropriately authenticated WiFi network then the loss of isolation doesn't matter, in the same way that a Sandbox escape in your web browser doesn't matter if you only visit a single trusted web site...
Yeah, that commercial-grade hardware didn't actually isolate at the PHY-MAC layer is a bit surprising. How would they have working VLANs at the AP?
I should reinforce this point by saying that it's the default position for "guest" networks to be using the same hardware as "secure" office wifi and such.
What about XFinity, which by default shares the wifi you pay for with strangers to create access points around the city?
It sounds like this attack would work in that scenario provided the attacker is able to connect to the guest access point.
I haven’t paid attention to one in a while but I seem to remember the need to authenticate with the guest network using Xfinity credentials. This at least makes it so attribution might be possible.
This is probably the biggest issue.
I turn WiFi mine off and use my own WiFi ap.
That's my read as well. It's bad for places that rely on client isolation, but not really for the general case. I feel like this also overstates the "stealing authentication cookies": most people's cookies will be protected by TLS rather than physical layer protection.
Still an interesting attack though.
That’s my read as well. It’s not good, but it’s not nearly as bad as the headline makes it sound.
>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.
You would like the film The Conversation (1974).
For a second I thought this was the Mel Gibson movie where he proves a Conspiracy Theory (1997)... but Gene Hackman, post-Watergate — with an ensemble cast of eavesdroppers?! — tonight's movie, decided.
Thank you for your recommendation - it be crazy up in here (head, country, world).
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 evvery enterprise wifi deployment I've ever seen does that.
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!
Like as in me being on the Guest network at a business can then read traffic of the Corporate network?
> Like as in me being on the Guest network at a business can then read traffic of the Corporate network?
Exactly.
Bit of a sensational title? This doesn't "break WiFi encryption", only device isolation if the attacker is already in the same network.
Many businesses and universities, and likely some government offices, rely on client isolation for segmenting their networks. It’s a big deal.
It's not a big deal because the Ars Technica summarisation is wrong. You can (and enterprise controllers do in fact) tie IPs and MACs to association IDs (8bit number per BSS) and thus prevent this kind of spoofing. I haven't had time to read the paper yet to check what it says on this.
Also client isolation is not considered "needed" in home/SOHO networks because this kind of attack is kinda assumed out of scope; it's not even tried to address this. "If you give people access to your wifi, they can fuck with your wifi devices." This should probably be communicated more clearly, but any claims on this attack re. home networks are junk.
you are definitely correct that it is potentially a big deal because it breaks expectation around network segmentation and isolation
however, most people will read "breaks wi-fi encryption" and assume that it means that someone can launch this attack while wardriving, which they cant.
>assume that it means that someone can launch this attack while wardriving, which they cant.
As a former wardriver (¡WEPlol!), it only makes this more difficult. In my US city every home/business has a fiber/copper switch, usually outside. A screw-driver and you're in.
Granted, this now becomes a physical attack (only for initial access) — but still viable.
----
>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.
----
I think the article's main point is that so many places have similarly-such-unsecured plug-in points. Perhaps even a user was authorized for one WiFi network segment, and is already "in" — bless this digital mess!
Meh. The computers that:
- must not be accessible because their services don't use authentication/encryption
- and share a wifi with potential attackers
is just not that large.
They exist, but the vast majority runs in places that don't care about security all that much.
This should be a signal to fix the two things I mention, not to improve their wifi/firewall security.
Anyone who relies on client isolation was just waiting to get pwned anyway.
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.
Little Snitch is probably the most popular one, written my devs who deeply understand macOS firewall architecture.
https://obdev.at/products/littlesnitch/index.html
Little Snitch is a user-friendly, software-level blocker, only – use with caution.
Just FYI: LittleSnitch pre-resolves DNS entries BEFORE you click `Accept/Deny`, if you care & understand this potential security issue. Your upstream provider still knows whether you denied a query. Easily verifiable with a PiHole (&c).
I liken the comparison to disk RAIDs: a RAID is not a true backup; LittleSnitch is not a true firewall.
You need isolated hardware for true inbound/outbound protection.
>Just FYI: LittleSnitch pre-resolves DNS entries BEFORE you click `Accept/Deny`, if you care & understand this potential security issue. Your upstream provider still knows whether you denied a query. Easily verifiable with a PiHole (&c).
This also feels like an exfil route? Are DNS queries (no tcp connect) logged/blocked?
>Are DNS queries blocked?
No, not with LittleSnitch (neither in/out-bound).
When you see the LittleSnitch dialogue (asking to `Accept/Deny`), whatever hostname is there has already been pre-resolved by upstream DNS provider (does not matter which option you select). This software pares well with a PiHole (for easy layperson installs), but even then is insufficient for OP's attack.
Little Snitch is commercial. If you want largely similar features (focused on egress), check out LuLu: https://github.com/objective-see/LuLu
https://objective-see.org/products/lulu.html
LittleSnitch
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."
IIUC the issue is, you could have a "secure" network and a guest network sharing an AP, and that guest network can access clients on the secure network. Someone did mention the xfinity automatic guest network, which might be a pain to disable?
This is likely not a big deal for your home network, if you only have one network, but for many enterprise setups probably much worse.
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.
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.
The Ars article mentions: “Even when HTTPS is in place, an attacker can still intercept domain look-up traffic and use DNS cache poisoning to corrupt tables stored by the target’s operating system.” Not sure, but I think this could then be further used for phishing.
Paper discussed in this article: https://www.ndss-symposium.org/ndss-paper/airsnitch-demystif...
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.
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.
A tad sensationalist perhaps, but "hot garbage" is a bit much.
Maybe I've just lost all patience for fluff, but I gave up trying to figure out what the attack was from the article pretty quickly where the abstract answered all my questions immediately.
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.)
That's an easy autocorrect issue. As someone who write Ubiquiti more often than most.
I don't even think most editors would know the difference. That's the problem with using corruptions of real words as your name.
I once suggested HN implement auto-correct because there are so many misspellings here. I was quickly downvoted.
I was indeed very surprised to see that it's from Dan Goodin
I only read his articles occasionally, but they always impressed me favorably; this one instead... the paper is probably clearer even for less technical people.
IMO spelling mistakes have always been a relatively weak indicator of writing quality, let alone truthiness.
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.