WiFi protocol flaw allows attackers to hijack network traffic | Hacker News Reader

WiFi protocol flaw allows attackers to hijack network traffic

bleepingcomputer.com

88 pointsilikepi18 comments

The tools used, and a better readable description of the actual attack.

Every time I see a serious headline like this, get that unnerving feeling it's got to be Mathy, because it's always Mathy.

Why has the WiFi Alliance constantly ignored everything he's advised until a PoC arrives? At a certain point it looks like malfeasance rather than incompetence.

Because it's cheaper to wait for specific thing to break that to try to fix all the potential things that may break.

Actual paper: https://papers.mathyvanhoef.com/usenix2023-wifi.pdf

Doesn’t seem like a fundamental flaw in the IEEE 802.11 spec, but rather an implementation issue. For example my previous startup (Anyfi Networks) implemented 802.11 in a split-MAC architecture where all encryption is done “in the cloud” and raw encrypted 802.11 frames are tunneled over IP. In such an architecture frames are encrypted long before being put in the power save queue in the access point.

Interesting!

This said, isn't it the same kind of attack that a malicious router (on the route between the sender and the receiver) could run? I.e. exploiting a plaintext connection?

It feels like using an encrypted connection like HTTPS prevents it, right?

Exactly! While such research is cool, I think this has been long solved using HTTPS everywhere. You simply can't trust the router. Without HTTPS, all you need is a honeypot router that acts as a man-in-the-middle, which is not that hard of a setup.

If the bad actor is injecting malicious javascript over plain text http to the device, doesn’t that get around this? Or is it possible to force the target ios/android/etc device to only accept https packets?

If my understanding is correct, it means you can’t really use unencrypted protocols even within an intranet or home network when it is wifi-based, which is kind of a pain due to certificates, and for example DNS typically being unencrypted.

This attack does require bypassing some network security already. It defeats client isolation but the attacker does need to be on the WiFi network already (according to https://github.com/vanhoefm/macstealer).

AP isolation is usually off for all but big hotspots in my experience. This will be a problem for people using AP isolation for preventing their IoT from connecting to other devices in their network, assuming their IoT is malicious, but other than that the risk seems to be mostly with professional/corporate networks.

There are still plenty of cleartext HTTP connections from most devices. An attacker only needs one to build the rest of an attack off of, e.g. wait for the browser to request http://banners.some-ad-platform.com/12345.html, spoof a response that redirects to http://<domain-to-execute-javascript-in>/xss.html, and then spoof the response to that second request with arbitrary JavaScript.

There are other factors that can make it less exploitable for a specific attack, like HSTS being enabled for a specific site, but unless you have some kind of host-based firewall that blocks all outbound cleartext connections, there's probably some potential for exploitation.

Is it my imagination, or has TLS always been more secure than Wifi?

Plot twist: Musk is the leaker.

To exploit this fully you would require a lot of info, on top of that you're not getting anything from encrypted TLS packets.

If you're passing around sensitive information with even TLS then you're already exposed to far easier attacks than this.

Interesting find but nothing to worry about overall.

I for one am very concerned that someone may be able to spoof a device on my WLAN and listen to plain text packets or spoof packets of a device. Do you know how many users would click proceed if they got a certificate mismatch warning not even knowing what it means?

I don't know if that's right. It seems to me that this could be a critical part of a larger attack:

One attack that occurs to me is to pause a client when it is looking up a DNS name, but before it has gotten the response. With the plaintext DNS response you can get the ID field and forge a response. If you can do this during an HTTP request you might be able to redirect your victim to another server.

TLS might be much of a problem either: a lot of devices poll HTTP urls to detect "captive portals" -- many offices even use these for corporate login via wifi, so our attacker may attempt to go after this infrastructure to collect corporate credentials.

There's probably more: Applications have been assuming this wasn't possible for a long time, so there are likely a lot of vulnerable targets.

Is it really different than any other MITM?

It is a MitM attack on WiFi networks that seems to have an effect similar to the one provided by ARP spoofing, but works on networks with client isolation enabled, where ARP spoofing doesn't.

Reply on news.ycombinator.com