> 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.
A lot of this work has been research of Dina Katabi at MIT, via a function called the Sparse Fourier ("4-E-A") Transform.
I am not excusing the privacy implications, which will be abused to the extreme. However, it will be used also for health reasons, like monitoring respiration, and activity.
Anyone aware of a polished application that utilizes this for personal home monitoring? It'd be fantastic to integrate this with Home Assistant[1] in lieu of Zigbee motion sensors.
> "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.
> "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."
> 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.
Why does this feel like Spectre? We're trying to speed things up in a way that eventually blows back into our face.
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.
"""
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.
"""
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.
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:
if decrypt(encrypted) == false
{
memcpy(plaintext, encrypted); // lets try to use the encrypted data anyway, you never know!
}
handle_packet(plaintext);
WiFi has always been developed on being retro-compatible. The good side is you can use something from 2003 with AP from today (let's ditch the 5MHz and 10MHz bandwidth), the downside is you have a big stack of technical debt in most of the chipset out there, which might be why this kind of things happens.
Not having any access to the firmware source (thanks FCC) does not help at all.
Might shock you but the for-profit Wifi Alliance repeatedly ignores best practice advice and has the garbage they push out owned all the time. At this point I'm half convinced they are compromised, see no reason why they should be writing the standards anymore. People tell them what they are doing wrong constantly and they just ignore it and push ahead until someone breaks it exactly as predicted, rinse, repeat. This has been going on for years.
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.
Some vendors aren't going to care about this in the least and won't offer any updates.
Some will only fix this in new and future devices.
And perhaps some will update all their devices going back several years.
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.
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.
> 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.
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!
From my experience with TP-LINK software, you don't need to worry about this attack. The attack demonstrated is complex, requires physical proximity and a lot of knowledge about the target.
Meanwhile, your router will probably give any attacker root if they ask it nicely. TP-Link doesn't seem to care about device security at all if you're already paid for the device, so don't expect any updates and expect a whole range of vulnerabilities to be exploitable against your router.
Now, it must be said, TP-Link is no D-Link, a company that almost seems to add security problems to their software intentionally with their awful software quality, but if you're conscious about security, any consumer device will probably have a whole bunch of exploits that would work easier and more reliably.
EDIT: replaced the word "access" with "proximity" to avoid confusion.
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.
“ More technically, the impact of attacks can also be reduced by manually configuring your DNS server so that it cannot be poisoned. Specific to your Wi-Fi configuration, you can mitigate attacks (but not fully prevent them) by disabling fragmentation, disabling pairwise rekeys, and disabling dynamic fragmentation in Wi-Fi 6 (802.11ax) devices.”
So yes, but as you say lots of things can override your explicit DNS settings. Even browsers can do it these days.
Run WireGuard. Effectively treat WiFi as untrusted and VPN over it. Have WireGuard send over your DNS on the other side, and have that DNS use D-o-T or D-o-H depending on your threat model.
Use Ethernet on stationary devices, and WiFi on mobile devices.
Authenticating the remote end of the connection (which all decent software does because using it on other people's WiFi would be very unsafe otherwise) makes it irrelevant.
[+] [-] transpute|4 years ago|reply
> 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.
IEEE 802.11bf paper: https://arxiv.org/abs/2103.14918
Papers on device-free wireless sensing (DFWS): https://dhalperi.github.io/linux-80211n-csitool/
Remote sensing with low-cost ESP32 and 802.11n: https://academic.oup.com/jcde/article/7/5/644/5837600
[+] [-] andrepd|4 years ago|reply
Honestly I don't see any purely technical solution to this. At some point we have to demand that laws be written to outlaw this.
[+] [-] disabled|4 years ago|reply
I am not excusing the privacy implications, which will be abused to the extreme. However, it will be used also for health reasons, like monitoring respiration, and activity.
[+] [-] salawat|4 years ago|reply
What does everyone think is going to happen with capabilities like that?
[+] [-] beermonster|4 years ago|reply
Scary times.
[+] [-] mushufasa|4 years ago|reply
yes, yes it was https://www.youtube.com/watch?v=IRELLH86Edo
[+] [-] neolog|4 years ago|reply
[+] [-] KETpXDDzR|4 years ago|reply
[+] [-] xanth|4 years ago|reply
[1] https://www.home-assistant.io/
[+] [-] passerby1|4 years ago|reply
[+] [-] EricE|4 years ago|reply
[+] [-] BatteryMountain|4 years ago|reply
[+] [-] matheusmoreira|4 years ago|reply
[+] [-] jesusjosephsson|4 years ago|reply
[+] [-] miles|4 years ago|reply
> "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.
> "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."
[1] https://www.commscope.com/blog/2021/wi-fi-alliance-discloses...
[+] [-] pmlnr|4 years ago|reply
Why does this feel like Spectre? We're trying to speed things up in a way that eventually blows back into our face.
[+] [-] Reventlov|4 years ago|reply
[+] [-] riobard|4 years ago|reply
[+] [-] timwis|4 years ago|reply
[+] [-] doggodaddo78|4 years ago|reply
[+] [-] totetsu|4 years ago|reply
[+] [-] DanAtC|4 years ago|reply
[+] [-] DanAtC|4 years ago|reply
[+] [-] tptacek|4 years ago|reply
https://www.krackattacks.com/
[+] [-] motohagiography|4 years ago|reply
[+] [-] BelenusMordred|4 years ago|reply
[+] [-] SCHiM|4 years ago|reply
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.
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:
[+] [-] Reventlov|4 years ago|reply
Not having any access to the firmware source (thanks FCC) does not help at all.
[+] [-] BelenusMordred|4 years ago|reply
Might shock you but the for-profit Wifi Alliance repeatedly ignores best practice advice and has the garbage they push out owned all the time. At this point I'm half convinced they are compromised, see no reason why they should be writing the standards anymore. People tell them what they are doing wrong constantly and they just ignore it and push ahead until someone breaks it exactly as predicted, rinse, repeat. This has been going on for years.
[+] [-] johnklos|4 years ago|reply
Some vendors aren't going to care about this in the least and won't offer any updates.
Some will only fix this in new and future devices.
And perhaps some will update all their devices going back several years.
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.
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.
[+] [-] jakob223|4 years ago|reply
[+] [-] inetknght|4 years ago|reply
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!
[0]: https://news.ycombinator.com/item?id=26778236
[1]: https://static.usenix.org/events/woot11/tech/final_files/Goo...
[+] [-] lwhi|4 years ago|reply
How likely are large manufacturers likely to react to this?
[+] [-] beermonster|4 years ago|reply
[+] [-] 1over137|4 years ago|reply
Ruckus has updates out already: https://support.ruckuswireless.com/fragattacks-ruckus-techni...
[+] [-] crookshanked|4 years ago|reply
[+] [-] jeroenhd|4 years ago|reply
Meanwhile, your router will probably give any attacker root if they ask it nicely. TP-Link doesn't seem to care about device security at all if you're already paid for the device, so don't expect any updates and expect a whole range of vulnerabilities to be exploitable against your router.
Now, it must be said, TP-Link is no D-Link, a company that almost seems to add security problems to their software intentionally with their awful software quality, but if you're conscious about security, any consumer device will probably have a whole bunch of exploits that would work easier and more reliably.
EDIT: replaced the word "access" with "proximity" to avoid confusion.
[+] [-] Dah00n|4 years ago|reply
[+] [-] SavantIdiot|4 years ago|reply
[+] [-] Dah00n|4 years ago|reply
[+] [-] jtchang|4 years ago|reply
[+] [-] beermonster|4 years ago|reply
So yes, but as you say lots of things can override your explicit DNS settings. Even browsers can do it these days.
Run WireGuard. Effectively treat WiFi as untrusted and VPN over it. Have WireGuard send over your DNS on the other side, and have that DNS use D-o-T or D-o-H depending on your threat model.
Use Ethernet on stationary devices, and WiFi on mobile devices.
[+] [-] billpg|4 years ago|reply
[+] [-] Pick-A-Hill2019|4 years ago|reply
[+] [-] 1vuio0pswjnm7|4 years ago|reply
[+] [-] colinbr96|4 years ago|reply
[+] [-] swiley|4 years ago|reply
[+] [-] throwitaway12|4 years ago|reply
Do we even know at this point?
[+] [-] mdeck_|4 years ago|reply
[+] [-] btach|4 years ago|reply