Live data from Hacker News

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

ndss-symposium.org

131–140 of 204 posts

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

#131

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! In the case of accessing the private Enterprise SSID, was the network VLAN isolated or some other type of virtualization of the bssid?

Thanks for your work on the topic! This is quite interesting!

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

#132

Earlier quoted context omitted.

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 admittedly don't have practical experience with RADIUS, but I read it as a more narrow attack: > We verified that an attacker, having intercepted the first RADIUS packet sent from the enterprise AP, can brute-force the Message Authenticator and learn the AP passphrase. I thought RADIUS fundamentally negotiates based on a PSK between the AP and the RADIUS box, which the attacker doesn't have? They're saying this giv…

> I thought RADIUS fundamentally negotiates based on a PSK between the AP and the RADIUS box, which the attacker doesn't have?

Are you talking about the secret shared between the NAS and the RADIUS server? It's only used to scramble some attributes (like MS-MPPE-Send-Key), but not all of them. Message-Authenticator is one that's not scrambled. Looking at this FreeRADIUS dictionary file I have, I see 42 out of ~6000 attributes that are scrambled.

Anyway, yeah, if you have a bigass shared secret, it's going to be infeasible to guess. I'm pretty sure that the long-standing very, very strong suggestion for operators has been something like "If you don't co-locate your RADIUS server and your NAS, then you really need have a bigass shared secret, and probably want to be using something like IPSec to secure the connection between the two." [0][1]

[0] https://datatracker.ietf.org/doc/html/rfc3579#section-4.3.3>

[1] https://datatracker.ietf.org/doc/html/rfc3579#section-4.2>

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

#133

Earlier quoted context omitted.

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?

I would guess that the VLAN separation should prevent it, but perhaps there are implementation errors on the VLAN implementation inside of individual brands of routers?

Inter-VLAN routing shouldn't be done at the wifi access point, packets would need to be tagged coming out of the wifi AP and switched upstream, unless I'm mistaken about this.

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

#134

Earlier quoted context omitted.

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.

If the vulnerability is between layers 1 and 2, wouldn’t that imply that VLAN tagging at layer 2 might not be effective in segregating the traffic?

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

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

Is this still true if the guest network is on its own isolated vlan?

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

#136
post #120

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.

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

#137

Earlier quoted context omitted.

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…

Much of (if not the vast majority of the 'worthwhile') traffic you're intercepting is still encrypted packets though. Not to minimize the recon value of the plaintext stuff. But not really fair to say you're 'bypassing' any encryption but for the WPA-specific kind.

People who use or rely on client isolation want to prevent inter-client attacks, for whatever reason. We show that this can often be broken. This can be problematic when you have older hardware in your network that is rarely updated, and many then rely on client isolation to mitigate attacks. If everything is encrypted and properly patched, then our attack indeed has less impact, but then there also wouldn't have been a good reason to use client isolation in the first place ;)

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

#138

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.

Counterpoint: it is trivial to have too much network security - don’t provide power. It is difficult to have just enough network security.

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

#139

Earlier quoted context omitted.

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…

We don't have a CVE number. Whether devices/networks are affected also highly depends on the specific configuration of the device/network. This means that some might interpret some of the identified weaknesses as software flaws, but other weaknesses can also be seen as configuration issues. That's actually what makes some of our findings hard to 'fix': it's easy to say that someone else is responsible for properly ensuring client isolation :) Hence also hard to really assign CVE(s).

One of the main takeaway issues, in my view, is that it's just hard to correctly deploy client isolation in more complex networks. I think it can be done using modern hardware, but it's very tedious. We didn't test with VLAN separation, but using that can definitely help. Enterprise devices also require a high amount of expertise, meaning we might have missed some specialised settings.. So I'd recommend testing your Wi-Fi network, and then see which settings or routing configurations to change: https://github.com/vanhoefm/airsnitch

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

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

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.

Post reply on HN