BadUSB: Clever but not novel

This article brought to you by LWN subscribers Subscribers to LWN.net made this article — and everything that surrounds it — possible. If you appreciate our content, please buy a subscription and make the next set of articles possible.

The annual Black Hat security conference often has eye-opening talks and demonstrations, but it also suffers from over-hyped presentations at times. The press coverage of this year's event was replete with references to the "BadUSB" talk that looked at the damage that can be caused by malicious USB devices. But, as discussions on the oss-security mailing list and elsewhere show, these ideas are not particularly new, nor especially surprising—at least to those who have been paying attention over the years.

The basic idea behind BadUSB is that USB devices have firmware that controls how they interact with the computers they get plugged into. If that firmware can be subverted—again, no real surprise that it can be—it can cause the USB device to do various surprising things: masquerade as a different kind of device (e.g. a storage device that acts like a keyboard), copy files, intercept file accesses to substitute malware, modify host network settings, and more. Changing the firmware of a USB device makes the device a persistent attack vector, but it is not just removable devices that are susceptible. Many systems, especially laptops, come with built-in USB devices (e.g. cameras). Infecting the firmware of those (which may not be as easy) would effectively persistently compromise the whole system.

But malicious USB devices are nothing new. In a Google+ post, Greg Kroah-Hartman pointed to the USB Rubber Ducky as an longstanding example of a programmable USB device that could used for malicious purposes. On the other side of the coin, Kees Cook used the Facedancer USB fuzzer to find lots of holes in the Linux USB stack (which have now been patched).

Whenever a USB device—a USB flash device, a phone for charging over USB, a mouse, or something more exotic—is plugged into a system, there is a fair amount of trust being placed in that device. If it claims to be an input device, the OS will treat it as such—even if it looks like a flash device to the user. That's part of where the problem lies; there are multiple types of USB devices that have different capabilities, but the type a device claims to be is not readily apparent from the outside. On the flip side, though, devices like the YubiKey can use that ability to do their job: presenting itself as a keyboard to input passwords.

Some of the attacks demonstrated and discussed at the Black Hat talk (slides [PDF], video [YouTube]) used the multi-function aspect of USB devices to inject commands as a keyboard or to redirect DNS queries when masquerading as network device (by replying to a DHCP request with the address of a malicious DNS server, but no default gateway, so traffic still routes over the existing network). The attacks presented are clever and, perhaps, not well-known, but they are hardly revolutionary—as some breathless articles might lead one to believe.

Dan Carpenter raised the issue on the oss-security mailing list, but the discussion there made it clear that there is nothing particularly new about BadUSB. In fact, Kroah-Hartman claimed:

In that thread, there were concerns about rewriting the firmware in the host controllers (the system hardware that handles USB communication), but no examples were offered (despite repeated requests). It is not just USB that suffers from these problems, however, as Dean Pierce (and others) pointed out; any bus or connector that allows hotplugging (e.g. Firewire, ExpressCard, Thunderbolt, even PCI) can have exactly the same issues. In fact, some of those hotpluggable devices can initiate direct memory access (DMA) operations, which leads to another whole level of attack possibilities.

But Pierce also wanted a way to disable USB hotplug, which is something that the Linux kernel has provided for a long time. As Kroah-Hartman noted, you can turn off USB hotplug, but "very few people take advantage of it". This command:

    echo "0" > /sys/module/usbcore/parameters/authorized_default

will turn off authorization for any USB devices that are plugged in, effectively disabling any malfeasance that BadUSB (or anything else) might attempt. In another message, he further explained the values for authorized_default beyond the 0 used above. The default -1 value means that all plugged-in USB devices are authorized, except for wireless network devices that must be explicitly authorized. The other possible value is 1, which authorizes all USB devices that are plugged in.

The only real benefit of all of the publicity around BadUSB (beyond Kroah-Hartman's tongue-in-cheek cost savings) is that it has raised the profile of this kind of attack. To those who are particularly security conscious or technically savvy, there may be nothing new here, but to many, including some with a lot of computer knowledge, BadUSB is surprising—even startling. So the publicity may lead to people being more careful with what devices they blithely plug into their systems.

It is pretty well established that allowing an attacker physical access to your system is not a path to happiness. In some sense, BadUSB just extends that idea further. Plugging random hardware into a system leaves you vulnerable to anything that hardware is capable of—whether you expect it or not.

Index entries for this article
Security	Firmware
Security	Hardware

---

(Log in to post comments)