Future Wi-Fi devices will be able to see through your home and business walls, for activity monitoring and biometric identification, <a href="https://www.theregister.com/2021/03/31/wifi_devices_monitoring/" rel="nofollow">https://www.theregister.com/2021/03/31/wifi_devices_monitori...</a><p><i>> In three years or so, the Wi-Fi specification is scheduled to get an upgrade that will turn wireless devices into sensors capable of gathering data about the people and objects bathed in their signals... When 802.11bf will be finalized and introduced as an IEEE standard in September 2024, Wi-Fi will cease to be a communication-only standard and will legitimately become a full-fledged sensing paradigm... tracking can be done surreptitiously because Wi-Fi signals can penetrate walls, don't require light, and don't offer any visible indicator of their presence.</i><p>IEEE 802.11bf paper: <a href="https://arxiv.org/abs/2103.14918" rel="nofollow">https://arxiv.org/abs/2103.14918</a><p>Papers on device-free wireless sensing (DFWS): <a href="https://dhalperi.github.io/linux-80211n-csitool/" rel="nofollow">https://dhalperi.github.io/linux-80211n-csitool/</a><p>Remote sensing with low-cost ESP32 and 802.11n: <a href="https://academic.oup.com/jcde/article/7/5/644/5837600" rel="nofollow">https://academic.oup.com/jcde/article/7/5/644/5837600</a>
From the industry response[1]:<p>> "It’s important to note that there is presently no evidence of the vulnerabilities being used against Wi-Fi users maliciously and these issues are mitigated through routine device updates once updated firmware becomes available.<p>> "Like many previous vulnerabilities, FragAttacks has been academically well-researched and responsibly reported in a manner allowing the industry to proactively prepare and begin to roll out updates that fully eliminate the vulnerabilities. This set of vulnerabilities requires a potential attacker to be physically within range of the Wi-Fi network (or user device) in order to exploit it. This significantly reduces the likelihood of actual exploitation or attack."<p>[1] <a href="https://www.commscope.com/blog/2021/wi-fi-alliance-discloses-fragattacks/" rel="nofollow">https://www.commscope.com/blog/2021/wi-fi-alliance-discloses...</a>
> 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. When using Wi-Fi 6, which is based on the 802.11ax standard, a device may dynamically fragment frames to fill up available airtime.<p>Why does this feel like Spectre? We're trying to speed things up in a way that eventually blows back into our face.
Mathy strikes again ! This has been fixed in Linux and certain firmware / driver already: <a href="https://lore.kernel.org/linux-wireless/20210511180259.159598-1-johannes@sipsolutions.net/" rel="nofollow">https://lore.kernel.org/linux-wireless/20210511180259.159598...</a>
By now it's probably easier in mind to treat any Wi-Fi as Open Network and always use something like WireGuard/Tailscale for secure communication between devices.
From the researcher that brought you KRACK:<p><a href="https://www.krackattacks.com/" rel="nofollow">https://www.krackattacks.com/</a>
"""
How can the adversary construct unencrypted Wi-Fi frames so they are accepted by a vulnerable device? First, certain Wi-Fi devices accept any unencrypted frame even when connected to a protected Wi-Fi network.
"""<p>This actually made me angry. How fucking long are we doing this already? This is so. basic. Why is this possible? This should incur liability, we know the IT environment is adversarial.<p>I understand one can make technical mistakes, or shoot oneself in the foot in low level languages that are difficult to handle correctly. But this is a conceptual mistake, involving crypto! How can you possibly have written this code for an issue like this to occur? What is the control flow that leads to this? I almost cannot imagine how someone could code this up by accident, this must be a backdoor. Just imagine:<p><pre><code> if decrypt(encrypted) == false
{
memcpy(plaintext, encrypted); // lets try to use the encrypted data anyway, you never know!
}
handle_packet(plaintext);</code></pre>
I think this will make for an excellent litmus test for companies that make wifi products. Is this a critical fix? No. Is it important, if not critical? Yes.<p>Some vendors aren't going to care about this in the least and won't offer any updates.<p>Some will only fix this in new and future devices.<p>And perhaps some will update all their devices going back several years.<p>Currently I buy used 802.11ac Airport Extremes for wireless for people because they're simple, they stay out of the way, and the last time there was a major update, Apple updated every Airport model all the way back to the Airport Express from 2008.<p>But I want to be able to buy new wifi devices, and how vendors handle this will inform me about which ones I'll buy going forward.
> <i>certain devices accept plaintext aggregated frames that look like handshake messages. An adversary can exploit this by sending an aggregated frame whose starts resembles a handshake message and whose second subframe contains the packet that the adversary wants to inject.</i><p>That reminds me of a thread [0] that came up a month ago mentioning discussion of packets in packets [1]. That paper was from 2011!<p>[0]: <a href="https://news.ycombinator.com/item?id=26778236" rel="nofollow">https://news.ycombinator.com/item?id=26778236</a><p>[1]: <a href="https://static.usenix.org/events/woot11/tech/final_files/Goodspeed.pdf" rel="nofollow">https://static.usenix.org/events/woot11/tech/final_files/Goo...</a>
Fragmentation is usually disabled in home APs. I've played with it on hostapd, but didn't find a performance improvement, and investigating withe WireShark found even 64k packets were not being fragmented. Is the same true for enterprise AP?
I wonder if hardcoding your DNS servers will help. I guess sometimes this is not possible because in corporate environments DNS servers are sent via DHCP.
I would really like to know, if someone could, the definitive answer to if using a VPN would prevent the malicious packet?<p>Do we even know at this point?
I've always felt an always listening radio, especially the ones in televisions that try to connect to anything it can, in any device is a big gaping security hole. We've already seen how Bluetooth makes things vulnerable. If you're truly worried about security, go with the cable.