Security research blog from SensePost, a South African security firm, covering penetration testing, reverse engineering, and tool write-ups.
HN commenters link it for specific write-ups such as Android multi-user profiles and USB attack devices, and one cites an old post on infosec blogging.
When you turn your WiFi on, you can be tracked and attacked very easily. This is been known for a while, though not widely enough.
If at one time you connected to an open network, your devices continues to scan for that network. I can spoof that network, you connect to it, and then I intercept all traffic. A full framework has been created for this, complete with the ability to fingerprint your browser/OS and send exploits to your device [1]. Even if you only connect to password protected networks, it's possible (without access to the real AP) to let your clients send parts of the EAPOL handshake, and then perform a bruteforce attack. Weak passwords are cracked, meaning I can again intercept all traffic and possibly exploit your device.
So you only connect to one single network, strong password. Good. I can still track your MAC address. Even with one single device I can estimate the distance and the angle of your signal [2]. Hence I know your location, at all times. So you prevent MAC address tracking by using an identifier-free link layer protocol [3] (this doesn't exist in practice, only researchers made a demo showing its possible). Though a lot better, even with such a system it's possible to track the movement of devices purely based on the fingerprint of the physical WiFi signal [4]. Given sufficient location data it's likely to again (automatically) de-anonimize the dataset and track your movements (it's more complicated, yes, but still possible).
[1]…
WiFi probes are indeed a huge information/privacy leak. I'm guessing a lot of this has to do with the fact that WiFi was not designed from the beginning with security in mind.
Simply using something like Kismet[0] yields a lot of information, even before any rigorous analysis is done. You'll see some probe requests with huge lists of SSIDs. Some of those SSIDs are comprised of an address (presumably a home address), others are obviously office/work SSIDs and still others are public ones. (Starbucks, etc.) From this you can infer a device's movement and thus likely a person's. This is all from a superficial analysis.
Others have done much more research into large-scale collection and analysis of WiFi probes. The information you can collect is immense. See Snoopy[1] and this research paper entitled, "Signals from the Crowd: Uncovering Social Relationships through Smartphone Probes". [2]
Some of these use a SSID-to-geolocation database to assign a physical location to specific SSIDs. WiGLE is an example.[3] Google, Apple, et al. maintain their own databases that are likely more accurate, used to provide geolocation services to mobile users.
0. https://www.kismetwireless.net/
1. http://www.sensepost.com/blog/7557.html
2. http://conferences.sigcomm.org/imc/2013/papers/imc148-barberaSP106.pdf
3. https://wigle.net/
Scrolling through their incident feed, it seems to be a bit more frequent than "extremely rare".
Remember that critical industry is a sector where patching software is viewed as risky, because changing anything when it works is seen as unnecessary, and would often have weeks or months of pre-deployment testing. They work on a different time-base to the IT world.
The ability to do a "bypass" is nice in theory, but the need for this option will resonate with the "old guard", who will be able to use this external dependency to keep it out.
Personally I prefer smartcard-based solutions for MFA, since you can do all verification offline without requiring any third party to inject themselves into the chain. I found a good example of a vulnerability this year in Duo that just shows their validation logic is complex enough that one user was able to pass 2FA as another user [1].
That's probably your second worst case scenario, with the worst being an outsider being able to pass 2FA. A well-implemented smartcard scheme shouldn't fail in this way, as you're distributing validation logic to each device, rather than centralising it and relying on a "trusted outsider" to give a "yes or no".
[1] https://sensepost.com/blog/2021/duo-two-factor-authentication-bypass/
I wrote this about 13 years ago (a little tongue in cheek) but it held up:
https://sensepost.com/blog/2009/twitter-killed-the-infosec-blogging-star/
-snip-
There’s something liberating about saying “here’s a link”, as opposed to taking the time to formulate your thoughts into a full blown posting.
We were curious if this twitter-effect was real, imaginary or only applicable to lazy people like us.. Thanks to python-twitter and a few lines of script we can look at the the blogging habits of some info-sec superstars (and maybe confuse correlation and causation to jump to conclusions while we at it).
-snip-
It was moved out in Vista with great fanfare. A side effect was GDI was no longer hardware accelerated. With windows 7 and later hardware acceleration was added back necessitating parts of it return to the kernel. For obvious reasons this wasn't as widely publicized.
This makes exploits like this possible: https://sensepost.com/blog/2017/abusing-gdi-objects-for-ring0-primitives-revolution/
You might be able to build something like that in serverless, if you wanted to: https://blog.cloudflare.com/introducing-websockets-in-workers/ (and updated keep-open pricing in https://blog.cloudflare.com/workers-pricing-scale-to-zero/)
Or here's a writeup about writing a proxy in Node: https://sensepost.com/blog/2015/another-intercepting-proxy/