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.
802.11 is kinda poorly designed in this regard, but they do isolate to some degree. I need to read the paper, some claims here have a very strong "misunderstood or wrong or specific vendor problem" smell.
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.
It looks like both clients must be on the same VLAN for the attack to work. They could be connected on different BSSIDs or even different SSIDs, but they still must be on the same VLAN.
I'm a co-author on the paper: I would personally indeed not use the phrase "we can break Wi-Fi encryption", because that might be misinterpreated that we can break any Wi-Fi network.
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.
Hi and thanks so much for the valuable research!! I know it has been asked a lot here already, and probably some in-deep reading would help figure that out by myself. But I’ve noticed that you used Cisco 9130 APs, and noticed only part of the attack work on those. So wanted to ask whether you tested those with just IP based network separation, or also the VLAN-based one? Also, since you’ve mentioned the findings have been communicated to the vendors and the WiFi alliance alike, may I ask you to maybe share a CVE number here? I (as probably a lot of us here), use some of the hardware mentioned for personal goals/hobby in my home setup, and find it fun to keep that setup reasonably protected for the sake (fun) of it. Much appreciated!
We don't have a CVE number. Whether devices/networks are affected also highly depends on the specific configuration of the device/network. This means that some might interpret some of the identified weaknesses as software flaws, but other weaknesses can also be seen as configuration issues. That's actually what makes some of our findings hard to 'fix': it's easy to say that someone else is responsible for properly ensuring client isolation :) Hence also hard to really assign CVE(s).
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
That should definitely help. You still have to double-check the IP routing tables between the VLANs, but most of the time, that should prevent attacks between SSIDs.
I would guess that the VLAN separation should prevent it, but perhaps there are implementation errors on the VLAN implementation inside of individual brands of routers?
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.
People who use or rely on client isolation want to prevent inter-client attacks, for whatever reason. We show that this can often be broken. This can be problematic when you have older hardware in your network that is rarely updated, and many then rely on client isolation to mitigate attacks. If everything is encrypted and properly patched, then our attack indeed has less impact, but then there also wouldn't have been a good reason to use client isolation in the first place ;)
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.
I think that places that rely on client isolation might be the general case - every public space that has a guest network - e.g. retail stores, doctor’s offices, hotels, hospitals - is probably using client isolation on their wireless network.
Access points frequently have multiple BSSIDs even if just for broadcasting on 2.4 and 5 at the same time. Any multiple AP scenario will have them regardless. Couple that with weak duplicate MAC checking and shared GTK (WPA2-PSK) and the attack becomes trivial. I imagine old hardware will be broken forever. Especially pre 802.11w.
>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.
It is hard to disagree with this approach. While I still use WiFi, it is a separate subnet and only whitelisted MACs are allowed to use it. Cameras and microphones are always unplugged when not in use, and my phone runs GrapheneOS. I also removed the hands-free microphone in my car, as well as the cellular modem.
Any decent sniffer (e.g. airsnort) can immediately identify all associations between all WiFi/Bluetooth devices. DD-WRT (router firmware/OS) has this WiFi-associations detector built-in ("local WiFi map"). There is no need to attempt any sort of hack — associations are publicly-broadcast information.
Then, just pick any authorized MAC and duplicate as your own.
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).
Directed by Francis Ford Coppola, Palme d'Or at Cannes, three Oscar nominations including Best Picture (which, amusingly, it lost to The Godfather Part II).
In all fairness, Part II is absolutely incredible storytelling.
Are you suggesting The Conversation is even better?! So excited for tonight's showtime — I'll make an updated reply here, tomorrow morning (with my viewreport).
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.
That seems less annoying than a hotel full of people who can play whatever they want with my Chromecast.
No malice is required for this to happen; it is completely possible to do by mistake.
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.
Even when not using client isolation, I've run into similar problems simply from having a computer connected over Ethernet instead of WiFi, and whatever broadcast method a gadget uses for discovery didn't get bridged between wired and wireless. (Side note: broadcast traffic on WiFi can be disproportionately problematic because it needs to be transmitted at a lowest common denominator speed to ensure all clients can receive it. IIRC, that usually means 6Mbps.)
I mean, yeah, isn't that the main purpose of client isolation? It sucks when you're on something like a locked down university dormitory network but it also stops (or at least, inhibits) other people from randomly turning on your lightbulb or worse, deploying exploits on your poorly engineered IoT device and lighting you up with malware.
Adding exceptions for certain protocols, IP ranges (maybe multicast, even) are certainly ways around this, but I imagine with every hole you poke to allow something, you are also opening a hole for data to leak.
Client isolation is done at L2. You can't add exceptions for IP ranges / protocols / etc this way because that's up the stack. Even if devices can learn about each other in other ways, isolation gets in the way of direct communication between them.
The paper makes the point that you need to consider L3 in client isolation too - they call this the gateway bouncing attack. If you can hairpin traffic for clients at L3, it doesn't matter what preventions you have at L2
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 client+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.
This is mostly accurate, to clarify the association IDs tie into what VLANs will be assigned and that does block all of the injection/MITM attacks. This also assumes that the VLAN segments are truly isolated from one another, as in they do not route traffic between each other by default including for broadcast and multicast traffic.
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.
What exactly a VLAN is (or rather, properly: broadcast domain) gets kinda fuzzy in enterprise controller based wifi setups… and client isolation isn't really different from what some switches sell as "Private VLAN" (but terminology is extremely ambiguous and overloaded in this area, that term can mean entirely different things across vendors or even products lines).
What exact security guarantees you get really depends on the sum total of the setup, especially if the wireless controller isn't also the IP router, or you do local exit (as opposed to haul-all-to-controller).
Yep, unfortunately fuzzy. For enterprise wifi deployments, one amusing thing to do when configuring 802.1X is to test ARP spoofing the upstream radius server after associating, and self-authenticate.
It might be interesting to go and apply some of the sneaky packet injection mechanisms in this paper actually to try to bypass ARP spoofing defenses.
What can you even do on the local network these days? Most everything is encrypted before it leaves the device. I guess you could cast stuff to the TV.
Probably more of a problem if combined with other exploitable issues in other devices. Like if your TV doesn't properly check signatures on its firmware upgrades…
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!
As a funny personal anecdote, my brother is a state judge. His most personal thoughts & correspondances are crafted upon typewriters (mine as well). He isn't officially allowed to just use any phone/computer/network. He is a "high value target" [0],
My personal attorney still doesn't use "the cloud" for client documents (which is respectable) — has local servers, mostly offline. No typewriter, though =P
----
I'm just an electrician.
[0] Does it bother anybody else that Pam Bondi has reports specifically of which documents each congressman reviewed (photographed by AP, during recent testimony)?
In addition to equvinox (hey again):
In enterprise networks you should rely on 802.1x or what's also valid use case is the use of ipsec to ensure the local client connection is "safe".
Some 802.1x have inherent mitm attacks that have been called out since 2004 and never got the v2 (https://www.rfc-editor.org/rfc/rfc6677.html). EAP-TLS however is the best practice here + VLANs.
I'm a co-author on the paper: I would personally not use the word break but instead bypass, to indeed clarify we can't just 'break' any network. We specifically target client isolation, which is nowadays often used, and that proved possible to bypass. If you don't rely on client/network isolation, you are safe.
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.
EAP TLS provides strong authentication, is much better than the other enterprise authentication options, but will not block these lateral attacks from other authenticated devices. The second half of the deployment is putting each identity into a VLAN to defend against the L2/L3 disconnects that can occur.
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.
More precisely: the manufacturer's software on your consumer grade routers refuses to expose that functionality to the end user. They're almost always relying on VLANs behind the scenes to separate the WAN and LAN ports.
> They're almost always relying on VLANs behind the scenes to separate the WAN and LAN ports.
I don't believe this is true. I expect that what's going on there is the WAN and LAN ports on the switch [0] are in separate bridges.
Why do you believe that they're using VLANs behind the scenes? It seems silly to add and remove a whole-ass VLAN tag to traffic based on what port it comes in on. Do you have switch chip or other relevant documentation that indicates that this is what's going on?
[0] or WAN and LAN interfaces, if the ports are actually separate, entirely-independent interfaces, rather than bound up in a switch
It requires disassociating and reassociating to the MAC so it requires two, which would cause a denial of service one would notice while watching it. Whether they can denial of service their way to the key, while someone is not actively watching, was not addressed. The paper is about essentially getting data from clients when there are two MACs. They glossed over the one MAC situation by saying someone would notice it so it was not useful.
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.
I had organized neighbors who broke WPA3 using tools, i disabled downgrade to WPA2 and they still broke it. I had one that setup an evil twin to catch my Linux login They stole the IP of one of boxes so they could get my login, and joined my network to setup the credential stealer. I caught this when my password didn't work at the ssh login. That was an apartment and they knew when I caught them.
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...
> Essentially everyone with the SSID on multiple access point MAC addresses can get pwned
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 run a website, video game servers, and Nextcloud. I have the nextcloud set to only allow access from my IP. It has to be open to the world with a domain name so I can use LetsEncrypt certs so it cannot only use private ip addresses which cannot be easily configured and trusted for https.
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 have the nextcloud set to only allow access from my IP. It has to be open to the world with a domain name so I can use LetsEncrypt certs so it cannot only use private ip addresses which cannot be easily configured and trusted for https.
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.
I admittedly don't have practical experience with RADIUS, but I read it as a more narrow attack:
> 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 thought RADIUS fundamentally negotiates based on a PSK between the AP and the RADIUS box, which the attacker doesn't have?
Are you talking about the secret shared between the NAS and the RADIUS server? It's only used to scramble some attributes (like MS-MPPE-Send-Key), but not all of them. Message-Authenticator is one that's not scrambled. Looking at this FreeRADIUS dictionary file I have, I see 42 out of ~6000 attributes that are scrambled.
Anyway, yeah, if you have a bigass shared secret, it's going to be infeasible to guess. I'm pretty sure that the long-standing very, very strong suggestion for operators has been something like "If you don't co-locate your RADIUS server and your NAS, then you really need have a bigass shared secret, and probably want to be using something like IPSec to secure the connection between the two." [0][1]
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!
Yes, if they host the guest network on the same hardware, same transmission path etc. Network "hygiene" will obviously differ from one place to the other.
"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.
Hostapd now has support for multi pass SAE /WPA3 password as well. We have an implementation of dynamic VLAN+per device PSK with WPA3 (https://github.com/spr-networks/super) we've been using for a few years now.
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?)
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.
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.
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?
This attack exploits multi PSK networks precisely. If it's all one PSK the attacker can already throw up a rogue AP for WPA3 or just sniff/inject WPA2 outright. The back half of a secure multi PSK setup is deploying VLANs for segmentation, to block these attacks.
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.
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.
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.
Just like it isn’t normal to buy one UPS per server, it is sensible to have one more capable firewall for all your servers, even if it does put you in a M&M situation.
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.
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.
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.
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?
802.11 is kinda poorly designed in this regard, but they do isolate to some degree. I need to read the paper, some claims here have a very strong "misunderstood or wrong or specific vendor problem" smell.
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.
It looks like both clients must be on the same VLAN for the attack to work. They could be connected on different BSSIDs or even different SSIDs, but they still must be on the same VLAN.
If the vulnerability is between layers 1 and 2, wouldn’t that imply that VLAN tagging at layer 2 might not be effective in segregating the traffic?
This is probably the biggest issue.
I turn WiFi mine off and use my own WiFi ap.
Yeah, along these lines I've always been biased strongly against using ISP hardware beyond the minimum required to connect to the outside world.
See also: Amazon's Sidewalk (which shares your network via Ring camerae, e.g.).
I'm a co-author on the paper: I would personally indeed not use the phrase "we can break Wi-Fi encryption", because that might be misinterpreated that we can break any Wi-Fi network.
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.
Hi and thanks so much for the valuable research!! I know it has been asked a lot here already, and probably some in-deep reading would help figure that out by myself. But I’ve noticed that you used Cisco 9130 APs, and noticed only part of the attack work on those. So wanted to ask whether you tested those with just IP based network separation, or also the VLAN-based one? Also, since you’ve mentioned the findings have been communicated to the vendors and the WiFi alliance alike, may I ask you to maybe share a CVE number here? I (as probably a lot of us here), use some of the hardware mentioned for personal goals/hobby in my home setup, and find it fun to keep that setup reasonably protected for the sake (fun) of it. Much appreciated!
We don't have a CVE number. Whether devices/networks are affected also highly depends on the specific configuration of the device/network. This means that some might interpret some of the identified weaknesses as software flaws, but other weaknesses can also be seen as configuration issues. That's actually what makes some of our findings hard to 'fix': it's easy to say that someone else is responsible for properly ensuring client isolation :) Hence also hard to really assign CVE(s).
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
Do separate VLANs behind the different SSIDs provide protection?
That should definitely help. You still have to double-check the IP routing tables between the VLANs, but most of the time, that should prevent attacks between SSIDs.
I would guess that the VLAN separation should prevent it, but perhaps there are implementation errors on the VLAN implementation inside of individual brands of routers?
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.
Hi! In the case of accessing the private Enterprise SSID, was the network VLAN isolated or some other type of virtualization of the bssid?
Thanks for your work on the topic! This is quite interesting!
Much of (if not the vast majority of the 'worthwhile') traffic you're intercepting is still encrypted packets though.
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.
People who use or rely on client isolation want to prevent inter-client attacks, for whatever reason. We show that this can often be broken. This can be problematic when you have older hardware in your network that is rarely updated, and many then rely on client isolation to mitigate attacks. If everything is encrypted and properly patched, then our attack indeed has less impact, but then there also wouldn't have been a good reason to use client isolation in the first place ;)
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.
I think that places that rely on client isolation might be the general case - every public space that has a guest network - e.g. retail stores, doctor’s offices, hotels, hospitals - is probably using client isolation on their wireless network.
Access points frequently have multiple BSSIDs even if just for broadcasting on 2.4 and 5 at the same time. Any multiple AP scenario will have them regardless. Couple that with weak duplicate MAC checking and shared GTK (WPA2-PSK) and the attack becomes trivial. I imagine old hardware will be broken forever. Especially pre 802.11w.
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.
It is hard to disagree with this approach. While I still use WiFi, it is a separate subnet and only whitelisted MACs are allowed to use it. Cameras and microphones are always unplugged when not in use, and my phone runs GrapheneOS. I also removed the hands-free microphone in my car, as well as the cellular modem.
Is MAC whitelisting anything but security theater? Isn't it trivial to determine a valid client MAC then spoof it?
What makes you say that? It does not seem trivial at all to guess a valid MAC.
It's not just a guess.
Any decent sniffer (e.g. airsnort) can immediately identify all associations between all WiFi/Bluetooth devices. DD-WRT (router firmware/OS) has this WiFi-associations detector built-in ("local WiFi map"). There is no need to attempt any sort of hack — associations are publicly-broadcast information.
Then, just pick any authorized MAC and duplicate as your own.
The MAC addresses of all the Wi-Fi clients are broadcasted in plain radio format all over the 2.4GHz. It is trivial.
It's in managmenet frames that you can sniff.
You would like the film The Conversation (1974).
Enemy of the State is a pretty good light weight successor of that movie as well. It's such a fun watch too. (RIP Gene Hackman)
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).
One fan theory is that Gene Hackman plays the same character, decades later, in Enemy of the State (1998).
I'll have to rewatch EofState, after tonights Conversation.
Fan theories are the only way I ever finished DFWallace's trifecta (2000 pages of gruelling chaos). Thank god for fans.
Directed by Francis Ford Coppola, Palme d'Or at Cannes, three Oscar nominations including Best Picture (which, amusingly, it lost to The Godfather Part II).
Great movie.
In all fairness, Part II is absolutely incredible storytelling.
Are you suggesting The Conversation is even better?! So excited for tonight's showtime — I'll make an updated reply here, tomorrow morning (with my viewreport).
I think they were simply musing as to how one Coppola film lost to another.
… also starring Harrison ford…
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.
That seems less annoying than a hotel full of people who can play whatever they want with my Chromecast. No malice is required for this to happen; it is completely possible to do by mistake.
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.
Even when not using client isolation, I've run into similar problems simply from having a computer connected over Ethernet instead of WiFi, and whatever broadcast method a gadget uses for discovery didn't get bridged between wired and wireless. (Side note: broadcast traffic on WiFi can be disproportionately problematic because it needs to be transmitted at a lowest common denominator speed to ensure all clients can receive it. IIRC, that usually means 6Mbps.)
I mean, yeah, isn't that the main purpose of client isolation? It sucks when you're on something like a locked down university dormitory network but it also stops (or at least, inhibits) other people from randomly turning on your lightbulb or worse, deploying exploits on your poorly engineered IoT device and lighting you up with malware.
Adding exceptions for certain protocols, IP ranges (maybe multicast, even) are certainly ways around this, but I imagine with every hole you poke to allow something, you are also opening a hole for data to leak.
Client isolation is done at L2. You can't add exceptions for IP ranges / protocols / etc this way because that's up the stack. Even if devices can learn about each other in other ways, isolation gets in the way of direct communication between them.
The paper makes the point that you need to consider L3 in client isolation too - they call this the gateway bouncing attack. If you can hairpin traffic for clients at L3, it doesn't matter what preventions you have at L2
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 client+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.
This is mostly accurate, to clarify the association IDs tie into what VLANs will be assigned and that does block all of the injection/MITM attacks. This also assumes that the VLAN segments are truly isolated from one another, as in they do not route traffic between each other by default including for broadcast and multicast traffic.
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.
What exactly a VLAN is (or rather, properly: broadcast domain) gets kinda fuzzy in enterprise controller based wifi setups… and client isolation isn't really different from what some switches sell as "Private VLAN" (but terminology is extremely ambiguous and overloaded in this area, that term can mean entirely different things across vendors or even products lines).
What exact security guarantees you get really depends on the sum total of the setup, especially if the wireless controller isn't also the IP router, or you do local exit (as opposed to haul-all-to-controller).
Yep, unfortunately fuzzy. For enterprise wifi deployments, one amusing thing to do when configuring 802.1X is to test ARP spoofing the upstream radius server after associating, and self-authenticate.
It might be interesting to go and apply some of the sneaky packet injection mechanisms in this paper actually to try to bypass ARP spoofing defenses.
What can you even do on the local network these days? Most everything is encrypted before it leaves the device. I guess you could cast stuff to the TV.
Probably more of a problem if combined with other exploitable issues in other devices. Like if your TV doesn't properly check signatures on its firmware upgrades…
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!
You have a modem that you can attach to those switches? They’re completely unauthenticated?
Both, yes. Physical hardware isolation.
----
As a funny personal anecdote, my brother is a state judge. His most personal thoughts & correspondances are crafted upon typewriters (mine as well). He isn't officially allowed to just use any phone/computer/network. He is a "high value target" [0],
My personal attorney still doesn't use "the cloud" for client documents (which is respectable) — has local servers, mostly offline. No typewriter, though =P
----
I'm just an electrician.
[0] Does it bother anybody else that Pam Bondi has reports specifically of which documents each congressman reviewed (photographed by AP, during recent testimony)?
In addition to equvinox (hey again): In enterprise networks you should rely on 802.1x or what's also valid use case is the use of ipsec to ensure the local client connection is "safe".
Some 802.1x have inherent mitm attacks that have been called out since 2004 and never got the v2 (https://www.rfc-editor.org/rfc/rfc6677.html). EAP-TLS however is the best practice here + VLANs.
What do you think about to just use open networks and the use of IPsec/wireguard?
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.
This is effectively victim blaming. Most of us are just users. Even corporate users (relying upon other contractors' default configurations).
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
I'm a co-author on the paper: I would personally not use the word break but instead bypass, to indeed clarify we can't just 'break' any network. We specifically target client isolation, which is nowadays often used, and that proved possible to bypass. If you don't rely on client/network isolation, you are safe.
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.
EAP TLS provides strong authentication, is much better than the other enterprise authentication options, but will not block these lateral attacks from other authenticated devices. The second half of the deployment is putting each identity into a VLAN to defend against the L2/L3 disconnects that can occur.
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.
My consumer grade routers cannot handle all that fancy VLAN stuff. Thanks for mentioning that.
More precisely: the manufacturer's software on your consumer grade routers refuses to expose that functionality to the end user. They're almost always relying on VLANs behind the scenes to separate the WAN and LAN ports.
> They're almost always relying on VLANs behind the scenes to separate the WAN and LAN ports.
I don't believe this is true. I expect that what's going on there is the WAN and LAN ports on the switch [0] are in separate bridges.
Why do you believe that they're using VLANs behind the scenes? It seems silly to add and remove a whole-ass VLAN tag to traffic based on what port it comes in on. Do you have switch chip or other relevant documentation that indicates that this is what's going on?
[0] or WAN and LAN interfaces, if the ports are actually separate, entirely-independent interfaces, rather than bound up in a switch
They still need to be able to connect to one of the network no? So a home network without guest would be fine is my understanding?
It requires disassociating and reassociating to the MAC so it requires two, which would cause a denial of service one would notice while watching it. Whether they can denial of service their way to the key, while someone is not actively watching, was not addressed. The paper is about essentially getting data from clients when there are two MACs. They glossed over the one MAC situation by saying someone would notice it so it was not useful.
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.
Social vector? Come up with some tradesperson spiel if person invites home, ask for wifi password, you are in.
Some people also have passwords easy to break. Friend of mine literally had "hunter22" as WiFi password.
I had organized neighbors who broke WPA3 using tools, i disabled downgrade to WPA2 and they still broke it. I had one that setup an evil twin to catch my Linux login They stole the IP of one of boxes so they could get my login, and joined my network to setup the credential stealer. I caught this when my password didn't work at the ssh login. That was an apartment and they knew when I caught them.
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.
> Essentially everyone with the SSID on multiple access point MAC addresses can get pwned
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 run a website, video game servers, and Nextcloud. I have the nextcloud set to only allow access from my IP. It has to be open to the world with a domain name so I can use LetsEncrypt certs so it cannot only use private ip addresses which cannot be easily configured and trusted for https.
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 have the nextcloud set to only allow access from my IP. It has to be open to the world with a domain name so I can use LetsEncrypt certs so it cannot only use private ip addresses which cannot be easily configured and trusted for https.
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.
I admittedly don't have practical experience with RADIUS, but I read it as a more narrow attack:
> 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 thought RADIUS fundamentally negotiates based on a PSK between the AP and the RADIUS box, which the attacker doesn't have?
Are you talking about the secret shared between the NAS and the RADIUS server? It's only used to scramble some attributes (like MS-MPPE-Send-Key), but not all of them. Message-Authenticator is one that's not scrambled. Looking at this FreeRADIUS dictionary file I have, I see 42 out of ~6000 attributes that are scrambled.
Anyway, yeah, if you have a bigass shared secret, it's going to be infeasible to guess. I'm pretty sure that the long-standing very, very strong suggestion for operators has been something like "If you don't co-locate your RADIUS server and your NAS, then you really need have a bigass shared secret, and probably want to be using something like IPSec to secure the connection between the two." [0][1]
[0] <https://datatracker.ietf.org/doc/html/rfc3579#section-4.3.3>
[1] <https://datatracker.ietf.org/doc/html/rfc3579#section-4.2>
It is common for ISPs to issue network equipment that enable a guest network by default. I wonder if those are vulnerable.
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!
Like as in me being on the Guest network at a business can then read traffic of the Corporate network?
Yes, if they host the guest network on the same hardware, same transmission path etc. Network "hygiene" will obviously differ from one place to the other.
> Like as in me being on the Guest network at a business can then read traffic of the Corporate network?
Exactly.
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.
Paper discussed in this article: https://www.ndss-symposium.org/ndss-paper/airsnitch-demystif...
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.
Hostapd now has support for multi pass SAE /WPA3 password as well. We have an implementation of dynamic VLAN+per device PSK with WPA3 (https://github.com/spr-networks/super) we've been using for a few years now.
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.
Is that the same feature as vlanid= in openwrt's wpa_psk_file? https://openwrt.org/docs/guide-user/network/wifi/basic#wpa_p...
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?)
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
+1 Thanks, I forgot about LuLu!
https://objective-see.org/products/lulu.html
LittleSnitch
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.
DNSSEC prevents that if set up properly.
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.
Only WPA2/3-Enterprise networks which offer no guest network access.
I'd like to see more enterprise-grade equipment tested.
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?
This attack exploits multi PSK networks precisely. If it's all one PSK the attacker can already throw up a rogue AP for WPA3 or just sniff/inject WPA2 outright. The back half of a secure multi PSK setup is deploying VLANs for segmentation, to block these attacks.
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.
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.
They've updated the link to the paper, and the summary there is much clearer (but wouldn't drive clicks, obviously).
The attacker needs to be connected to a wireless network if I understood this correctly?
For all users reading this on their own home network: DISABLE ALL GUEST NETWORKS
It seems as if approved guest access now == system-wide access (at the hardware level). User compartmentalization no longer works.
Is this still true if the guest network is on its own isolated vlan?
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.
Just like it isn’t normal to buy one UPS per server, it is sensible to have one more capable firewall for all your servers, even if it does put you in a M&M situation.
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.
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.
Counterpoint: it is trivial to have too much network security - don’t provide power. It is difficult to have just enough 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.)
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.
IMO spelling mistakes have always been a relatively weak indicator of writing quality, let alone truthiness.
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.
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)
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
Updated, thanks!
@dang, can we get the link and title changed?
@dang doesn't do anything; email hn@ycombinator.com and they'll do something quite responsively.