MacStealer allows for WiFi client isolation bypasses

We designed SPR to address problems with wifi isolation. Every wifi device runs in an isolated subnet and individual VLAN. Mac spoofing is not possible since a device's MAC identity is combined with a device-specific PSK. You can check out the project here: https://www.supernetworks.org/

While we were not aware of these protocol flaws specifically, the project was inspired by fundamental weaknesses in secure wifi isolation. One of the attacks that's demonstrated in the scripts but not in the academic paper -- is that most routers will route UDP/IP packets between devices even when they are "isolated", so there are problems with most guest wifi networks even before mac stealer type attacks come into play.

In a time before HTTPS (which wasn’t too long ago), this would have been a lot more concerning. Of course, the extraction of a target IP may be interesting, but a device currently sends so many requests once it connects to the internet, anything from Apple/MS to all and every piece of software checking for updates… it sounds quite hard to nail the right timing and get a spicy result out of this. And once the attack happens, the target is disconnected and that was your one shot, no? Also, the URL params, headers, Cookies, etc are all encrypted at this point.

Not to diminish the effort and write up, I fully get how exciting this is to discover, but it feels a bit more at home in a bug report for router firmware. Am I missing something?

Funny this is exactly the same name as the macOS malware also being discussed on the HN front page: https://news.ycombinator.com/item?id=35581375

Very interesting looking research and examples. That at least as of their work they think VLANs can help mitigate it though is an important thing:

>We remark that our attack cannot bypass VLANs. In other words, based on current experiments, our attack cannot be used to exploit a device in another VLAN.

This is mostly how I've rolled things out, authorized users all get put on their own VLANs with the idea that traffic gets forced through the router and as another isolation layer. This applies to all authorized traffic. I say "mostly" though because at least two sites are run with a more generic "Guest" setup which is flat, and does indeed depend on client isolation. So while guest users would be unable to attack anything on all the other VLANs, they could attack each other. This then is another major motivation for:

>Note that when using multi-PSK (a.ka. per-station PSK or identity PSK), you can put clients in different VLANs depending on the password that they use. In other words, you can use a VLAN for each password. This prevents clients with different passwords from attacking each other.

MPSK (or "PPSK") was the final driving reason in beginning a switchover from UniFi to Omada for me, because it dramatically simplifies using VLANs even for completely unmanaged BYOD situations (a college for example). If everything under the sun supported 802.1x auth and the whole certificate situation was much better it wouldn't be an issue, but as it is getting huge numbers of devices (not just IOT, everything from TV appliances and consoles to a lot of new printers) onto the right VLAN was a pain requiring manual effort with MAC auth bypass which would be easily hoovered up too. MPSKs are a fairly elegant solution to that, you can just give people their own password or passwords, and then they can just use those as they would any typical WPA2-PSK network and everything ends up on the assigned VLANs without further IT assistance required. It's such a big feature that I think going forward I'm going to consider it essential. Also makes it easy to have even more IOT separation, every single last category of device (well, at least up to thousands) can be on its own VLAN no problem, and all the typical irritating """smarts""" of IOT stuff like where things of the same device manufacturer try to share WiFi password all is controlled and does as it should too.

One thing I would be curious about though was how this works with full virtual SDNs, which is now how all important stuff gets done, simply not trusting the physical network at all. They talk about traffic encrypted at a higher layer:

>We remark that intercepted traffic may be protected by higher-layer encryption, such as TLS and HTTPS. Nevertheless, even if higher-layer encryption is being used, our attack still reveals the IP address that a victim is communicating with. This in turn reveals the websites that a victim is visiting, which can be sensitive information on its own.

But I assume that if using WireGuard or Nebula or the like, particularly the former in a typical wheel/spoke setup, this leak would also be quelled? The VPN goes to either the router or other endpoint which can be isolated, and that then relays to the final destination, so being able to tell where the VPN traffic was going wouldn't reveal much. The mesh aspect of Nebula might reveal more, since it'd tell what other nodes were being communicated with, but as those are going to be internal and protected except via Nebula traffic I'm not sure if that's critical either, going out to websites would still mean getting proxied?

Anyway, guess another reminder that things lower down the stack can have surprises.