I swear Mathy Vanhoef has dedicated his life to making my life miserable. Every time he finds these wifi security problems, we get to spend weeks/months integrating and testing vendor patches.
Sounds like the Wi-Fi Alliance is making your life complicated!
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.
> This exploits a design flaw in hotspot-like networks and allows the attacker to force an access points to encrypt yet to be queued frames using an adversary-chosen key, thereby bypassing Wi-Fi encryption entirely. Our attacks have a widespread impact as they affect various devices and operating systems (Linux, FreeBSD, iOS, and Android) and because they can be used to hijack TCP connections or intercept client and web traffic
Interesting approach, that seems to be limited to Hotspots or am I getting this wrong?
See section 5.1 about threat model, hotspot just describes the threat model (network of distrusting clients). They do explicitly do test against some hotspot implementations, but the vulnerability isn’t limited to those.
For the life of me I don't understand either of these:
- 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?
> How do these not get caught with so many people studying the specs for decades?
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.
> Because extremely few people actually look at the detailed specs. You’d think more people did, but it turns out they don’t.
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?
I'd argue the number of startups that have trust all local network connections is not far behind. I doubt a company seriously considers their wifi connectivity as a threat vector until they get to a series B size.
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.
Many elaborate scams are not relevant to most people, but only to people with money. Most phishing attacks are not relevant to most people, only to people in some important enough positions, or with access to interesting enough networks.
But the damage of such attacks is still large enough to care.
I'm sure there are quite a lot of non-tech-startup small businesses in the same boat. And sure, still less than 50% of people own such business, but that something doesn't directly affect a majority doesn't mean it's not important.
I guess, to clarify, what I'm trying to get at is, should someone who hears "this computer/router/whatever supports WPA{N+1}, whereas that one just supports WPA{N}" factor that into their purchasing decision or not. And the answer I see seems to be, "if this is just for your household use, then no, unless you have reason to believe someone in your proximity would try to hack you".
Users certainly do still need to care about having encryption at the physical layer. Wi-Fi networks having done key exchange and taking that out of the equation for regular users so that they get some guarantees of encryption without constantly doing key exchange on their own is a big deal.
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 first point, the flaws are almost always in the implementation, not the design, though specs inevitably leave too much to the implementation.
Regarding your second point, security works in layers. Much like it's better to have two locks than one.
So the way it works is that if you have a setup like so:
Your client <-- bad actor --> Public Webserver.
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.
Technically I think it depends on whether someone can mess with your connection enough to convince the browser to fall back to HTTP. And whether you could be tricked into entering credentials on the wrong page.
How does your VPN handle having its connections blocked by an adversary in the middle?
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.
Wi-Fi has the same challenges as if someone just tapped an Ethernet cable. (Except the Ethernet line can't be sniffed from the parking lot.) The amount of unsecure traffic on a basic Ethernet network makes Wi-Fi security slightly better.
I don't think that's exactly true. Ethernet is a pretty simple physical-layer protocol only made for 1:1 connections, and you can't generally inject packets from a simple tap mid-cable. You would have to undetectably insert an active MITM device into the cable to get on the network, which is a lot more tricky to do than an undetectable tap.
An old hub (not switch) does exactly that: all traffic forwarded down each port and I can see what everyone was doing. Even with a switch, a misbehaving device can cause all sorts of havoc on an Ethernet network. 802.1X is supposed to provide port security but isn't used often. Anyone could plug into a wall port and get access to a corporate network.
A hub and an accessible wall port are not common parts of Ethernet networks today. The former hasn't generally been used since the 90's (putting it generously) and the latter is usually locked up. GP referred to a cable tap, which is just not going to give you access on an Ethernet network that you will find in any building today.
Old, old Ethernet specs used to include multi-drop buses and a "hub" model. That hasn't been true for a very long time.
Except there is a trick: In a switch, a port can only associate with limited number of hardware addresses. If you spam it with generated hw address, some switches put that port into open mode, some switch shutdown that port, the other just misbehaves.
Almost none of them keep a LRU list correctly
I think you're missing the point. Electrically, you can't "spam" anything on a tapped cable. It will just go down at the physical layer when you try to transmit unless you cut it and insert yourself between its endpoints (as a switch, essentially).
Well, that is totally wrong. And I deduct that you're rather young.
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.
I have actually read the Ethernet standard almost cover-to-cover, but GP was referring to Ethernet in the common use, not the technically-available options that can be tapped if your building happens to be from the 80's (or is a car). Also, at this point, a lot less of the available "Ethernets" can be tapped than you may be thinking.
Ethernet includes address and source identifiers so that multiple sources and destinations can be used on the same wire. As the sibling comment mentioned, hubs (not switches) simply broadcasted every frame to every connection, and the NICs at each end would have to determine if they were the intended destination. Some of them didn't even require power because they were essentially joining the wires together. Switches require power because they learn which destination the ports respond to and can route more efficiently based on that knowledge.
> Ethernet is a pretty simple physical-layer protocol only made for 1:1 connections, and you can't generally inject packets from a simple tap mid-cable.
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?
Ethernet as used in almost every facility has not practically been a shared-medium protocol for decades. The citation of "token ring" sort of dates your notion of "Ethernet."
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 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.
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?
They use the words "lack of explicit guidance", so maybe more of an unspecced-bug rather than a spec bug - but it's the same thing at the end of the day.
Saying that the spec should contain more guidance implies that that guidance is relatively obvious. It also implies that there is one correct way to resolve the issue that the guidance would resolve. That might not be the case. So it is usually best not to claim a specification issue where none technically exists. Just state clearly what you think should be done and leave it at that. The specification might not be incomplete depending on what approach is eventually taken.
Source: "Interesting Links" at https://old.reddit.com/r/termux/comments/19573gg/encryption_... ("Encryption, Decryption, Android 11 Operating System, Termux, And proot-distro Using Alpine Linux minirootfs: cryptsetup v2.6.1 And LUKS", old.reddit.com/r/termux/comments/19573gg/encryption_decryption_android_11_operating_system/).
