undefined

[-]

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.

by nickburns1 hours ago|

[-]

Access points by their very definition are not capable of inter-VLAN routing.

[-]

That should definitely help. You still have to double-check the IP routing tables between the VLANs, but most of the time, that should prevent attacks between SSIDs.

by delBarrio3 hours ago|

[-]

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!

[-]

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

by blobbers2 hours ago|

[-]

I think you could apply specific CVEs to specific devices + setting combination, as:

CVE 1 : router brand X software version Y.Z configured with client isolation does not provide sufficient isolation that it cannot be broken with air snitch.

CVE 2 : router brand A software version B.C configured with client isolation does not provide sufficient isolation that it cannot be broken with air snitch.

etc.

by spockz2 hours ago|

[-]

CVE are handed out like candy in Java land for artifacts that have code that only opens up a vulnerability when another package is available and the first artifact is misconfigured. So I think you would be fully in your right to claim a CVE and list all affected versions of devices/firmwares there.

by nickburns4 hours ago|

[-]

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

by nickburns1 hours ago|

[-]

Disagree with your final statement. There's good security (and performance) reason to use any/all viable network isolation/segmentation/separation, etc., whenever/wherever possible. So-called Wi-Fi 'client isolation' is but a single network security strategy. No single strategy should be relied upon exclusively, nor avoided for that matter.

But it seems we otherwise agree on the overall impact of this vector. My point was mostly about the statement regarding any 'bypassing' of encryption.

by vanhoefm10 minutes ago|

[-]

It indeed seems we overall agree. Even if I may not have always explicitly said 'Wi-Fi encryption' for convenience, that can be derived from context normally, though it's always hard to estimate how people interpret text (and even harder to predict how others write about it :).

by blobbers3 hours ago|

[-]

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!

[-]

When testing our own Enterprise devices, VLANs were not used. This was done to understand the impact of client isolation on its own.

For the university networks that we tested, I'd have to ask my co-author. But perhaps my other comment can further contextualize this: https://news.ycombinator.com/item?id=47172327 Summarized, I'm sure that it is possible to configure devices securely, and VLANs can play an important role in this. But doing so is more tedious and error-prone than one may initially assume, e.g., there is often no single setting to easily do so.

by benlivengood36 minutes ago|