Cybersecurity researchers in Belgium and the US recently published a paper scheduled for presentation later this year at the USENIX 2023 conference.
The three co-authors couldn’t resist a punning title, dubbing their attack Framing Frames, with a slightly easier-to-follow strapline that says Bypassing Wi-Fi encryption by manipulating transmit queues.
As security researchers are wont to do, the trio asked themselves, “What happens when a Wi-Fi user disconnects temporarily from the network, either accidentally or on purpose, but might very well reappear online after a short outage?”
Queue it up just in case!
The wireless chip in a phone or laptop might temporarily drop into power-saving or “sleep” mode to conserve power, or drift out of range and then back in again…
…during which time, access points often save up any reply packets that arrive for requests that were still unanswered at the time that the device powered down or went out of range.
Given that a client that’s disconnected can’t initiate any new requests until it announces its return to active participation in the network, an access point isn’t likely to get bogged down with that many left-over reply packets for each inactive user.
So, why not simply queue them up, as long as there’s enough free memory space left, and deliver them later when the device reconnects, to improve convenience and throughput?
If memory runs low, or a device stays offline for too long, then queued-up packets can harmlessly be discarded, but as long as there’s space to keep them there “for later”, what harm could that cause?
Shaking stray packets loose
The answer, our researchers discovered, is that so-called active adversaries might be able to shake loose at least some queued-up data from at least least some access points.
The queued-up data, it turned out, was stored in decrypted form, anticipating that it might need to be re-encrypted with a new session key for delivery later on.
You can probably guess where this is going.
The researchers figured out various ways of tricking some access points into releasing those queued-up network packets…
…either without any encryption at all, or encrypted with a new session key that they chose for the purpose.
Sleepy bypass
In one attack, they simply told the access point that they were your wireless card, and that you were about to go into “sleep mode”, thus advising the access point to start queuing up data for a while.
Annoyingly, the “I am going taking a nap now” requests were not themselves encrypted, so the researchers didn’t even need to know the Wi-Fi network password, let alone to have sniffed out the setup of your original session key (the PMK, or pairwise master key).
Shortly after that, they’d pretend that they were your laptop or phone “waking back up”.
They’d ask to reassociate to the access point, but with no encryption key set this time, and sniff out any queued-up replies left over from before.
They found that numerous access points didn’t worry about the fact that queued data that was originally requested in an encrypted format was now being released in unencrypted form, and so at least some data would leak out.
Don’t use that key, use this one instead
In another attack, they used a slightly different technique.
This time, they sent out spoofed packets to force your wireless network card to disconnect from the network, after which they quickly set up a new connection, with a new session key.
For this attack, of course, the need to know the Wi-Fi network key, but in many coffee shops or shared workplaces, those keys are as good as public, typically written on a blackboard or shared in a welcome email.
If they were able to kick you off the network at exactly the right moment (or the wrong moment from your perspective), for example just after you had sent out a request they were interested in…
…and they managed to complete their spoofed reconnection in time, they might be able to decrypt a few reply fragments queued up from before.
Even if you noticed you’d disconnected from the network, your computer would probably try to reconnect automatically.
If the attackers had managed to “eat up” any queued-up replies in the interim, your own reconnection wouldn’t be entirely seamless – for example, you might see a broken web page or a failed download, rather than a trouble-free recovery from the outage.
But gliches when you disconnect and then reconnect to wireless hotspots are common enough that you probably wouldn’t think much of it, if anything at all.
What to do?
For access point developers:
- If your access points runs on Linux, use the 5.6 kernel or later. This apparently sidesteps the first attack, because queued data won’t be released if it was encrypted on arrival but would be unencrypted when finally sent out.
- Flush traffic queues on key changes. If a client disconnects and wants to reconnect with a new session key, refuse to re-encrypt queued data received under the old key. Simply discard it instead.
For hotspot users:
- Minimise the amount of unencrypted traffic you send. Here, we’re talking about a second level of encryption on top of your Wi-Fi session key, such as HTTPS for your web browsing, and DNS-over-HTTPS for your DNS requests.
With an additional layer of application-level encryption, anyone who decrypts your Wi-Fi packets still can’t make sense of the data inside them.
The attackers may be able to figure out network-level details such as the IP numbers of servers you connected to, but if you stick to HTTPS while you are browsing, the content you send and receive will not be exposed by these admittedly limited attacks.
