For how useful USB thumb drives are for quickly toting around and copying files from one computer to another, they can be a bit of a security headache. Programs can be loaded on them with all kinds of malware; they can be obscured in some ways that are difficult to detect, and they can be set up to execute certain programs when they’re plugged in. The general wisdom is to simply avoid untrusted USB devices completely, but that sort of abstinence-only policy rarely works in the real world. If, for some reason, an untrusted USB device absolutely needs to be used, many of these security issues can be mitigated with this tool.
Built by [Novamostra], the device is simple on the surface: it’s a Raspberry Pi Pico mated to a 2-in-1 USB splitter cable. But with the USB Neutralizer software they have written loaded onto the Pico, it automatically destroys the ability of any connected USB thumb drive to load files. The program works by deleting the first and last 34 Logical Block Addressing (LBA) sectors on the drive immediately when it’s plugged in, without doing anything else. This effectively corrupts the drive bad enough to prevent malicious software in the partitions from doing anything, allowing the user to (relatively) safely put the USB drive into their computer and format it for re-use. The code for this tool is also open-source and reviewable on the project’s GitHub page.
Of course, this isn’t a perfect security solution for all USB attacks. It doesn’t erase or replace the firmware on the drive itself, and although firmware-level attacks are rare they’re not out of the question for all users, all the time. It also won’t prevent a malicious physical attack like this high-voltage one, and it may also not stop hidden or obscured partitions or devices programmed for storage and some other nefarious purpose simultaneously, like a USB HID. But still, this solves a great many of the problems associated with getting new drives from semi-untrustworthy sources, like retailers or friends whose computer skills we don’t fully trust.
It seems like the only attack it actually stops is (coincidentally?) an attack that’s irrelevant except to Windows users? No matter what information is on the ‘disk’, i don’t expect my linux machine to start executing from any device plugged into it… But they are certainly vulnerable to voltage spikes and nefarious HID devices.
This sort of attack vector reminds me how much of practical technology use is effectively stochastic. If i had a positive reason to mistrust a USB device, i would just throw it in the trash. But if for some reason i had a different goal, i would just use a burner laptop (possibly even disconnect its wifi). I have 2 or 3 laptops that could serve this role, and the odds of killing both of them with hostile USB devices is so low, i wouldn’t hesitate to risk them this way. But for the regular run-of-the-mill USB device of unknown prevenance (i.e., federated online marketplace), risking it on my daily driver laptop is a no-brainer. The worst experience i’ve had so far is a scanner that becomes unreliable on battery power (I guess its light-bar causes the USB to drop below 5V).
Ideally, i would be a little more precious with my main PC because that would be a little harder to recover if i killed it…but mostly it gets spared this sort of risk simply because it’s not physically at-hand when i’m doing something foolish.
But fundamentally i’m vulnerable to, say, a piece of cheap technology that functions as a trojan horse and only misbehaves when i’m not looking. What are the odds i’ll meet something like that in my lifespan? What are the odds i’ve already met something like that and not regretted it? Fundamentally it’s just like HDD failure…an unlikely event that i can partially mitigate with backups that allow me to recover more easily, rather than true prevention that makes failure impossible.
Many Linux desktops these days are set up to automount devices (even if autorun is not a thing), and I wouldn’t bet against there being some exciting exploitable bugs that can occur just by mounting a specially crafted filesystem image. It’s possible, though less likely, that there could be bugs that can be triggered just by reading a partition table or looking for lvm/md metadata automatically or whatever else might happen without human intervention.
I’d suggest the odds are approaching 1 on the going forward stuff even if you don’t expect to live that much longer. As the microprocessor needed to misbehave intentionally and still do the users expected job well enough too used to be comparatively expensive and physically larger and meaningfully more power hungry compared to the just does the job chip. Now they are quite likely the same darn price and maybe even entirely the same silicon just with different software. And the laser to remark the different chip as something that would be expected has become so cheap I’m thinking of trying to find space to add one to my tool pile too!
Which is worrying in itself, and gets worse now data mining personal details etc has become hugely more profitable or at least easier to get money out of – the incentive to be dodgy goes up and the cost of blanket attacks flooding the market with seemingly normal devices approaches nill… A problem we are all fairly likely to encounter soon I suspect, if we haven’t already – the problem is noticing it happened, and then knowing what to blame. As it would be rather easy to blame the social media platform, email provider, bank, government etc from not having your data secured, or your “AI agent” breaking the supposed rules etc etc.
Rather than a full featured laptop, I’d consider using the cheapest SBC I had available (Raspberry flavored or not) that runs some basic Linux in offline air-gapped mode.
Automount or not, attach it and dig around in the logs and devs-folders to see what it might be up to.
Worst-case (e.g. a HV-usbkiller device), all you’ve lost is the cheap-ish SBC. And if there’s reason to suspect such a thing, maybe it could be bench-tested by feeding it only +5V and Gnd in a lab test setup first, checking that it doesn’t go all Tazer-mode on you
Given the horrendously deleterious effect that it has on any USB drive plugged into it, is there any chance that the firmware could be retooled to operate as – effectively – a hardware write-blocker?
I’ve lost count of the number of devices that’ve been irreparably damaged by plugging them into a SATA/IDE/CF/whatever USB device that’s then plugged into a Windows machine. Make no mistake, there’s a very good chance that Windows will overwrite the first 512-ish bytes of your media before it even asks you what to do with it.
Look no further than the Philips B.O. “Videosynthesizer” prototype for what would eventually become the CD-i. I told the owner over and over again to not plug it into a Windows machine. It ended up falling on the shoulders of CD-i Fan, a super-knowledgable person regarding OS-9/68k, to manually rebuild those first 512 bytes, as apparently they contain some critical data regarding the operating system.
I understand that this hack is something of a gag, but from a broader perspective, please don’t think that just because you aren’t using this device that your data is safe.
I’m with the others on this one. Even on Windows, I don’t believe files are arbitrarily executed on insertion of a drive (at least since Windows realized that was incredibly exploitable in the XP days).
I think the much greater concern are devices that have microprocessors that allow them to either suddenly act as a HID (or other device) when not being watched or one that could maybe scan and maliciously alter files (like swapping an trusted exe out) to find its way in.
So what would be more useful would be a relay device that can strip the ability of a device to act as something other than mass storage which I believe is currently the most exploited path.
The other vulnerability that I mentioned would require some known good memory to check against making it much harder to block.