Holes in the WiFi

Did you know...? LWN.net is a subscriber-supported publication; we rely on subscribers to keep the entire operation going. Please help out by buying a subscription and keeping LWN on the net.

By Jake Edge
May 12, 2021

The discoverer of the KRACK attacks against WPA2 encryption in WiFi is back with a new set of flaws in the wireless-networking protocols. FragAttacks is a sizable group of WiFi vulnerabilities that (ab)use the fragmentation and aggregation (thus "Frag") features of the standard. The fixes have been coordinated over a nine-month period, which has allowed security researcher Mathy Vanhoef time to create multiple papers, some slide decks, a demo video, patches, and, of course, a web site and logo for the vulnerabilities.

Three of the vulnerabilities are design flaws in the WiFi standards, so they are likely present in all implementations, while the other nine are various implementation-specific problems. The design flaws may be more widespread, but they are much harder to exploit "because doing so requires user interaction or is only possible when using uncommon network settings". That means the real danger from FragAttacks lies in the programming errors in various WiFi implementations. "Experiments indicate that every Wi-Fi product is affected by at least one vulnerability and that most products are affected by several vulnerabilities."

In fact, in the FAQ section of the web site, Vanhoef offers to list any products that he can verify as not having been affected by the flaws described on the site. He also notes that even though the design flaws are difficult to exploit on their own, they can be combined with the other flaws found to make for a much more serious problem. "In other words, for some devices the impact is minor, while for others it's disastrous."

Fragging

As the names would imply, fragmentation and aggregation refer to ways that wireless "frames" can be split apart or coalesced depending on various constraints; large frames can be fragmented for reliability purposes, while smaller frames can be aggregated for better network throughput. Fragmentation problems that he noticed in Linux while working on the KRACK attacks in 2017 were what drew Vanhoef's attention to the problems, but he put off looking into it more closely until 2020.

Fast-forward three years later, and after gaining some additional ideas to investigate, closer inspection confirmed some of my hunches and also revealed that these issues were more widespread than I initially assumed. And with some extra insights I also discovered all the other vulnerabilities.

Aggregation is indicated in a frame with an "is aggregated" flag, but that flag is not protected ("authenticated" is the term Vanhoef uses) with the rest of the header, so an adversary can change its value without invalidating the frame. If the attacker can trick the victim into connecting to a dodgy server, they can cause the victim to process the encrypted data in an unintended way. That can lead to injecting arbitrary network packets into the victim's system by setting the aggregation flag for carefully selected frames. In the demo, that flaw is used to cause the victim to use a malicious DNS server.

The fix for that problem is obvious: add the flag to the protected portion of the frame. Ironically, the standard already has a way to do so, but it is not implemented by devices. Herein lies a lesson for those implementing "secure" systems:

Unfortunately, many products already implemented a draft of the 802.11n amendment, meaning this problem had to be addressed in a backwards-compatible manner. The decision was made that devices would advertise whether they are capable of authenticating the "is aggregated" flag. Only when devices implement and advertise this capability is the "is aggregated" flag protected. Unfortunately, in 2020 not a single tested device supported this capability, likely because it was considered hard to exploit. To quote a remark made back in 2007: "While it is hard to see how this can be exploited, it is clearly a flaw that is capable of being fixed."

In other words, people did notice this vulnerability and a defense was standardized, but in practice the defense was never adopted. This is a good example that security defenses must be adopted before attacks become practical.

Fragmentation is rarely enabled by devices, so the two design flaws found there have even less impact. Each fragment that belongs to the same frame is encrypted using the same key, but receivers are not required to ensure that is the case and will reassemble frames from fragments encrypted with different keys. "Under rare conditions this can be abused to exfiltrate data."

In addition, WiFi devices are not required to flush fragments that they have received—but not yet reassembled while waiting for additional fragments—from memory when a client disconnects from the network. An attacker can "preload" the device with some fragments and disconnect in anticipation of the victim connecting. If the victim uses fragmentation, "which appears uncommon in practice", the flaw can be used to exfiltrate data as well.

In both of these fragmentation cases, the fix is for devices to be more proactive than the standard requires. The device should ensure that all fragments are encrypted with the same key before allowing them to be reassembled and processed further. Likewise, fragments for incomplete frames should be flushed from memory when the client disconnects. Both seem like prudent "defensive programming" measures, at least in hindsight.

More flaws

The overview of the rest of the flaws shows how the different pieces can come together and lead to further mayhem:

Some routers will forward handshake frames to another client even when the sender hasn't authenticated yet. This vulnerability allows an adversary to perform the aggregation attack, and inject arbitrary frames, without user interaction.

Another extremely common implementation flaw is that receivers do not check whether all fragments belong to the same frame, meaning an adversary can trivially forge frames by mixing the fragments of two different frames.

Additionally, against several implementations it is possible to mix encrypted and plaintext fragments.

Finally, some devices don't support fragmentation or aggregation, but are still vulnerable to attacks because they process fragmented frames as full frames. Under the right circumstances this can be abused to inject packets.

Home networks are particularly vulnerable to the flaws and, given the spotty record of updates for many home-network devices, these kinds of problems may sadly persist for years to come. The demo (YouTube video) shows three examples of how the flaws can be exploited in that kind of environment:

First, the aggregation design flaw is abused to intercept sensitive information (e.g. the victim's username and password). Second, it's shown how an adversary can exploit insecure internet-of-things devices by remotely turning on and off a smart power socket. Finally, it's demonstrated how the vulnerabilities can be abused as a stepping stone to launch advanced attacks. In particular, the video shows how an adversary can take over an outdated Windows 7 machine inside a local network.

In all, 12 separate CVEs were issued for the flaws: three for the design flaws, four for vulnerabilities that "allow the trivial injection of plaintext frames in a protected Wi-Fi network", and five for other implementation bugs. The response to the flaws, which was coordinated by the Wi-Fi Alliance and the Industry Consortium for Advancement of Security on the Internet (ICASI), followed a somewhat different strategy in assigning the CVE numbers:

Although each affected codebase normally receives a unique CVE, the agreement between affected vendors was that, in this specific case, using the same CVE across different codebases would make communication easier. For instance, by tying one CVE to each vulnerability, a customer can now ask a vendor whether their product is affected by a specific CVE. Please note that this deviates from normal MITRE guidelines, and that this decision was made by affected vendors independently of MITRE, and that this in no way reflects any changes in how MITRE assigns CVEs.

Reading between the lines might indicate that MITRE and/or the CVE board were less than entirely pleased by that approach. Of late, the board has been rather protective of the CVE-issuance process. Balancing the needs of all of the disparate CVE users and consumers has been an ongoing problem, part of which we looked at in early April.

Meanwhile, the Linux networking developers, including Vanhoef, have come up with a patch set to address the vulnerabilities in the kernel. Some are being fixed in the mac80211 core, while others are being handled in the drivers. More fixes may be coming for other drivers and, potentially, the core as well. Beyond that, firmware updates are needed for some hardware; the firmware for some hardware has been updated to patch the vulnerabilities (silently, at least for Intel firmware).

FragAttacks is a whole passel of vulnerabilities, for sure, but it is a little unclear how serious of a problem they will pose in the real world. That should not lead one to neglect updating devices, however. Unfortunately, WiFi implementations are often deployed in equipment that sees little or no maintenance—if it can be maintained at all. That reason alone should lead to more scrutiny and testing of the security of both the standards and the implementations. But it seems likely we will see another batch or three of WiFi holes as time goes on.

---

(

Log in

to post comments)

from Hacker News https://ift.tt/3hHAHlH