Navigating the impact of Wi-Fi FragAttacks: users, developers and asset owners

In short: Wi-Fi devices are affected by a series of new attacks on the Wi-Fi protocol, known as FragAttacks and released in May 2021. These attacks have complex requirements and impacts. We attempt to shed some light on those and provide some guidance for users, developers and asset owners (integrators or IT staff).

---

FragAttacks in a nutshell

FragAttacks are a new collection of vulnerabilities affecting Wi-Fi devices, discovered and released by Mathy Vanhoef in May 2021. In this post, we will not dive into the technical details of the attacks – if you are interested, we highly recommend Mathy’s paper, which is an excellent technical read and does a great job of explaining the nitty-gritty details.

Instead, we will focus on the exploitation requirements and concrete impact of these vulnerabilities, hoping to help users, developers, integrators and IT staff understand them better and take appropriate actions. If you are only interested in the “take home” message and actionable points feel free to skip to the Conclusion and Aftermath sections 🙂

Attack requirements and impacts

Off the top, it is important to understand that FragAttacks are a collection of vulnerabilities that can be divided in two groups:

1. Design flaws in the 802.11 (Wi-Fi) standard: these affect all Wi-Fi networks, from WEP to WPA3. They can abused using three attacks: frame aggregation (CVE-2020-24586), mixed-key attacks against fragmentation (CVE-2020-24587) and fragment cache poisoning (CVE-2020-24588). They affect most Wi-Fi access points (APs) and client devices (ex. IoT devices, mobile phones, personal computers etc.).
2. Implementation flaws: these affect specific devices (APs or clients). They include all the rest of the FragAttacks CVEs.

Zooming in on the Wi-Fi design flaws (CVE-2020-24586/7/8)

Let’s first start with the possible impacts: what can happen if an attacker successfully exploits one of these flaws. There are two possibilities: traffic injection and traffic exfiltration.

💉 Traffic injection

The attacker can send traffic to a Wi-Fi connected client or an AP without being connected to the Wi-Fi network (i.e. without knowing the Wi-Fi credentials). Both home and enterprise networks can be affected.

The concrete impact of this depends on the device / AP being targeted:

• if there are vulnerable network services listening on the target, the attacker could attempt to exploit them. For example, if the target is an alarm system and it can receive commands on a UDP port without authentication, the attacker could send a UDP packet disabling the alarm (see our Hacking Connected Home Alarms post for more on attacking alarm systems).
• if the target supports IPv6, it is possible to redirect its traffic to a malicious server controlled by the attacker by abusing DNS. The attacker might then be able to intercept and manipulate the rest of the victim’s traffic. This could allow them to retrieve credentials, cookies and other confidential information. However, the impact depends on the security of the protocols used. For example, the attack might not be effective if the victim verifies the identity of the server it connects to (ex. an IoT device using certificate pinning for its backend TLS endpoints will not be affected).
• if the target is an AP, the injected traffic can also be used to punch holes into its NAT, therefore allowing attackers to remotely target devices connected to the AP – in that case, the impact depends once more on the services listening on the targeted device.

🕳 Traffic exfiltration

The attacker can obtain parts of traffic sent by Wi-Fi clients.

It is important to understand that these traffic fragments will not be encrypted on the Wi-Fi level, but can be encrypted on the application level, depending on the protocol used by the client. For example, if the exfiltrated traffic is HTTPS, the attacker will not be able to read it. Therefore, this impacts mostly traffic using plaintext protocols (HTTP, FTP etc.).

It is also important to point out that the attacker might not be able to control with precision which traffic fragments they will receive.

Requirements

All three attacks have a series of relatively complex requirements to be successfully exploited. We provide a high-level overview of the main ones in the table below.

Requirement	CVE-2020-24586	CVE-2020-24587	CVE-2020-24588
Physical proximity to Wi-Fi network: the attacker must perform an active Man-in-the-Middle attack against the Wi-Fi network, discussed in detail here. In brief, the attacker duplicates the target network using a network card, jams the original network and forces the targeted client to connect to their clone. They then relay messages between the client and the original AP. This allows them to selectively modify Wi-Fi frames. Note that since the attacker does not have Wi-Fi credentials, the payload of the frames remains encrypted.	✗	✗	✗
Trick a client: the attacker must trick a Wi-Fi client in the target Wi-Fi network to connect to a malicious server. This is so that either the client or the server can generate a malicious IP packet, which the Wi-Fi client or the Wi-Fi AP will encrypt and include in a frame. The attacker needs that frame to trigger the attack: they intercept it using their MitM position and alter it accordingly. Without this technique, the flaws cannot be exploited, since the attacker cannot influence the encrypted payload of the Wi-Fi frames directly. In practice, this can be accomplished through social engineering: for example, sending an email with a malicious link that the victim opens on their computer while they are connected to the Wi-Fi network. Naturally, this is not possible for clients such as IoT devices.		✗	✗
Client sending fragmented frames: for the flaw to be exploited, one of the clients in the Wi-Fi network needs to send fragmented Wi-Fi frames. This is an optimization done by newer devices, so older devices might not allow attackers to trigger the flaw.	✗	✗
Specific AP configuration: the AP must be configured to periodically refresh client session keys. This is generally not the case by default, so this requirement is unlikely to be satisfied in most Wi-Fi networks.		✗
Valid Wi-Fi credentials: this is a special requirement for attacks against Wi-Fi hotspots that enforce client isolation. CVE-2020-24586 can be used to bypass the isolation and exfiltrate traffic from or inject traffic to other clients, but the attacker needs a pair of Wi-Fi credentials to be connected to the hotspot as well.	✗

Depending on the attack, some other conditions might also be necessary: for example, for CVE-2020-24586, the target’s cache must not be cleared regularly and frames must be reassembled in a specific way. This means that some systems are not vulnerable (for example, OpenBSD-based APs are not affected by CVE-2020-24586).

Zooming in on the implementation flaws (rest of CVEs)

The rest of FragAttacks’ CVEs are implementation flaws and can be divided in two subgroups.

Conclusion

The three “base” attacks (CVE-2020-24586/7/8) affect most Wi-Fi devices, but are unlikely to be abused at scale against regular users.

This is because in practice they require a combination of the attacker being physically present near the Wi-Fi network, social engineering and, in some cases, a specific network configuration. We believe the most likely scenarios of abuse concern high-value targets in spear-phishing scenarios.

Some of the implementation flaws, especially those allowing plaintext injection of frames, allow bypassing the social engineering component and injecting packets in protected networks without other requirements, therefore they are more dangerous in practice. However:

• they are device-specific, meaning that not all devices are affected;
• they still require the attacker to be in proximity of the target Wi-Fi network;
• their impact depends on the security of the target (presence of vulnerable services, hardening measures, use of secure protocols like HTTPS etc.).

Aftermath – what can I do?

We leave you with some actions points for regular users, developers and asset owners.

Regular user:

✔ Keep all your devices (home Wi-Fi access point, personal computer, mobile devices, IoT devices) updated. If you are not sure that a device has an automatic update mechanism, check the vendor website or contact them for more information about how updates are performed.

✔ Use a modern, up-to-date web browser.

✔ Do not ignore browser messages warning you about insecure connections.

✔ Be cautious when following links in e-mails and messages.

✔ Avoid connecting to public Wi-Fi hotspots (open hotspots or hotspots with a shared password, like at a coffeeshop).

Developer:

✔ Check with the manufacturer of the device you are using (or with the supplier of the Wi-Fi hardware) for guidance on the impact and remediation of FragAttacks on your platform.

✔ Test your platform using the testing tool provided by Mathy.

✔ Properly secure the services exposed or used by your application. For example: use a secure protocol such as TLS, take advantage of mechanisms such as certificate pinning and enforce proper authentication on all listening services. Don’t hesitate to take a look at the OWASP ISVS for more guidance.

Asset owner (device integrator or IT staff) :

✔ Check with product vendors for guidance and patches against FragAttacks.

✔ If you are responsible for IT security, ensure users are properly educated about phishing and social engineering tactics.

✔ If your infrastructure has support for rogue AP monitoring, ensure it is enabled and alerts are acted upon.

If you still have questions or need help navigating the impact of these attacks, don’t hesitate to get in touch!

About the author

Théo Rigas is an IT Security Consultant at NVISO. His main areas of focus are IoT and embedded device security. He regularly performs Web, Mobile and IoT security assessments for NVISO and contributes to NVISO R&D.