Hacker News

The attacker doesn't need to be connected to the victim's network, only to the same hardware, the hardware's loss of isolation is the unexpected problem.

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

What about XFinity, which by default shares the wifi you pay for with strangers to create access points around the city?

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.

That's my read as well. It's bad for places that rely on client isolation, but not really for the general case. I feel like this also overstates the "stealing authentication cookies": most people's cookies will be protected by TLS rather than physical layer protection.

Still an interesting attack though.

Access points frequently have multiple BSSIDs even if just for broadcasting on 2.4 and 5 at the same time. Any multiple AP scenario will have them regardless. Couple that with weak duplicate MAC checking and shared GTK (WPA2-PSK) and the attack becomes trivial. I imagine old hardware will be broken forever. Especially pre 802.11w.

That’s my read as well. It’s not good, but it’s not nearly as bad as the headline makes it sound.

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.

You would like the film The Conversation (1974).

That seems less annoying than a hotel full of people who can play whatever they want with my Chromecast. No malice is required for this to happen; it is completely possible to do by mistake.

Words like "I've been trying to use the Chromecast!" "The Living Room Chromecast?" "Yes! It says it's playing, but I don't see anything on the TV screen!" "You hit the play button, right?" "Yeah, and then it keeps stopping on its own!" "Are you sure you plugged it in?" "What in the world is wrong with this dumb thing?" drift between one partner and another in some other in some far corner of the hotel as they innocently trample my efforts to watch old episodes of How It's Made.

For all of these reasons, I tend to travel with a network that I control. That's usually in the form of some manner of very small router -- with a strong preference towards something that runs (or can run) OpenWRT. There's a ton of such "travel routers" in the market that are centered around $60 or so that don't take up much space at all.

I use this to slurp up whatever free wifi or ethernet I can get, or my phone tethering/hotspot, and I don't worry at all about how someone else's network might decide to treat me today. Whatever stuff I bring with me all works about as well as it does at home.

Even when not using client isolation, I've run into similar problems simply from having a computer connected over Ethernet instead of WiFi, and whatever broadcast method a gadget uses for discovery didn't get bridged between wired and wireless. (Side note: broadcast traffic on WiFi can be disproportionately problematic because it needs to be transmitted at a lowest common denominator speed to ensure all clients can receive it. IIRC, that usually means 6Mbps.)

I mean, yeah, isn't that the main purpose of client isolation? It sucks when you're on something like a locked down university dormitory network but it also stops (or at least, inhibits) other people from randomly turning on your lightbulb or worse, deploying exploits on your poorly engineered IoT device and lighting you up with malware.

Adding exceptions for certain protocols, IP ranges (maybe multicast, even) are certainly ways around this, but I imagine with every hole you poke to allow something, you are also opening a hole for data to leak.

Many businesses and universities, and likely some government offices, rely on client isolation for segmenting their networks. It’s a big deal.

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.

EAP TLS provides strong authentication, is much better than the other enterprise authentication options, but will not block these lateral attacks from other authenticated devices. The second half of the deployment is putting each identity into a VLAN to defend against the L2/L3 disconnects that can occur.

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.

They still need to be able to connect to one of the network no? So a home network without guest would be fine is my understanding?

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

Like as in me being on the Guest network at a business can then read traffic of the Corporate network?

IIUC the issue is, you could have a "secure" network and a guest network sharing an AP, and that guest network can access clients on the secure network. Someone did mention the xfinity automatic guest network, which might be a pain to disable?

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.

Hostapd now has support for multi pass SAE /WPA3 password as well. We have an implementation of dynamic VLAN+per device PSK with WPA3 (https://github.com/spr-networks/super) we've been using for a few years now.

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.

Little Snitch is probably the most popular one, written my devs who deeply understand macOS firewall architecture.

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

https://objective-see.org/products/lulu.html

LittleSnitch

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.

Only WPA2/3-Enterprise networks which offer no guest network access.

This attack exploits multi PSK networks precisely. If it's all one PSK the attacker can already throw up a rogue AP for WPA3 or just sniff/inject WPA2 outright. The back half of a secure multi PSK setup is deploying VLANs for segmentation, to block these attacks.

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.

A tad sensationalist perhaps, but "hot garbage" is a bit much.

For all users reading this on their own home network: DISABLE ALL GUEST NETWORKS

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

Just like it isn’t normal to buy one UPS per server, it is sensible to have one more capable firewall for all your servers, even if it does put you in a M&M situation.

Counterpoint: it is trivial to have too much network security - don’t provide power. It is difficult to have just enough network security.

That's an easy autocorrect issue. As someone who write Ubiquiti more often than most.

I don't even think most editors would know the difference. That's the problem with using corruptions of real words as your name.

IMO spelling mistakes have always been a relatively weak indicator of writing quality, let alone truthiness.

I was indeed very surprised to see that it's from Dan Goodin

I only read his articles occasionally, but they always impressed me favorably; this one instead... the paper is probably clearer even for less technical people.

Yeah, this is a much clearer source and the abstract gets pretty directly to the point. The first paragraph tells you pretty much everything you need to know before you read more. The Ars article took 4 paragraphs to mention "client isolation" and even longer to get into the meat.

Updated, thanks!

@dang, can we get the link and title changed?