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.
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...
This is in contrast to more genetic, descriptive terms like "additional network", "separate network for guests", etc.
What we can do is that, when an adversary is connected to a co-located open network, or is a malicious insider, they can attack other clients. More technically, that we can bypass client isolation. We encountered one interesting case where the open Wi-Fi network of a university enabled us to intercept all traffic of co-located networks, including the private Enterprise SSID.
In this sense, the work doesn't break encryption. We bypass encryption.
If you don't rely on client/network isolation, you are safe. More importantly, if you have a router broadcasting a single SSID that only you use, we can't break it.
One of the main takeaway issues, in my view, is that it's just hard to correctly deploy client isolation in more complex networks. I think it can be done using modern hardware, but it's very tedious. We didn't test with VLAN separation, but using that can definitely help. Enterprise devices also require a high amount of expertise, meaning we might have missed some specialised settings.. So I'd recommend testing your Wi-Fi network, and then see which settings or routing configurations to change: https://github.com/vanhoefm/airsnitch
To clarify, the passphrase for each SSID is different, and the question is whether, first, an client that doesn't know any of the passphrases can somehow attack other clients who do, and second, whether a client that knows the passphrase for one SSID can attack clients connected to the other SSID (which has a different passphrase)?
First, they can't attack a WiFi access point for which they do not know any password(s). Thus your multi-SSID access point with multiple passwords is "safe" from this particular attack.
However, second, they can attack an access point for which they know any password, gaining access to clients on the other SSIDs. This means your security is now effectively only the security of your worst SSID's password. It also may defeat your purpose in having multiple SSIDs/passwords in the first place.
Inter-VLAN routing shouldn't be done at the wifi access point, packets would need to be tagged coming out of the wifi AP and switched upstream, unless I'm mistaken about this.
Thanks for your work on the topic! This is quite interesting!
For the university networks that we tested, I'd have to ask my co-author. But perhaps my other comment can further contextualize this: https://news.ycombinator.com/item?id=47172327 Summarized, I'm sure that it is possible to configure devices securely, and VLANs can play an important role in this. But doing so is more tedious and error-prone than one may initially assume, e.g., there is often no single setting to easily do so.
Not to minimize the recon value of the plaintext stuff. But not really fair to say you're 'bypassing' any encryption but for the WPA-specific kind.
- Buy cheap IOT device
- Isolate it on guest network
- IOT device is compromised (or shipped that way)
- IOT device now has clear access to traffic on both your guest and primary networks
Is that accurate?
Absolutely love your work, go strong. I click these thread and always expect your name to pop up
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.
I turn WiFi mine off and use my own WiFi ap.
Still an interesting attack though.
>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.
Quote (from movie): "just think, all this technology is already twenty years old..."
Much better than
The Conversation, but the links were uncanny (including Hackman's line: "yeah this has been my office where I do things for a long time*" — and it's the same set[up]).EotS honestly has the best death finale scene I've ever seen (not being hyperbolic, the best). Don't want to spoil it }:D ------>
Thank you for your recommendation - it be crazy up in here (head, country, world).
Great movie.
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.
Words like "I've been trying to use the Chromecast!" "The Living Room Chromecast?" "Yes! It says it's playing, but I don't see anything on the TV screen!" "You hit the play button, right?" "Yeah, and then it keeps stopping on its own!" "Are you sure you plugged it in?" "What in the world is wrong with this dumb thing?" drift between one partner and another in some other in some far corner of the hotel as they innocently trample my efforts to watch old episodes of How It's Made.
For all of these reasons, I tend to travel with a network that I control. That's usually in the form of some manner of very small router -- with a strong preference towards something that runs (or can run) OpenWRT. There's a ton of such "travel routers" in the market that are centered around $60 or so that don't take up much space at all.
I use this to slurp up whatever free wifi or ethernet I can get, or my phone tethering/hotspot, and I don't worry at all about how someone else's network might decide to treat me today. Whatever stuff I bring with me all works about as well as it does at home.
It's a real router with a stateful firewall, just like you use at home. Such devices protect you from the nefarious goings-on of the hotel wifi, just as they protect you from the nefarious goings-on of the big bad Internet on the other side of the cable modem at home.
A travel router differs only in that it is designed to be physically small.
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.
However client isolation should be a tool people have at their disposal. Consider the need for people to buy cloud IOT devices and throw them on a guest network (https://arstechnica.com/security/2024/09/massive-china-state...). It's also about keeping web-browsers away from these devices during regular use, because there are paths for malicious web pages to break into IOT devices.
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.
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!
- 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.
Is it grandma's fault that her ISP-issued router came with vulnerabilities exposing mammy's entire digital life?
On a massive scale, this is a huge security disclosure of the hardware -level.
—justbee
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.
My concern is doing it asynchronously against things when no one is watching.
Basically it takes turn being the client and the AP both so that it can get the traffic from both. It is an evil twin attack doubled.
It might have broken EAP TLS.
If your wifi is off when you are not using it and you are not getting denial of serviced while using it and you have only one Mac for your SSID, this attack is not occuring.
Some people also have passwords easy to break. Friend of mine literally had "hunter22" as WiFi password.
The problem is not wardrivers. The problem is your neighbors running 24x7 cyber operations. It happens everywhere. When I moved to a house there was a persistent attacker, and finally I setup my own key and authentication infrastructure.
They broke everything.
Finally I had to go EAP TLS and rotate certificates every three months.
Evil twin attack that keeps switching sides... The first of its kind, soon to be automated into a single button if it isn't already.
Does the temporal key mechanisms prevent them from taking a key they denial of serviced their way to while I was work -- do the temporal mechanisms prevent them from sniffing all my packets when I get home. They will not use it to get data during the denial of service.... But if they can get that radius key and use it five hours later during some backups or something...
That is the question.
You still have to be able to authenticate to some network: the spoofing only allows users who can access one network to MITM others, it doesn't allow somebody with no access to do anything.
In practice a lot of businesses have a guest network with a public password, so they're vulnerable. But very few home users do that.
I have been relying on EAP TLS via wifi so my phones could upload their photos and videos to Nextcloud.It was way cheaper than doing it via AWS, which is what I used to do and used ethernet LAN connections only. If this works asynchronously across time to allow authentication to my network which uses EAP TLS, will knock me out of being able to use Nexctloud on my mobile devices since plugging an ethernet in after I take photos is too cumbersome to do very often.
I love Nextcloud, but do not want to pay Amazon for EC2 etc.
My read is this allows them to mimic both client and access point to assemble the handshake and obtain radius authentication. Rather than have to verify a certificate on the client or crack complex passwords, they pretend to the client sending the response it sends when the certificate is verified. Then they switch MAC to the SSID MAC and send the next part to the client. Previous evil twin attacks were one sided rather than basic frame assemblers.
I read that paper as describing a successful reconstruction of the Radius authentication handshakes at layer 2 after the fact for use later rather than caring about actual certificate validations. Basically handing a three letter agency quality tool to the Kali Linux fan club.
I am hoping I read it wrong,
I would put that nextcloud instance on a private/vpn IP and not expose it. For the letsencrypt you can use DNS based approval. Cloudflare DNS is pretty easy to configure for example, they also support setting DNS records for private IPs which I understand is not standard. (If it's on a private IP you don't strictly need HTTPS anyway). Wireguard is ideal for this kind of thing and it works well on mobile as well.
If the above quoted piece is the entirety of your requirements there are a lot of other ways to solve the same issue. Tunnels, reverse proxies etc.
EDIT: Letsencrypt just recently add a new authentication method which uses a one time TXT entry into your DNS record.
> We verified that an attacker, having intercepted the first RADIUS packet sent from the enterprise AP, can brute-force the Message Authenticator and learn the AP passphrase.
I thought RADIUS fundamentally negotiates based on a PSK between the AP and the RADIUS box, which the attacker doesn't have? They're saying this gives you the ability to brute force that PSK, but if the PSK isn't weak (e.g. a dictionary word) that's hopeless.
I work on https://supernetworks.org/. We propose a solution to these flaws with per-device VLANs and encourage per-device passwords as well.
More practically the risk for these attacks is as follows. A simple password makes sense for easy setup on a guest network, that's treated as untrusted. These passwords can probably be cracked from sniffing a WPA2 key exchange -- who cares says the threat model, the network is untrusted. But this attack lets the insecure network pivot out into the secure one.
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!
Exactly.
I have some of those wifi APs that do not even provide any sort of isolation besides just implementing multiple SSID on the same wifi radio aka Guest SSID. No guarantee, no isolation.
"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 is likely not a big deal for your home network, if you only have one network, but for many enterprise setups probably much worse.
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.
Ironically one of the main pain points is Apple. keychain sync means all the apple devices on the same sync account should share a password for wireless. Secondly the MAC randomization timeouts require reassignment.
The trouble with SAE per device passwords is that the commit makes it difficult to evaluate more than one password per pairing without knowing the identity of a device (the MAC) a-priori, which is why it's harder to find this deployed in production. It's possible for an AP to cycle through a few attempts but not many, whereas in WPA2 an AP could rotate through all the passwords without a commit. The standard needs to adapt.
I was leaning towards using this configuration for splitting devices into VLANs while using one SSID. Yeah, dynamic VLAN+per device PSK would be best, but I'm probably happy enough with a shared PSK per VLAN to isolate a guest or IoT network. Would this VLAN isolation have prevented this attack? At least to prevent an attacker from jumping between VLANs? (I assume shared PSK per VLAN might be vulnerable to attacking client isolation within the VLAN?)
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.
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.
This also feels like an exfil route? Are DNS queries (no tcp connect) logged/blocked?
Has China become so prominent in security research?
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.
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.
"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.
WiFi provides half-way measures with client isolation features that break down when the packets hit L3, or in some cases the broadcast key implementations are deficient allowing L2 attacks. The paper is about all of the fun ways they could pivot across networks, and they figured out how to enable full bidirectional MITM in a wider class of attacks than commonly known or previously published.
It seems as if approved guest access now == system-wide access (at the hardware level). User compartmentalization no longer works.
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.
Are you being abused or something? This sounds ridiculous
It’s very difficult to have too much network security.
Summary: https://www.ndss-symposium.org/ndss-paper/airsnitch-demystif... (hat tip: https://news.ycombinator.com/item?id=47167975)
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.
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 don't even think most editors would know the difference. That's the problem with using corruptions of real words as your name.
We're talking about Ars Technica, not USA Today. Kinda like MotorTrend editors should know what a Z-rated tire is.
And I assume you've heard about the their AI fabrication scandal? - https://arstechnica.com/staff/2026/02/editors-note-retractio...
Not a great look, if Ars either doesn't know, or can't control what they're actually publishing.
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.
