[HN Gopher] Framing Frames: Bypassing wi-fi encryption by manipu...
___________________________________________________________________
Framing Frames: Bypassing wi-fi encryption by manipulating transmit
queues
Author : sipofwater
Score : 129 points
Date : 2024-01-25 11:19 UTC (11 hours ago)
(HTM) web link (www.usenix.org)
(TXT) w3m dump (www.usenix.org)
| sipofwater wrote:
| 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_de
| cryption_android_11_operating_system/).
| londons_explore wrote:
| I can't quite see how this can be a spec bug...
|
| 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?
| Retr0id wrote:
| 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.
| upofadown wrote:
| 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.
| 3abiton wrote:
| > 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?
| cmrx64 wrote:
| 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.
| tmd83 wrote:
| So if the underlying connection isn't encrypted (like https) it
| essentially became open to anyone of the same network?
| kevindamm wrote:
| If you also know the adversary-chosen key, yes.
| dboreham wrote:
| I thought we didn't rely on WiFi encryption since...long ago?
| Most hotspots don't even have encryption enabled.
| bell-cot wrote:
| Security-wise, Wi-Fi has always been a steaming heap. And
| probably always will be.
| para_parolu wrote:
| What are better alternatives for wireless connectivity?
| Retr0id wrote:
| Alternative is the wrong question, I think.
|
| 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.
| dale_glass wrote:
| But that shouldn't be necessary. WiFi itself should be
| doing whatever wireguard adds to this setup.
| Retr0id wrote:
| It shouldn't be necessary, yet WiFi continues to show
| that it is.
| bell-cot wrote:
| Not to claim that 99% of users would show any preference for
| a better standard...but that's pretty much the problem.
|
| [Edit: Retr0id is perfectly correct...but even thinking in
| terms of a threat model has already excluded the 99%, if not
| more.]
| linuxlizard wrote:
| 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.
| pclmulqdq wrote:
| 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.
| linuxlizard wrote:
| 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.
| pclmulqdq wrote:
| 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.
| j16sdiz wrote:
| 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
| pclmulqdq wrote:
| 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).
| ppseafield wrote:
| 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.
| Metacelsus wrote:
| Maybe "Wired Equivalent Privacy" was a good choice of name,
| lol
| bee_rider wrote:
| Of course, the network isn't trustworthy; giving it encryption
| related tasks was a bad idea.
| linuxlizard wrote:
| 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.
| diggan wrote:
| Sounds like he is helping you discover who you should really be
| blaming for these found issues :)
| linuxlizard wrote:
| He's forcing me to work hard, dang it! I'm being forced to
| study WiFi carefully and learn his (really amazing) tools to
| fix these issues.
| tux3 wrote:
| 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.
| fulafel wrote:
| Wireless stuff has some bad times recently - bluetooth keyboard
| injection: https://news.ycombinator.com/item?id=38661182
| rjaco31 wrote:
| It's written in the paper that the PoC code has been published.
| But there is no link anywhere?
| spidersenses wrote:
| Paper:
| https://www.usenix.org/system/files/sec23summer_355-schepers...
|
| Tool: https://github.com/vanhoefm/macstealer
| dataflow wrote:
| 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?
| robertlagrant wrote:
| I also struggle to understand this. If I'm on a VPN or only
| using HTTPS, is my data safe?
| razemio wrote:
| Yes
| dataflow wrote:
| 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.
| fullspectrumdev wrote:
| 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.
| chunky1994 wrote:
| 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.
| mzs wrote:
| Your data is safe, but you can be prevented from connecting
| at all.
| teddyh wrote:
| > _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.
| dataflow wrote:
| > 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?
| chunky1994 wrote:
| 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.
| dataflow wrote:
| Startups, sure, but <1% of people are running such
| startups I imagine. So it's fair to say this isn't
| relevant to most people?
| nine_k wrote:
| 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.
| thfuran wrote:
| 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.
| ddtaylor wrote:
| 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.
| riedel wrote:
| Maybe one should note that this was reported 9 month ago:
| https://news.ycombinator.com/item?id=35353264
___________________________________________________________________
(page generated 2024-01-25 23:00 UTC)