Cybersecurity researchers in Belgium and the US have published a paper describing a way to bypass Wi-Fi encryption called "Frames Frames".
In the article, the scientists described bypassing Wi-Fi encryption by manipulating packet transmission queues, and also answered the main question: “What happens when a user temporarily disconnects from Wi-Fi, and reconnects after a short absence?”
The Wi-Fi chip in your phone or laptop may temporarily go into power-saving (“sleep”) mode to save power, or your smartphone may leave the Wi-Fi zone and then reconnect. During this time, the Wi-Fi access point stores response packets for requests that were not answered when the device was disconnected from the Wi-Fi network.
In this case, the access point queues packets as long as there is enough free memory space and delivers them later when the device reconnects. This improves convenience and throughput.
Experts note that if there is not enough memory or the device is offline for too long, then packets from the queue can be intercepted. However, what can be done if these packets are left in the queue?
The answer is that an attacker can “throw out” some data from the queue of certain access points. It is worth noting that the queued data is stored in decrypted form, and for subsequent delivery it is re-encrypted using a new session key.
In the first attack, the experts pretended to be a network card, and “told” the access point that they were going to go into sleep mode, thereby instructing the access point to queue data for a while.
Remarkably, the requests themselves, indicating that the Wi-Fi receiver was about to go to sleep, were not encrypted, so the researchers did not even need to know the Wi-Fi password. Moreover, it was not difficult to determine the setting of the initial session key (Pairwise Master Key, PMK).
The experts then pretended to be a laptop or phone waking up from sleep. Scientists asked to reconnect to the access point, but this time without the encryption key installed. As a result, the specialists were able to see all the answers in the queue, left over from the previous device.
The researchers found that queued data that was originally requested in an encrypted format is now given out in the clear, and therefore some of the data may be exposed.
In another attack, the experts sent fake packets to force the network card to disconnect from the network, after which they quickly established a new connection with a new session key.
For this attack, you need to know the Wi-Fi password, but in many cafes or common workplaces, the password is known - usually it is written in a prominent place or in an email to an employee.
If you disconnect from Wi-Fi at the right time, such as right after you sent the request, and still complete the fake reconnect, you will be able to decrypt several fragments of the response queued earlier.
When the device is disconnected from the network, it tries to automatically reconnect. If at this point a hacker is able to grab responses from the queue, when you reconnect, you should be able to see a broken web page or a failed download, rather than just a connection failure.
For hotspot developers:
- If your access points are running Linux, use kernel 5.6 or later. This circumvents the first attack because the data in the queue will not be sent if it was encrypted upon receipt, but will be unencrypted when it is finally sent.
- Reset traffic queues on key changes. If a client disconnects and wants to reconnect with a new session key, opt out of re-encrypting queued data received with the old key. Instead, just revoke it.
For hotspot users:
- Minimize the amount of unencrypted traffic you send. This refers to the second layer of encryption on top of your Wi-Fi session key, such as HTTPS for web browsing and DNS over HTTPS for your DNS queries.
With an extra layer of app-level encryption, anyone who decrypts your Wi-Fi packets can't see the data inside them. Attackers can obtain data at the network level, such as the IP addresses of the servers you are connected to. However, if you use HTTPS while browsing, the content you send and receive will not be subject to these attacks.