[HN Gopher] MacStealer allows for WiFi client isolation bypasses...
___________________________________________________________________
MacStealer allows for WiFi client isolation bypasses
(CVE-2022-47522)
Author : oger
Score : 45 points
Date : 2023-04-15 17:46 UTC (5 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| daveidol wrote:
| 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
| Maursault wrote:
| 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.
| aaronbrethorst wrote:
| https://en.wikipedia.org/wiki/Buffalo_buffalo_Buffalo_buffal.
| ..
| supernetworks wrote:
| 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.
| sargun wrote:
| 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.
|
| Do yall have a better solution?
| supernetworks wrote:
| Yes -- except for limited wireguard support, usability for
| multicast is mostly solved. SPR services mDNS and
| Zeroconf/SSDP with a udp proxy[1].
|
| [1] https://github.com/spr-
| networks/super/blob/main/multicast_ud...
| xoa wrote:
| 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.
| mittermayr wrote:
| 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?
| akira2501 wrote:
| > Also, the URL params, headers, Cookies, etc are all encrypted
| at this point.
|
| To external sites, sure. To internal ones? I would not be so
| sure.
___________________________________________________________________
(page generated 2023-04-15 23:00 UTC)