Sophos Cloud Optix
Imagine if you had to throw away your USB devices after letting someone else use them.
That USB key with the PowerPoint file on it that you loaded onto the projector at a conference?
Bin it.
Your mouse, selflessly lent to a fellow traveller while you both were waiting at the airport?
Might as well leave it behind with the complimentary newspaper.
The cool new outdoor action camera you plugged into your friend’s laptop after a day of bike riding in the mountains?
Oh no! Not the cool new camera!
Well, according to a paper coming up at the BlackHat 2014 conference, that’s where we might be heading if we’re not careful.
Influential security researcher Karsten Nohl and his colleague Jakob Lell will be talking on the topic BadUSB – On Accessories that Turn Evil, dealing with the problem of whether to trust a USB device or not.
The problem with USB
Here’s a very coarse guide to the problem that Kohl and Lell will be digging into:
1. USB devices (e.g. data sticks, keyboards) contain a tiny computer and some firmware.
The firmware is essentially a special software program – a miniature operating system, if you like – that makes the device work.
The firmware operates at a low level; it is usually programmed into the device in the factory and often forgotten about thereafter.
2. You have to take it as an act of faith that a USB device has firmware that does what it’s supposed to.
For example, you assume that a USB data storage device doesn’t fiddle with your data when you read it back; you assume your keyboard doesn’t sneakily type in extra characters when you aren’t looking; and so on.
There isn’t a straightforward way to deal with issue (2).
But a bit of care will go a long way, for example by buying reputable brands, and sticking with products you trust.
Except for the fact that:
3. The firmware on many USB devices can be sneakily reprogrammed whenever the device is plugged into an untrusted computer.
The designers of budget USB devices generally don’t build in any safeguards to stop you changing the firmware without warning.
Oh dear!
So, in theory, even if you solve problem (2) by taking great care with your supply chain, you’re scuppered as soon as you plug your USB device into anyone else’s computer.
Malicious software on that computer could modify your USB firmware, and you’d be none the wiser.
And that would be a huge security risk.
Just imagine
Imagine a USB flash drive that deliberately alters the contents of previously-stored data sectors when you read them back in, but only the second time they are accessed.
So you’d write your backup files, read them back once for verification and they’d be fine.
But try to read them next month when you urgently need to restore your backup for real, and the files will be corrupted.
Or imagine a USB keyboard that turns, without warning, into a covert keylogger.
Or imagine a virus like Stuxnet that spreads via your mouse, not via a flash drive.
What to do?
Nohl and Lell will be giving us some ideas on how to mitigate the risks in their forthcoming talk.
And, as we’ve mentioned before, Naked Security writer Chester Wisniewski will be at BlackHat 2014, and I’m going to be linking up with him during the event to record a special episode of the Sophos Security Chet Chat podcast.
So I’ll be sure to ask him what he thinks we can do to mitigate this problem!
What I’d like to see, not just on USB devices but on all sorts of reflashable hardware components, is some sort of physical interlock for updates.
A simple switch or button that would electronically block firmware writes unless it were toggled or pressed would, in my opinion, help a great deal.
It wouldn’t stop an attacker from Trojanising one of your devices while your back was turned, but it would let you plug that cool new outdoor action camera into your friend’s laptop without fear.
Many other sorts of device use interlocks to improve safety and security: some motorycles, for instance, have sensors that cut the engine if you try to ride off with the sidestand down.
Why not a similar sort of accident-prevention interlock switch for reflashable computer devices?
Image of tangled USB leads courtesy of Shutterstock.
Any device must use firmware which is digitally signed by the manufacturer. Any firmware update must be rejected unless the digital signature is present.
No, no, no, 1000 times no 🙂
In many ways, that’s worse – it’s effectively the very sort of device lock that mobile phone users are fighting for the right to removed in the USA right now.
If only the manufacturer can issue firmware upgrades, then [a] no open source or other commercial alternatives are ever possible; [b] you are entirely reliant on the manufacturer for updates (and, as vendor-locked Android devices remind us, that can be a fruitless reliance); [c] if ever you think that the manufacturer’s private key has been compromised, you’re back where we started; and [d] it still doesn’t deal with the problem of firmware updates to which you haven’t given consent, informed or otherwise.
The UEFI firmware in my Windows netbook takes a nice middle ground: you can turn signature checking off, you can upload keys to authorise firmware signed by someone else, including yourself; and you can drop right back to old-school BIOS mode.
I’m still keen on a hardware interlock, digital signatures or not. That way, there is a completely different *physical* workflow between plugging in the device to use it, and plugging in the device to update it.
I have an old USB that has a physical switch on it to write protect it. I love it but can not find this feature on any current USB sticks. I use it to store virus fighting software. I hope it never dies.
There are not many out there, I think, but they do still make some USB flash drives with a physical write protection switch. I recently purchased one. The brand is Kanguru and the product is Flash Blu.
It is a really good idea, especially if you are going to use it in a relatively public computer.
ONLY if (unlike the worthless sdcard physical switch) it is actually ENFORCED by the Firmware / card reader / USB bus / software it connects-to. No-one mentioned it… still an issue in 2019.
It wouldn’t work in this case, since BadUSB is coded into the device’s firmware.
Given who invented USB keys, they are as trustworthy as any firmware, BIOS, dll driver for wireless. You should suspect everything, trust nothing and use anyway.
Remember “U3”? It wasn’t a successor band to U2, but a type of USB flash drive that deliberately circumvented “AutoRun” limitations by lying, and saying it was a CD-ROM drive as well as a USB device, so Windows would trust it.
You could reconfigure the firmware to turn this disreputable behaviour off…but not, it seems, to disable it indefinitely. So someone else could turn it back on later. And, while they were about it, secretly rewrite the contents of the fake CD-ROM drive (usually a small 6MB ISO image, contents…whatever you liked).
Fortunately the concept imploded and the devices aren’t sold any more.
If I recall right, U3 was a software platform, not technically controller-level firmware. Kinda Apples and Oranges, no?
Back in the last century the most common portable storage was the floppy disk. This was the source of much malware, and the solution was a little piece of plastic the prevented the computer from writing on the disk. So you could insert your disk into a strange floppy-drive with the “write-protect” tab, and feel safe. The motto was “practice safe computing–always use a write-protect tab”.
Now, a generation later, we have the same problem. Couldn’t we have a similar solution?
Amen, brother.
You do get (or used to get) some storage devices with write protect switches – I have an SD card with one – but: [a] the switch mechanism is terribly fiddly, to the point that you feel that something is going to give up the ghost when you try to use it (either the switch itself or your patience); [b] I have no idea whether it’s a genuine electronic interlock or just some kind of “advisory configuration flag” that can be ignored; [c] I have no idea whether the write-protection applies to the firmware storage area as well as the data, or is merely used by the firmware to control access to the data.
Need to consider the physical mechanism used to create a ‘write protect’ mode. On floppies of old there was a simple bit of plastic that could be moved into one of two possible positions. It didn’t actually do anything on the disc itself. When the disc was inserted into a drive, the ‘bit of plastic’ operated a simple switch to enable or disable the write feature.So if the little hardware switch in the drive failed, the position of the switch was ignored entirely and it either allowed writing or not, depending on how it had failed.
What is needed is a foolproof system on the disc itself that internally turns on or off the ability to write to the disc. But even that can physically fail – nothing is perfect!
Mikelis wrote “So you could insert your disk into a strange floppy-drive with the “write-protect” tab, and feel safe.”
Uhh, no. That’s fine if you are letting Joe copy one of your files from the diskette. It fails when you give Joe the diskette to add a file for you (because you have to disable the write-protect).
I think the OP’s point was that after write protecting a diskette, you had a good chance that it actually *was* protected against writes.
Certainly a malevolent “friend” could rig the write protect optics on his drive, but malware couldn’t write to a write-protected disk of its own accord. There was an interlock.
So you could, indeed, feel safe if the write protect tab was set.
Isn’t one of the obvious things that needs to be done to standardise all USB devices on a Free and Open Source firmware?
The best-laid schemes o’ mice an’ men
Gang aft agley,
An’ lea’e us nought but grief an’ pain,
For promis’d joy!
Open standards might work. But, then again, consider that the majority of mobile phones in the world right now are based on a free and open source core, namely, Android. Look how “free and open” that’s turned out – lots of handsets are firmware locked so only the vendor can update them. (And then they don’t.)
Having said that, I guess I know what you mean – something more like UEFI, where there is standardisation and flexibility, than the iPhone, where there is none at all.
Better than what we have now…
But why is it even possible to reprogram the driver firmware on a USB storage device??!
Well, the naive answer would be to think that the manufacturer deliberately left the ability to do so in order to be able to fix any possible bugs after production.
The likely answer though, is that once the initial firmware is written, nobody has given a single thought to whether or not it should be protected and how it could be protected.
Or, if you are a cynic, perhaps there was *exactly* a single thought give to how to protect the firmware on low-cost devices…and it went like this:
Q. Hey! Field updates to firmware are a handy feature, but perhaps we should protect them?
A. Perhaps we should. Next question?
@ Paul: I’m a cynic.
Remember the Seagate high-capacity hard drives which had a bug in their controller firmware? That’s why.
One addition to a switch on a Trusted USB device: Two-factor authentication, if the device is physically big enough to take a fingerprint or other biometric factor.
But, how can we retrofit existing USB devices to be resistant? I would hate to have to buy all new devices.
And how could someone test for BadUSB in an unsecured device? Is it even possible?
Thank you for the heads up
Wow!!! BadUSB!!!! Is this a scandal aimed at raising prices on USB Devices or part of the marketing plan for “Thunderbolt”? And don’t all components with plug ‘n play communicate with the OS? What about “machine to machine” (m2m)? I can see it now, head of lettuce logs into the net complaining about the fridge not being cold enough, but really the e. coli bacteria found in the lettuce came from the producer who programmed the embedded “RFID” chip in the packaging to blame it on the refrigerator!
This is far more theoretical — an improbable — than the author is painting it to be.
There are a half dozen popular USB controllers — dozens more that are less popular. Each have their own models. SMI, Chipsbank, Alcor, Buildwin, and so on.
They are paired with a HUGE variety of memory in a variety of configurations. Hynix, Samsung, Toshiba, Micron, and so on.
You need to have the proper controller programming tool for the chip, and the proper database of memory chips.
There is not some universal programming tool that would allow your computer to infect any USB inserted into it.
If this is true, it should alleviate a lot of fears. I’d like to wait to see what exactly the team did uncover with BadUSB before making such a far-reaching statement.
I do hope you are right.
The code is on GitHub.
There is code on Github, but it isn’t quite what the BadBIOS story described. I don’t think anyone doubted many of the individual technical tricks described in the BadBIOS story; but many quite reasonably wondered just how true the whole edifice was.
This isn’t the BadBIOS story.
Essentially, any USB device should now be considered untrusted, and that includes any computer to which a USB device of any kind has ever been connected. This hack is two-way, meaning if a computer has had a BadUSB-altered device plugged into it at any time, it can potentially alter the firmware of any future device that’s plugged into it. Especially untrustworthy are the computers of friends or business associates who may be unaware that their computers have been compromised. Lend someone a mouse and you could be infected. Buy a cheap Chinese keyboard from your favorite tech store and your computer may be infected. Recharge your phone on a public charger and you could be infected. BadUSB is a computer STD. Until USB devices are cryptographically signed, all USB should be considered dead and unusable.
Seriously? You think that the way to solve this is for every USB device to be locked down like a iPhone? Not only will that mean you have to take the manufacturer’s updates only, you’ll have to trust those updates blindly, and you’ll have to trust their code signing keys for the lifetime of the device.
All you really need is something that requires physical interaction with the device to flash the firmware – a switch or button would do the trick, just like “Press F to boot from Floppy” in the old days would have wiped out boot sector viruses.
How would that work, exactly? Since the device driver must communicate with the port in order to make a connection, where do you put the switch? If the switch disables the firmware, it disables the device.
I discovered a similar effect on some HP systems, that would reliably brick the system on boot if a particular el cheapo pendrive was inserted.
Never found out why and all the affected drives went back shortly thereafter, assume it was some sort of buffer overflow during early boot.