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

101–110 of 204 posts

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

#101

Post by eqvinox »

benlivengood wrote: post #55
tialaramex wrote: post #29

Earlier quoted context omitted.

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…

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.

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

#102

Post by runjake »

mrexcess wrote: post #14
runjake wrote: post #7

Earlier quoted context omitted.

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 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!

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

#103

Post by bombcar »

stebalien wrote: post #36
strongpigeon wrote: post #28

Earlier quoted context omitted.

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

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

#104

Post by wtallis »

economistbob wrote: post #79
supernetworks wrote: post #77

Earlier quoted context omitted.

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

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.

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

#105

Post by supernetworks »

eqvinox wrote: post #99
supernetworks wrote: post #86

Earlier quoted context omitted.

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

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.

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

#107

Post by russdill »

bronco21016 wrote: post #46
upboundspiral wrote: post #43

Earlier quoted context omitted.

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.

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

#108

Post by _bernd »

supernetworks wrote: post #100
_bernd wrote: post #90

Earlier quoted context omitted.

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?

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

#109

Post by drnick1 »

ProllyInfamous wrote: post #16

>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, m…

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.

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

#110

Post by kayson »

drnick1 wrote: post #109
ProllyInfamous wrote: post #16

>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, m…

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