FragAttacks: vulnerabilities that affect Wi-Fi devices
Security researcher Mathy Vanhoef discovered several security vulnerabilities that affect most Wi-Fi devices. The collection of attacks, called FragAttacks, which stands for fragmentation and aggregation attacks, requires that that attacker is within range of the wireless network.
Three of the discovered vulnerabilities are "design flaws in the Wi-Fi standard" according to Vanhoef, and therefore affecting most Wi-Fi devices. Additional vulnerabilities were discovered during the research that were made possible by "widespread programming mistakes in Wi-Fi products".
The vulnerabilities affect all security protocols of the Wi-Fi standard, including the latest WPA3 specification but also WPA2 and WPE.
The researcher notes that the programming mistakes are the biggest concern because of their exploitability. The vulnerability was disclosed to the Wi-Fi Alliance and ICASI, and manufacturers of Wi-Fi devices had nine month time to create security updates for their devices to protect customers from potential attacks.
Devices should be updated if manufacturers have released updates that address the issues. Some issues can be mitigated using HTTPS.
Vanhoef published a video on YouTube in which he demonstrates attacks that exploit the Wi-Fi implementation flaws.
The following vulnerabilities have been disclosed:
Plaintext injection vulnerabilities
An attacker can construct unencrypted Wi-Fi frames that are accepted by target Wi-fi devices. Some wireless devices accept these frames automatically, others may accept plaintext aggregated frames if they "look like handshake messages"
This can for instance be abused to intercept a client's traffic by tricking the client into using a malicious DNS server as shown in the demo (the intercepted traffic may have another layer of protection though). Against routers this can also be abused to bypass the NAT/firewall, allowing the adversary to subsequently attack devices in the local Wi-Fi network (e.g. attacking an outdated Windows 7 machine as shown in the demo).
Design flaw: aggregation attack
The "is aggregated" flag is not authenticated, which means that it can be modified by attackers.
An adversary can abuse this to inject arbitrary network packets by tricking the victim into connecting to their server and then setting the "is aggregated" flag of carefully selected packets. Practically all tested devices were vulnerable to this attack. The ability to inject packets can in turn be abused to intercept a victimâ€™s traffic by making it use a malicious DNS server (see the demo).
Design flaw: mixed key attack
Frame Fragmentation was designed to improve the reliability of Wifi connections by splitting large frames into smaller ones. Problem is, that receivers are not required to check if the fragments have been encrypted using the same key, and that means that fragments that were decrypted using different keys may be reassembled.
This design flaw can be fixed in a backwards-compatible manner by only reassembling fragments that were decrypted using the same key. Because the attack is only possible under rare conditions it is considered a theoretical attack.
Design flaw: fragment cache attack
Another flaw in Wi-Fi's frame fragmentation feature. Wi-Fi devices are not required to remove non-reassembled fragments from memory when a client disconnects. The attack injects a malicious fragment in the memory of the access point so that the injected fragment of the attacker and the fragmented frame of the client will be reassembled on reconnect.
If the victim sends fragmented frames, which appears uncommon in practice, this can be abused to exfiltrate data.
Here is the full list of CVE identifiers:
- CVE-2020-24588: aggregation attack (accepting non-SPP A-MSDU frames).
- CVE-2020-24587: mixed key attack (reassembling fragments encrypted under different keys).
- CVE-2020-24586: fragment cache attack (not clearing fragments from memory when (re)connecting to a network).
- CVE-2020-26145: Accepting plaintext broadcast fragments as full frames (in an encrypted network).
- CVE-2020-26144: Accepting plaintext A-MSDU frames that start with an RFC1042 header with EtherType EAPOL (in an encrypted network).
- CVE-2020-26140: Accepting plaintext data frames in a protected network.
- CVE-2020-26143: Accepting fragmented plaintext data frames in a protected network.
- CVE-2020-26139: Forwarding EAPOL frames even though the sender is not yet authenticated (should only affect APs).
- CVE-2020-26146: Reassembling encrypted fragments with non-consecutive packet numbers.
- CVE-2020-26147: Reassembling mixed encrypted/plaintext fragments.
- CVE-2020-26142: Processing fragmented frames as full frames.
- CVE-2020-26141: Not verifying the TKIP MIC of fragmented frames.
A research paper is available with additional details.
YOUR HOME PAGE IS ABSOLUTELY HORRIBLE!!!
Use the following to get back the old landing page:
Thanks. Also, I like this landing page, as it filters out Ashwin:
After reviewing the demo video, it is clear that this vulnerability is not as serious as the KRACK vulnerability of 2017.
The main exploit implementation hinges upon the victim connecting to a malicious server, which is done by (surprise surprise) tricking the user into opening a malicious email. The email contains an invisible image which when accessed triggers the malicious server to send a tcp packet instead of an image thereby hijacking that browsing session’s DNS requests. The victim can then be redirected to a fake site which will steal login credentials and the like. There are several ways this can be mitigated:
1. The user doesn’t open suspicious emails. The attack fails.
2. The user has auto image loading disabled. The attack fails.
3. The user opens the email, but then closes the browser and relaunches it later. The attack came close, but still fails.
4. The user uses a browser with a sensible address bar design which makes it extremely obvious when connecting to a spoofed address (including punycode address spoofing) such as Pale Moon and therefore notices something is wrong. The attack fails and the user is now on high alert.
While this is still a wifi design flaw, it is mostly a PEBKAC issue.
As for the exploit implementation which hijacks older Windows systems, this is technically less of an operating system vulnerability and more of an RDP vulnerability, specifically the “BlueKeep” vulnerability. This can be mitigated by:
1. Using literally any other remote desktop solution aside from RDP. Seriously, disable RDP.
If Flash was Adobe’s gaping security hole, then RDP is Microsoft’s security hole (now that IE is dead). It’s mind boggling how many security issues can be completely ignored by disabling RDP.
2. Using a decent firewall, like Comodo Firewall. Ignoring Windows built-in firewall, basically any firewall worth using will block unknown connections by default, especially incoming connections from an unused port.
And for the implementation that hijacks a power socket, all I can say is IoT / “smart” devices are really dumb. If you want your light bulbs, power sockets, thermostats, and doorbells connected to wifi, you do you.
> 2. Using a decent firewall, like Comodo Firewall. Ignoring Windows built-in firewall, basically any firewall worth using will block unknown connections by default, especially incoming connections from an unused port.
This is bs. Windows firewall is ok. Default settings are bad, but not worth installing known malware as Comodo product.
Windows Firewall is functional yes, but it clearly wasn’t designed for ease of configuration. It’s also not good at inspecting packets with granularity, particularly from outgoing traffic. But for most things it’ll do. However any user knowledgeable enough to fully configure Windows Firewall for optimal security would likely be unaffected by crude wifi exploits in the first place.
Also, while I dislike Comodo’s internet security suite / antivirus, their firewall is still the best third-party firewall available for Windows, and I’ve been using it for over 13 years now. Comodo basically started out as a firewall company. In the beginning there was just Comodo Firewall, which was and always has been, free. Then they started branching out to other projects like an antivirus, then a full-blown security suite, then their own Chromium-based browser, all of them pretty bad. They should’ve just stuck with the firewall, but I guess businesses need to try new things.
While they insist on bundling everything through an online installer it is still possible to install just the firewall by itself. There’s a link to an offline installer on their forum. During install you need to uncheck the antivirus component and you’re set:
(The installer is under “Offline Setup Details”)
so – disable wifi????
If you’re concerned about tech security, the best option is not to have any tech, though you’d also have to install a firewall in your brain because it can also be hacked, its called social engineering.
Not to worry, all the brain washing everyone has been subjected by everyone and their mothers on behalf of your insert-corp-name-here all your life will be unaffected, They wouldn’t want to ruin a obedient consumer that is not capable of critical thinking.
And, like a magic trick while you are looking at the left hand, your future has been robbed from you with the right hand.
Not using Wi-Fi removes a huge attack vector. I don’t use Wi-Fi and thus never have to worry about it.
WiFi security bugs is one of the reasons why I always make sure any laptop I buy has a RJ45 port for a ethernet cable.
Other problems caused by having no RJ45 port is the lower speed, and needing to ask people who you are helping with their computer problems for their WiFi passwords when you bring your laptop and need internet access.
Another problem is WiFi not working on Linux, because the driver maintainer has not yet updated the driver to work with a new kernel.
So it is a shame that more and more laptops no longer have a RJ45 port, even some big 17 inch laptops.
Yep really annoying that the trend is for the ethernet port to be removed.
It seems to me that laptops are now commonly used as home computers, so if anything the ‘need’ for an ethernet port would be increasing rather than decreasing.
Of course you can buy an adapter, but unnecessary expensive.
> Of course you can buy an adapter, but unnecessary expensive.
Those adapters are cheap. Buying a laptop that supports RJ45 port is the unnecessary expensive option.
Serious, yes, but so much information was left out:
“Fortunately, the design flaws are hard to abuse because doing so requires user interaction or is only possible when using uncommon network settings.”
“The design issues are, on their own, tedious to exploit in practice.”
“By default devices don’t send fragmented frames. This means that the mixed key attack and the fragment cache attack, on their own, will be hard to exploit in practice, unless Wi-Fi 6 is used.”
“Can fragmentation attacks be preventing by disallowing small delays between fragments?
This would make exploiting possible vulnerabilities harder and perhaps in some cases practically infeasible.”
“‘There is no evidence of the vulnerabilities being used against Wi-Fi users maliciously, and these issues are mitigated through routine device updates that enable detection of suspect transmissions or improve adherence to recommended security implementation practices,'” the Wi-Fi Alliance said.”
“Vanhoef recommends accessing sites via secure HTTPS connections.”
The time, tedium, and expertise needed to attack one AP would all but guarantee failure for 99.9% of attempted, malicious attacks.
I found the information about the “smart homes” vulnerabilities much more serious.
Anyone use the tools to check their Wi-Fi?
Hmm… think I ran into this last weekend on a friends system with an unknown connection using a MAC addy that was mine but the device didn’t match. :\
NetGear has a decent “workaround” explanation, which is probably applicable, at https://kb.netgear.com/000063666/Security-Advisory-for-Fragment-and-Forge-vulnerabilities-on-some-WiFi-capable-devices-PSV-2021-0014-PSV-2021-0080 although this not may cover the entirety of the listed CVE’s.
I kind of agree with the comments above stating that there is some requirement for the attacks to not fail. However, this is today, this is what this guy discovered. If I have to bet, some other guy gal or alien (if you think you are one) will find a better simpler way. I go even further and make a sustantial bet that giving the path we are walking these days regarding CPU side channel attacks, WiFI issues like these, DSP vulnerabilities like the ones in Snapdragon SoCs, etc., we are doomed if we do not stop and start building things from scratch with security in mind. Most of what have been done in software and hardware until now is pretty flawed. We need hardware redesigns, and developing software with at least memory safe programming languages. Just as the first step.
We need competent programmers, not some memory mumbo-jumbo. Do it right or shut up.
We need companies that focus on quality, rather that profit and time-to-market. And we need consumers who would be willing to buy these high quality product that would be much more expensive.
Another security fud salesman like fart et al.
If you got hacked, you are just stupid.
Maybe you should read this https://www.abetterinternet.org/docs/memory-safety/