Live data from Hacker News

AirSnitch: Demystifying and breaking client isolation in Wi-Fi networks [pdf]

ndss-symposium.org

111–120 of 204 posts

Re: AirSnitch: Demystifying and breaking client isolation in Wi-Fi networks [pdf]

#111
post #110

Earlier quoted context omitted.

It is hard to disagree with this approach. While I still use WiFi, it is a separate subnet and only whitelisted MACs are allowed to use it. Cameras and microphones are always unplugged when not in use, and my phone runs GrapheneOS. I also removed the hands-free microphone in my car, as well as the cellular modem.

Is MAC whitelisting anything but security theater? Isn't it trivial to determine a valid client MAC then spoof it?

What makes you say that? It does not seem trivial at all to guess a valid MAC.

Re: AirSnitch: Demystifying and breaking client isolation in Wi-Fi networks [pdf]

#112

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 som…

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.

Re: AirSnitch: Demystifying and breaking client isolation in Wi-Fi networks [pdf]

#113

Bit of a sensational title? This doesn't "break WiFi encryption", only device isolation if the attacker is already in the same network.

I'm a co-author on the paper: I would personally not use the word break but instead bypass, to indeed clarify we can't just 'break' any network. We specifically target client isolation, which is nowadays often used, and that proved possible to bypass. If you don't rely on client/network isolation, you are safe.

Re: AirSnitch: Demystifying and breaking client isolation in Wi-Fi networks [pdf]

#114
post #110

Earlier quoted context omitted.

Is MAC whitelisting anything but security theater? Isn't it trivial to determine a valid client MAC then spoof it?

What makes you say that? It does not seem trivial at all to guess a valid MAC.

It's not just a guess.

Any decent sniffer (e.g. airsnort) can immediately identify all associations between all WiFi/Bluetooth devices. DD-WRT (router firmware/OS) has this WiFi-associations detector built-in ("local WiFi map"). There is no need to attempt any sort of hack — associations are publicly-broadcast information.

Then, just pick any authorized MAC and duplicate as your own.

Re: AirSnitch: Demystifying and breaking client isolation in Wi-Fi networks [pdf]

#115

Earlier quoted context omitted.

> Essentially everyone with the SSID on multiple access point MAC addresses can get pwned You still have to be able to authenticate to some network: the spoofing only allows users who can access one network to MITM others, it doesn't allow somebody with no access to do anything. In practice a lot of businesses have a guest network with a public password, so they're vulnerable. But very few home users do that.

I run a website, video game servers, and Nextcloud. I have the nextcloud set to only allow access from my IP. It has to be open to the world with a domain name so I can use LetsEncrypt certs so it cannot only use private ip addresses which cannot be easily configured and trusted for https. I have been relying on EAP TLS via wifi so my phones could upload their photos and videos to Nextcloud.It was way cheaper than do…

I admittedly don't have practical experience with RADIUS, but I read it as a more narrow attack:

> We verified that an attacker, having intercepted the first RADIUS packet sent from the enterprise AP, can brute-force the Message Authenticator and learn the AP passphrase.

I thought RADIUS fundamentally negotiates based on a PSK between the AP and the RADIUS box, which the attacker doesn't have? They're saying this gives you the ability to brute force that PSK, but if the PSK isn't weak (e.g. a dictionary word) that's hopeless.

Re: AirSnitch: Demystifying and breaking client isolation in Wi-Fi networks [pdf]

#116
post #110

Earlier quoted context omitted.

Is MAC whitelisting anything but security theater? Isn't it trivial to determine a valid client MAC then spoof it?

What makes you say that? It does not seem trivial at all to guess a valid MAC.

It's in managmenet frames that you can sniff.

Re: AirSnitch: Demystifying and breaking client isolation in Wi-Fi networks [pdf]

#117
post #110

Earlier quoted context omitted.

Is MAC whitelisting anything but security theater? Isn't it trivial to determine a valid client MAC then spoof it?

What makes you say that? It does not seem trivial at all to guess a valid MAC.

The MAC addresses of all the Wi-Fi clients are broadcasted in plain radio format all over the 2.4GHz. It is trivial.

Re: AirSnitch: Demystifying and breaking client isolation in Wi-Fi networks [pdf]

#118

Even if they can rewrite the MAC and force a new one via ping, which are usually already disabled, they still can’t eavesdrop on the TLS key exchange. I fail to see how this is a risk to HTTPS traffic? It’s a mitm sure but it is watching encrypted traffic.

The Ars article mentions: “Even when HTTPS is in place, an attacker can still intercept domain look-up traffic and use DNS cache poisoning to corrupt tables stored by the target’s operating system.” Not sure, but I think this could then be further used for phishing.

DNSSEC prevents that if set up properly.

Re: AirSnitch: Demystifying and breaking client isolation in Wi-Fi networks [pdf]

#119

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 som…

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 whe…

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.

Re: AirSnitch: Demystifying and breaking client isolation in Wi-Fi networks [pdf]

#120
Client isolation is helpful in the real world, but it's yet another band aid for the deeper more fundamental problem.

If a device is insecure when placed directly onto the Internet with no firewall, it is insecure. Full stop. Everything else is a hack around that fact. Sometimes you have to do that since you can't fix broken stuff, but it's still broken.

Post reply on HN