I often have a dev server running bound to 0.0.0.0 as it makes debugging easy at home on the LAN, but then if I connect to a public WiFi I want to know that I am secure and the ports are closed. "Block all incoming connections" on macOS has failed me before when I've tested it.

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.

To prevent malicious Wi-Fi clients from attacking other clients on the same network, vendors have introduced client isolation, a combination of mechanisms that block direct communication between clients. However, client isolation is not a standardized feature, making its security guarantees unclear. In this paper, we undertake a structured security analysis of Wi-Fi client isolation and uncover new classes of attacks that bypass this protection. We identify several root causes behind these weaknesses. First, Wi-Fi keys that protect broadcast frames are improperly managed and can be abused to bypass client isolation. Second, isolation is often only enforced at the MAC or IP layer, but not both. Third, weak synchronization of a client’s identity across the network stack allows one to bypass Wi-Fi client isolation at the network layer instead, enabling the interception of uplink and downlink traffic of other clients as well as internal backend devices. Every tested router and network was vulnerable to at least one attack. More broadly, the lack of standardization leads to inconsistent, ad hoc, and often incomplete implementations of isolation across vendors. Building on these insights, we design and evaluate end-toend attacks that enable full machine-in-the-middle capabilities in modern Wi-Fi networks. Although client isolation effectively mitigates legacy attacks like ARP spoofing, which has long been considered the only universal method for achieving machinein-the-middle positioning in local area networks, our attack introduces a general and practical alternative that restores this capability, even in the presence of client isolation.

>The most powerful such attack is a full, bidirectional machine-in-the-middle (MitM) attack, meaning the attacker can view and modify data before it makes its way to the intended recipient. The attacker can be on the same SSID, a separate one, or even a separate network segment tied to the same AP. It works against small Wi-Fi networks in both homes and offices and large networks in enterprises.

----

I wardrove back in the early 2000s (¡WEP lol!). Spent a few years working in data centers. Now, reasonably paranoid. My personal network does not implement WiFi; my phone is an outgoing landline; tape across laptop cameras, disconnected antenna; stopped using email many years ago...

Technology is so fascinating, but who can secure themselves from all the vulnerabilities that radio EMF presents? Just give me copper/fiber networks, plz.

----

>the next step is to put [AirSnitch] into historical context and assess how big a threat it poses in the real world. In some respects, it resembles the 2007 PTW attack ... that completely and immediately broke WEP, leaving Wi-Fi users everywhere with no means to protect themselves against nearby adversaries. For now, client isolation is similarly defeated—almost completely and overnight—with no immediate remedy available.

On WPA3/SAE this is more complicated: the standard supports password identifiers but no device I know of supports selecting an alternate password aside from wpa_supplicant on linux.

"If the network is properly secured—meaning it’s protected by a strong password that’s known only to authorized users—AirSnitch may not be of much value to an attacker."

These attacks are not new: the shocking thing here that apparently a lot of enterprise hardware doesn't do anything to mitigate these trivial attacks!

Essentially everyone with the SSID on multiple access point MAC addresses can get pwned.

Neighhood hackers drove me to EAP TLS a few years ago, and I only have it on one frequency, so the attack will not work.

The mitigation is having only a single MAC for the AP that you can connect to. The attack relies on bouncing between two. A guest and regular, or a 2.4 and 5, etc.

I need to research more to know if they can read all the packets if they pull it off on EAP TLS, with bounces between a 2.4 and 5 ghz.

It is a catastrophic situation unless you are using 20 year old state of the art rather that multi spectrum new hotness.

It might even get folks on a single SSID MAC if they do not notice the denial of service taking place. I need to research the radius implications more. TLS never sends credentials over the channel like the others. It needs investigation to know if they get the full decryption key from EAP TLS during. They were not using TLS because their tests covered Radius and the clients sending credentials.

It looks disastrous if the certificates of EAP TLS do not carry the day and they can devise the key.

That is my take.

Then comes network isolation and you can no longer turn on your Elgato Wi-Fi controlled light, talk to your Bose speaker, or use a Chromecast.

"WPA2/3-Enterprise. These attacks generally do not work against WPA2/3-Enterprise networks..."

So this is a protocol attack, not an encryption attack. If you're using proper encryption per client, there is no attack available.

https://github.com/zhouxinan/airsnitch

Edit: it’s the same repo as linked in the paper, so it seems likely to be the correct repo, though I didn’t originally find it via the paper.

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.

https://obdev.at/products/littlesnitch/index.html

Still an interesting attack though.

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

This is likely not a big deal for your home network, if you only have one network, but for many enterprise setups probably much worse.

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 work on https://supernetworks.org/. We propose a solution to these flaws with per-device VLANs and encourage per-device passwords as well.

More practically the risk for these attacks is as follows. A simple password makes sense for easy setup on a guest network, that's treated as untrusted. These passwords can probably be cracked from sniffing a WPA2 key exchange -- who cares says the threat model, the network is untrusted. But this attack lets the insecure network pivot out into the secure one.

It seems as if approved guest access now == system-wide access (at the hardware level). User compartmentalization no longer works.

WiFi provides half-way measures with client isolation features that break down when the packets hit L3, or in some cases the broadcast key implementations are deficient allowing L2 attacks. The paper is about all of the fun ways they could pivot across networks, and they figured out how to enable full bidirectional MITM in a wider class of attacks than commonly known or previously published.

Ironically one of the main pain points is Apple. keychain sync means all the apple devices on the same sync account should share a password for wireless. Secondly the MAC randomization timeouts require reassignment.

The trouble with SAE per device passwords is that the commit makes it difficult to evaluate more than one password per pairing without knowing the identity of a device (the MAC) a-priori, which is why it's harder to find this deployed in production. It's possible for an AP to cycle through a few attempts but not many, whereas in WPA2 an AP could rotate through all the passwords without a commit. The standard needs to adapt.

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.