Framing Frames: Bypassing wi-fi encryption by manipulating transmit queues
usenix.org
usenix.org
From the makers of WEP (Wired Equivalent Privacy), the latest "Wi-Fi CERTIFIED 7" update is sure to bring your business up to enterprise-quality standards of security.
Interesting approach, that seems to be limited to Hotspots or am I getting this wrong?
- Why, after so many darn versions of Wi-Fi security standards, we still have attacks that just bypass encryption entirely. How do these not get caught during the design/implementation with so many people studying the specs for decades?
- Why 99% of end-users should even care about these issues from a security standpoint, given they already have https and such (because the transport is already assumed to be untrusted), and given that people have been connecting to "unsecured" networks for decades now, without the sky falling. Is the added security of each version of WPA even relevant to normal people?
Does it “fail open”? Or silently fail? Does it alert the user?
Does anything on your device use non-TLS? Software updaters? Are they susceptible to downgrade/fallback attacks?
When I last properly explored this I found a good number of automatic software updaters would fall back to plaintext HTTP (or just didn’t use TLS) and often didn’t perform much or any signature checking on updates.
Your first layer of defense is assuming its hard for a bad actor to get to that spot (which this attack is showing is possible).
Now the next thing the bad actor needs to do to compromise your traffic is deal with HTTPS/VPN. The only real way to do that would have to be to convince your client that the certificate from the CA that's signing the https traffic received from the webserver/VPN provider is trusted/ (i.e a classic MITM with a compromised client and a local CA).
Most clients will warn you that this cert is unrecognized, so with an untampered client unless you just clickthrough the cert warnings you will be protected. However, people often ignore cert warnings and that means that all your traffic is now cleartext for the bad actor.
Because extremely few people actually look at the detailed specs. You’d think more people did, but it turns out they don’t.
> Is the added security of each version of WPA even relevant to normal people?
It’s relevant for those who misguidedly have their network infrastructure set to trust all local network connections. In my experience, many people do.
Well that's depressing :(
> It’s relevant for those who misguidedly have their network infrastructure set to trust all local network connections. In my experience, many people do.
For 99% of people worrying about "network infrastructure" would only be relevant at home, right? So the threat model here is some nefarious nearby actor (your tech-savvy neighbor? someone else parked nearby who hates you and knows how to do these hacks?) is trying to hack you? How often does this actually happen?
Hypothetically I'd imagine if you take early startup infrastructure snooping + <insert criminal act here> you probably have a criminal enterprise that's cashflow positive.
But the damage of such attacks is still large enough to care.
You are correct that transport layer security like HTTPS can protect many connections end to end, however if you have MITM attacks on your physical layer they can do certificate pinning attacks, redirection attacks and more.
Sure, there is a good chance they won't get into your Gmail because Google embeds the certificates of their and the top other websites into their browser, but that's not much consolation.
Regarding your second point, security works in layers. Much like it's better to have two locks than one.
You should* assume the wireless connection itself is compromised and use an extra layer, like wireguard.
*Assuming this makes sense within your threat model. It's not something I think I should care about much, personally. Everything important I do goes over https anyway.
[Edit: Retr0id is perfectly correct...but even thinking in terms of a threat model has already excluded the 99%, if not more.]
Old, old Ethernet specs used to include multi-drop buses and a "hub" model. That hasn't been true for a very long time.
This is complete nonsense. Ethernet is a shared-medium protocol. The fact that it doesn't need any special handling of particular endpoints is one of the things that distinguishes it from e.g. Token Ring. How do you think it's possible to link two switches with a standard cable on standard ports? What on Earth are you basing your claims on?
The Ethernet spec is over 5,200 pages, including the old multi-drop buses, but the parts of the standard that specify the physical layer and actually get used, including 10/100/1GBASE-T and the fiber Ethernets, cannot support more than one endpoint on a wire.
You think Ethernet is 10BaseT, 100BaseT and similar, i.E. Twisted Pair. But original Ethernet was designed for Coax cable, for 1:many connections.
Basically you had one coax cable and run it from computer to computer. At both ends you had a terminator resistor of 50 Ohm. And at the computers you originally had vampire clamps, later T connectors. That was used until for two or maybe even three decades. First only in research, military and university (e.g. where also TCP/IP was originally was used). But later also e.g. for Novell Netware. The Terminator/RG58 cable/Network card with NE2000-clones or 3C359 cards was relatively cheap, so a lot of offices used that with some Novell Netware file server.
Ethernet was designed for many clients, the CD in CSMA/CD means collision detection. With only two clients, you could do some handshake, like with RS485. But with many clients, this can become cumbersome or impossible. So Ethernet decided to detect this, and to let the senders re-send the packets after a random back-off time.
On the https://en.wikipedia.org/wiki/Ethernet after "Shared Medium" you can see a picture of this entirely not 1:1 equipment :-)
Also Wi-Fi Alliance: Refactored(-ish) deauth to unprotected power-save bit.
I mean, why would client A be able to change the key used for communicating with client B?
Does this rely on some kind of confusion between clients? ie. force a client to disconnect, then the attacker connects using its mac address, and receives all the queued frames?