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 described to start getting packets meant for that Eduroam user.
If you only have a single appropriately authenticated WiFi network then the loss of isolation doesn't matter, in the same way that a Sandbox escape in your web browser doesn't matter if you only visit a single trusted web site...
This is in contrast to more genetic, descriptive terms like "additional network", "separate network for guests", etc.
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 where the open Wi-Fi network of a university enabled us to intercept all traffic of co-located networks, including the private Enterprise SSID.
In this sense, the work doesn't break encryption. We bypass encryption.
If you don't rely on client/network isolation, you are safe. More importantly, if you have a router broadcasting a single SSID that only you use, we can't break it.
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.
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
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.
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.
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.
Thanks for your work on the topic! This is quite interesting!
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.
The real solution is zero-trust network access which gets closer to reality with passkeys; the last mile will be internal (LAN) devices that need a way to provision trusted identities (Bluetooth proximity, QR codes, physical presence buttons, etc.). Quite a pain for smartbulbs or other numerous IoT. If ZTNA is solved then 802.1x is trivial as well for e.g. preventing bandwidth stealing.
EDIT: I guess Matter is leading the way here. I need to do some more reading/learning on that.
[0] https://www.rit.edu/wisplab/sites/rit.edu.wisplab/files/2022...
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.
I turn WiFi mine off and use my own WiFi ap.
Still an interesting attack though.