Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AirSnitch: Demystifying and breaking client isolation in Wi-Fi networks [pdf]

ndss-symposium.org

Post reply on HN
Print view View original

81–90 of 204 posts

Re: AirSnitch: Demystifying and breaking client isolation in Wi-Fi networks [pdf]

#81

Post by wtallis »

jwr wrote: post #76

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.

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.)

Re: AirSnitch: Demystifying and breaking client isolation in Wi-Fi networks [pdf]

#82

Post by blobbers »

If you're a panicking IT guy, from the original paper:

"WPA2/3-Enterprise. These attacks generally do not work against WPA2/3-Enterprise networks..."

So this is a protocol attack, not an encryption attack. If you're using proper encryption per client, there is no attack available.

Re: AirSnitch: Demystifying and breaking client isolation in Wi-Fi networks [pdf]

#83

Post by ProllyInfamous »

ErneX wrote: post #60

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.

Re: AirSnitch: Demystifying and breaking client isolation in Wi-Fi networks [pdf]

#84

Post by ProllyInfamous »

blobbers wrote: post #82

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.

Re: AirSnitch: Demystifying and breaking client isolation in Wi-Fi networks [pdf]

#85

Post by JKCalhoun »

ProllyInfamous wrote: post #73
jasomill wrote: post #56

Earlier quoted context omitted.

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.

Re: AirSnitch: Demystifying and breaking client isolation in Wi-Fi networks [pdf]

#86

Post by supernetworks »

eqvinox wrote: post #32
iamnothere wrote: post #12

Earlier quoted context omitted.

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 sco…

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.

Re: AirSnitch: Demystifying and breaking client isolation in Wi-Fi networks [pdf]

#87

Post by oasisbob »

c0nsumer wrote: post #80
Chihuahua0633 wrote: post #78

Earlier quoted context omitted.

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

Re: AirSnitch: Demystifying and breaking client isolation in Wi-Fi networks [pdf]

#88

Post by ectospheno »

benlivengood wrote: post #13

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 som…

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.

Re: AirSnitch: Demystifying and breaking client isolation in Wi-Fi networks [pdf]

#89

Post by StilesCrisis »

economistbob wrote: post #75
varispeed wrote: post #68

Earlier quoted context omitted.

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 w…

Is it possible that you have undiagnosed schizophrenia?

Re: AirSnitch: Demystifying and breaking client isolation in Wi-Fi networks [pdf]

#90

Post by _bernd »

iamnothere wrote: post #12
sippeangelo wrote: post #9

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.

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".
Post reply on HN