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

121–130 of 204 posts

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

#121

Post by NetMageSCW »

strongpigeon wrote: post #24
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…

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.

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

#122

Post by bburky »

supernetworks wrote: post #94
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 reas…

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

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

#123

Post by NetMageSCW »

vanhoefm wrote: post #112
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…

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

Do separate VLANs behind the different SSIDs provide protection?

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

#124

Post by dizhn »

JKCalhoun wrote: post #31
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…

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)

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

#125

Post by simoncion »

wtallis wrote: post #104
economistbob wrote: post #79

Earlier quoted context omitted.

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

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

#126

Post by Gigachad »

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…

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.

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

#127

Post by dizhn »

economistbob wrote: post #69
jcalvinowens wrote: post #59

Earlier quoted context omitted.

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

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

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

#128

Post by delBarrio »

vanhoefm wrote: post #112
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…

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

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!

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

#130

Post by eqvinox »

Gigachad wrote: post #126
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…

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