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.
So, a long time ago, I implemented a similar system on top of some enterprise access points -- broadcast storms were just killing our Wi-Fi. The problem was mDNS / bonjour didn't work in this setup, although there was a way to use a routable multicast address, we couldn't get printers working.
Eventually we hacked something up where the AP controller could do proxy ARP, and google cloud print.
In an enterprise setup you usually ALG those things and block BUM traffic except for things that register for a routed stream in which case you have the system convert multicast to unicast to that client (in transport, not destination). If those are not a checkbox on your gear of choice then you have to build it yourself as you did.
VLANs+Subnets play little role in the end on a Wi-Fi SSID. Clients get put in the same GTK and hear everything in the same BSSID. You don't want to go making BSSIDs per client either as that kills airtime. Most of the time you're better off with a flat wireless network with the above controls as it functions exactly the same as a divided network where you need the same controls anyways but now it's simpler. Different subnets per SSID (for when you need to support different authentication methods, not for when you need different services to co-exist) can make things simpler though.
This sounds like ‘we had problem with devices talking to each other so we blocked that, and then services that require devices to talk to each other didn’t work!’
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?
Homophones are aggravatingly common. Can a bear bear it? It was just a fluke I caught a fluke using a fluke on a fluke while a fluke waved nearby. I took a bow on the bow. etc.
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.
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.