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

91–100 of 204 posts

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

#91

Post by supernetworks »

mlhpdx wrote: post #71

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.

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

#92

Post by tmp10423288442 »

ProllyInfamous wrote: post #34
john_strinlai wrote: post #20

Earlier quoted context omitted.

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

You have a modem that you can attach to those switches? They’re completely unauthenticated?

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

#93

Post by ProllyInfamous »

jeffbee wrote: post #30
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.

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

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

#94

Post by supernetworks »

zekica wrote: post #18

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.

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

#95

Post by gh02t »

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.

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.

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

#96

Post by ProllyInfamous »

tmp10423288442 wrote: post #92
ProllyInfamous wrote: post #34

Earlier quoted context omitted.

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

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

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

#97

Post by rsync »

jasomill wrote: post #56
ProllyInfamous wrote: post #41

Earlier quoted context omitted.

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

… also starring Harrison ford…

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

#99

Post by eqvinox »

supernetworks wrote: post #86
eqvinox wrote: post #32

Earlier quoted context omitted.

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…

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

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

#100

Post by supernetworks »

_bernd wrote: post #90
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.

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