Hacker News Reader

Comment by benlivengood | Hacker News Reader

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 something because that doesn't sound like it allows the worst kind of attacks, e.g. drive-by with no ability to associate to APs without cracking keys.

View on HN

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

I should reinforce this point by saying that it's the default position for "guest" networks to be using the same hardware as "secure" office wifi and such.

I'd further reinforce this by pointing out that this is what the specific term, guest network, means - it's the common name used by router manufacturers to describe an optional feature of serving secondary network from the same hardware, intended for the specific, common use case of serving transient and/or less trusted users.

This is in contrast to more genetic, descriptive terms like "additional network", "separate network for guests", etc.

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.

Fun story, back in uni, if you would spin up a webserver ($ python -m http.server 8000 for example) one could access it from other campuses. We never tried it across countries, but it might (have) worked

That's usually just because it's the same network, it's not a loss of isolation.

It is possible for your university to run a single WiFi network that is multi-campus, and so some "local" packets have to be sent between campuses, whether that's a good idea doesn't necessarily affect whether it's how it was set up.

If your university has campuses in other countries (as mine does) it is not likely they use a single WiFi LAN though it isn't impossible. However the fact that the networks operated by UCLA, Manchester University and the Sorbonne are all named "eduroam" is just for the pragmatic reason that WiFi devices connect by name, those aren't the same WiFI LANs, any more than the guy I know named "Steve Harris" is the bassist from Iron Maiden just because they share the same name.

[The Eduroam name has more significance than the coincidence of name, but that's all the name is doing here, WiFi devices which trust your local cafe "Coffee WiFi" will also connect to the "Coffee WiFi" offered in a completely different store.]

Having an public IP was one of the perks of being on campus up until 2010 at least, it is still the policy of Eduroam at least here YMMV

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

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

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.

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

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.

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

I mean yes and no, if an AP is configured for multiple VLANs you could implement inter VLAN routing on the AP itself. It seems stupid but if your software is ported from a switch or a router to an AP, it could include that.

But yeah I agree, generally it would be receive traffic on a bssid, tag it, and send it out the wire upstream and let the switch deal with sending it back if its allowed by whatever VLANing policy you have.

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.

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

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.

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.

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.

Without 802.1X (EAP), there isn't really a way to achieve client isolation against inside attackers who can mount mc-mitm [0] attacks against base stations and clients. The basic problem is single shared secrets that allow anyone who knows it to act as any of the participants (which also breaks privacy). Unfortunately the infrastructure for EAP is unwieldy for unmanaged devices.

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

So if you're running multiple SSIDs on a single router, but all of them use encryption and require a passphrase (i.e., none of them are open), the attacks you are describing don't work?

To clarify, the passphrase for each SSID is different, and the question is whether, first, an client that doesn't know any of the passphrases can somehow attack other clients who do, and second, whether a client that knows the passphrase for one SSID can attack clients connected to the other SSID (which has a different passphrase)?

My interpretation:

First, they can't attack a WiFi access point for which they do not know any password(s). Thus your multi-SSID access point with multiple passwords is "safe" from this particular attack.

However, second, they can attack an access point for which they know any password, gaining access to clients on the other SSIDs. This means your security is now effectively only the security of your worst SSID's password. It also may defeat your purpose in having multiple SSIDs/passwords in the first place.

>Of course it's you / partially you

Absolutely love your work, go strong. I click these thread and always expect your name to pop up

Is this one possibility?

- Buy cheap IOT device

- Isolate it on guest network

- IOT device is compromised (or shipped that way)

- IOT device now has clear access to traffic on both your guest and primary networks

Is that accurate?

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.

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?

Wireless cards typically don't expose the VLAN tags directly. So VLANs should be OK.

This is probably the biggest issue.

I turn WiFi mine off and use my own WiFi ap.

Yeah, along these lines I've always been biased strongly against using ISP hardware beyond the minimum required to connect to the outside world.

See also: Amazon's Sidewalk (which shares your network via Ring camerae, e.g.).

As of a few years ago, you could simply spoof your MAC to that of a Comcast subscriber with these and you'd get unrestricted access on the hotspot.

Im not 100% sure but I think for captive portal this would def work. For the authenticated wpa3 or whatever i think theyve actually added 802.1x

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.

Access points frequently have multiple BSSIDs even if just for broadcasting on 2.4 and 5 at the same time. Any multiple AP scenario will have them regardless. Couple that with weak duplicate MAC checking and shared GTK (WPA2-PSK) and the attack becomes trivial. I imagine old hardware will be broken forever. Especially pre 802.11w.

That’s my read as well. It’s not good, but it’s not nearly as bad as the headline makes it sound.

Reply on news.ycombinator.com