BadUSB – now with Do-It-Yourself instructions

Back in August 2014, we wrote about BadUSB.

That was a paper about USB firmware hacking written by a pair of researchers from Germany and presented at the BlackHat 2014 conference.

Many firmware hacks, of course, are benign or even beneficial.

But the BadUSB paper wasn’t about how to unlock some hidden features in your latest digital camera.

And it didn’t look at the usefulness of getting rid of those bloatware apps your phone vendor decided to pack onto your latest handset.

Indeed, the full title makes the slant of the paper clear: BadUSB – On Accessories that Turn Evil.

If you’ve ever tried to tweak the firmware on your phone, even if it’s one of those Android devices that was deliberately made to be hackable, like Google’s own Nexus range, you’ll know that it’s unlikely to happen without you noticing.

And if you have a mobile device that the supplier, the vendor or the carrier has locked down “for your own convenience and safety” (or some other unstated reason), you’ll know that it can require a great deal of careful and deliberate effort to reflash it.

That’s after the jailbreakers or rooters have spent months to make the hack possible in the first place.

Reflashing the firmware

But as researchers Nohl and Lell pointed out, there are many devices where this sort of effort might be sidestepped.

Many, if not most, USB consumer devices, such as USB flash drives, can only interact with the outside world via their USB interface.

That includes not only formatting, writing and reading the data storage areas in regular use, but also writing out the firmware in the first place.

After all, even a humble USB stick needs some embedded software, or firmware, on it so that it can respond to the commands of the computers you plug it into.

That firmware is usually uploaded to the USB stick at the factory, before the device is shipped to the supplier.

The supplier might than write some data to the device, such as free software, instruction manuals, advertising materials or, sadly, malware.

Fortunately, on most operating systems at least, it’s possible to plug in a new USB device without activating any of the software stored on it, so you can scan it, wipe it or otherwise take control of it before using it in earnest.

→ That wasn’t always so easy. Microsoft Windows, at least, used to have a feature commonly known as AutoRun activated by default. Specially-named files would run automatically as soon as you inserted a USB device. After several years during which this was a major vehicle for malware activation, Microsoft finally capitulated and turned the feature off by default, at least for rewritable devices.

Two big deals

As Nohl and Lell discovered, the same isn’t true for the firmware part of many USB devices.

Very simply put, there are two big deals here:

1. The firmware on the USB device has to run when you plug it in, in order to make the device work. So you can’t turn the firmware off.
2. The firmware isn’t write-protected after a device is plugged in. So you can’t automatically trust it.

Catch 0x16! (That’s Catch 22 in hexadecimal.)

In theory, your PC could be infected with malware that would reflash any USB device you plugged in, so that when you used it to transfer data to another PC, the malware would go with it, invisibly to the recipient.

And in practice, as Noll and Lell reported in their paper, that really is possible, if you know what you are doing.

But Noll and Lell didn’t tell the world how to do it, figuring it would be irresponsible to release working proof-of-concept (PoC) code right away.

Most people would probably agree with their decision, which is why only showing people how to carry out a dangerous hack if you think they have a need to know and might actually be able to fix the problem, is generally known as responsible disclosure.

Full disclosure

That’s not good enough for everyone, of course, and the contrary approach of full disclosure involves telling and showing everyone at the same time, as a way of forcing the good guys not to sit on their hands doing nothing.

Full disclosure has now happened, with hackers named Adam Caudill and Brandon Wilson publishing PoC code for maliciously attacking USB flash firmware.

The PoC code was announced at a recent security conference in Kentucky, USA.

Solving the BadUSB problem

A common “solution” proposed to this problem – a “solution” apparently endorsed by Nohl himself – is to hard-wire USB devices so they will only accept firmware that is digitally signed by the original manufacturer.

In my opinion, that’s exactly the wrong way forward, because it leaves the devices “vendor locked” – a configuration on many mobile phones right now that consumers in the USA are fighting for the right to work around.

If only the manufacturer can issue firmware upgrades, then:

• No open source or other commercial alternatives are ever possible.
• You are entirely reliant on the manufacturer for updates. (As vendor-locked Android devices remind us, that can be a fruitless reliance.)
• If ever you think that the manufacturer’s private key has been compromised, you’re back where we started.
• You still aren’t safe against firmware updates to which you haven’t given consent, informed or otherwise.

An alternative solution

As I wrote last time this came up, I’m keen on a solution based on a hardware interlock, whether you choose to use digital signatures elsewhere in the process or not.

In short, a button or switch on the device needs pressing or toggling to permit firmware updates.

That way, there is a completely different physical workflow between plugging in the device to use it, and plugging in the device to update or reprogram it.

That’s my two cents’ worth.

Where do you sit on this issue?

Image of tangled USB leads courtesy of Shutterstock.