BadUSB isn't always BadUSB

Since Karsten Nohl and his colleagues from SRLabs has presented the attack he named “BadUSB” back in July 2014, I’ve seen some media reports about those attacks in the wild. But do they actually implement the attack that SRLabs demonstrated?

There have been dedicated USB programmable ‘keyboards’ in the form factor of a thumb drive on the market years before the BadUSB attack was presented by SRLabs. The novel thing that they presented was that regular USB mass-storage devices with an 8051 microcontroller could be reprgrammed to act like an USB human interface device. But is this actually useful for an attacker when the attack happens with a USB device that the victim hasn’t seen before? Malicious people or red-teamers can buy USB devices with a more convienient ARM Cortex M0 or ATmega and program that with their preferred keystrokes. The media calling these style of attacks “BadUSB” is a misuse of the name that SRLabs came up with, since this kind of attack predates their research. The dedicated versions are comparable to real USB thumbdrives in terms of price and are easier to program with standard toolchains like the Arduino IDE for example. It doesn’t make much sense to use a real USB mass-storage device.

In this article which was republished in a ZDNet article titled “Rare BadUSB attack detected in the wild against US hospitality provider”, a picture of the thumb drive is shown. In the advertisement, it shows that it contains an ATMega32U4.

The attack by SRLabs is actually hacking the USB devices to let them do a thing they were not intended to do. The devices that are designed for this are much less clever in comparison, since programming a USB HID in a microcontroller is a common use case for these chips. Not to discourage anyone from building them yourself, it’s surely a cool project!

BadUSB cannot be patched in current hardware. But the development of a dangerous worm is unlikely for multiple reasons:

The danger of the actual BadUSB attack is less than the infections through devices built specifically for that purpose, which are already quite rare. This doesn’t mean that USB devices shouldn’t be fixed. I think that the fix suggested by SRLabs is still the best one: disable firmware updates. I think that this works best for the most dumb devices like mass-storage, but more complex USB devices can implement signatures, so security vulnerabilities can be updated with tools like fwupd.

Closing note: do threat modeling. Whitelisting USB devices is very likely not worth the effort of protecting against this specific attack. Should red-teaming use this kind of attack if the company will continue to trust keyboards by default? I don’t think doing such a test is helpful that way.