I found some design and implementation flaws in Wi-Fi again. All Wi-Fi devices are affected. It was a long ~9 months embargo, over this time a lot of info has been collected and that info now available at fragattacks.com
Interview with SecureW2, where we look back on various Wi-Fi attacks and give network security advice to handle future attacks, especially in the age of AI securew2.com/signal/sneakin…
tl;dr: ensure a layered defense
This refers to repeatedly connecting using different passwords & optimizing the speed of connection attempts
What's most interesting is that models can now do this kind of engineering. A while ago, they even struggled to answer details about the different types of WiFi frames
Yesterday night I left Kimi K3 with a monitor WiFi interface and root access. This morning I woke up to a new way to bruteforce WEP, WPA2-PSK and WPA3-SAE even if the card does not send ACKs in monitor mode. And found that WPA3 is much faster to bruteforce than WPA2 :D
Interesting realization: any bash script can get your geolocation.
Here done using Wi-Fi trilateration on macOS by spawning a chrome browser.
I would assume the same thing is possible on Linux, probably even without spawning a browser.
1/
WHEREAMI: Built a Chrome-based geolocation red team tool (bash script😅).
whoami tells you who. whereami tells you where.
Living-Off-the-Land (#LOLbins), no new binaries, no permissions prompts.
Relevant for proximity based attacks, e.g. @Volexity's nearest neighbor
Vulnerabilities not being exploitable in a common configuration also happens often when I audit network code during research. The effort to report them, or describe them in a paper, was often not worth it. So these ‘vulnerabilities’ typically remained unpatched.
We’ve now seen at least four nginx RCEs that require non-default configs: nginx rift, nginx poolslip, and two of our own (including the one in the last tweet).
The configs involved are unusual, which raises the obvious question: do these attacks actually work in real-world