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'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.
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.
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.
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.
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.
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.)
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.
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.
> 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.
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.
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, though do all of these wifi devices actually have a formal assurance (as in written specification) of network L2/L3 isolation between virtual APs?
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."
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.
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.
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.
China has surpassed the USA in almost every metric except freedom (so far). They already do, or are close to doing, the most and best research in every field, producing the best and cheapest of every product category, and providing the best living standards for their Han Chinese citizens. Europe has a huge amount of catching up to do, and the US is basically a lost cause.
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.
Very encouraging to see they are testing the open source projects like OpenWrt. Too often these types of tests target the most popular off-the-shelf products, "enterprise" products, and obscure knock-off products.
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.
Just being able to inject traffic is already huge as it allow you to send IPv6 router advertisement, which sometimes allows you to change the DNS config
Other members of my household frequently invite people to my own place that have malicious intent against me. They don't like me for reasons like not being a fan of Trump, Drake, or N3on. Unfortunately, this is a risk that many people other than me have to face. This is an eye-opening article as I do provide my guest password to them.
I plan on disabling the guest network entirely and utilizing a completely different router for the guest network. As the paper states, an isolated guest network isn't standardized. I plan on revisiting my network security once it is.
Once again I feel justified in hard wiring all connections. I do have a wireless network for a couple of portable devices, but everything else has a plug and a VLAN.
It’s very difficult to have too much network security.
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.
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.
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.
benlivengood|4 days ago
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.
tialaramex|4 days ago
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...
vanhoefm|4 days ago
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.
upboundspiral|4 days ago
strongpigeon|4 days ago
Still an interesting attack though.
ectospheno|4 days ago
wat10000|4 days ago
ProllyInfamous|4 days ago
>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.
JKCalhoun|4 days ago
drnick1|4 days ago
jwr|4 days ago
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.
ssl-3|4 days ago
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.
gh02t|4 days ago
wtallis|4 days ago
Chihuahua0633|4 days ago
sippeangelo|4 days ago
iamnothere|4 days ago
vanhoefm|4 days ago
economistbob|4 days ago
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.
Sytten|4 days ago
jcalvinowens|4 days ago
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.
supernetworks|4 days ago
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.
jcalvinowens|4 days ago
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!
Waterluvian|4 days ago
winstonwinston|4 days ago
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.
jeroenhd|4 days ago
ProllyInfamous|4 days ago
vxxzy|4 days ago
"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."
nixpulvis|4 days ago
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.
zekica|4 days ago
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.
supernetworks|4 days ago
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.
madjam002|4 days ago
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.
runjake|4 days ago
https://obdev.at/products/littlesnitch/index.html
roflchoppa|4 days ago
tiger3|4 days ago
api|4 days ago
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.
NetMageSCW|4 days ago
g-b-r|4 days ago
Has China become so prominent in security research?
direwolf20|3 days ago
this-is-why|4 days ago
amiljkovic|4 days ago
kevincloudsec|4 days ago
paulnpace|3 days ago
aspenmayer|4 days ago
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.
blobbers|4 days ago
"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.
ProllyInfamous|4 days ago
mlhpdx|4 days ago
supernetworks|4 days ago
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.
champtar|4 days ago
ErneX|4 days ago
ProllyInfamous|4 days ago
It seems as if approved guest access now == system-wide access (at the hardware level). User compartmentalization no longer works.
sgalbincea|4 days ago
kittikitti|4 days ago
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.
andsoitis|3 days ago
Are you being abused or something? This sounds ridiculous
fabioyy|4 days ago
iamnothere|4 days ago
It’s very difficult to have too much network security.
NetMageSCW|4 days ago
unknown|4 days ago
[deleted]
cs702|4 days ago
Summary: https://www.ndss-symposium.org/ndss-paper/airsnitch-demystif... (hat tip: https://news.ycombinator.com/item?id=47167975)
andrewstuart2|4 days ago
tomhow|4 days ago
JumpCrisscross|4 days ago
fdefitte|3 days ago
[deleted]
genie3io|3 days ago
[deleted]
stebalien|4 days ago
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.
strongpigeon|4 days ago
bell-cot|4 days ago
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.)
John23832|4 days ago
I don't even think most editors would know the difference. That's the problem with using corruptions of real words as your name.
pinkmuffinere|4 days ago
g-b-r|4 days ago
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.