BadUSB: Clever but not novel
Did you know...? LWN.net is a subscriber-supported publication; we rely on subscribers to keep the entire operation going. Please help out by buying a subscription and keeping LWN on the net. |
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_defaultwill 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)
BadUSB: Clever but not novel
Posted Aug 14, 2014 7:57 UTC (Thu) by job (guest, #670) [Link]
BadUSB: Clever but not novel
Posted Aug 14, 2014 18:32 UTC (Thu) by droundy (subscriber, #4559) [Link]
David
BadUSB: Clever but not novel
Posted Aug 15, 2014 3:30 UTC (Fri) by mjthayer (guest, #39183) [Link]
BadUSB: Clever but not novel
Posted Aug 16, 2014 5:38 UTC (Sat) by dlang (guest, #313) [Link]
just make the kernel unconditionally log "the device you just plugged in can be compromised" and you will get just as good a result as trying to maintain a blacklist.
BadUSB: Clever but not novel
Posted Aug 16, 2014 6:23 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
BadUSB: Clever but not novel
Posted Aug 16, 2014 5:39 UTC (Sat) by dlang (guest, #313) [Link]
USB is just the latest to be publicized.
BadUSB: Clever but not novel
Posted Aug 16, 2014 8:50 UTC (Sat) by mjg59 (subscriber, #23239) [Link]
BadUSB: Clever but not novel
Posted Aug 19, 2014 19:35 UTC (Tue) by Baylink (guest, #755) [Link]
1) I unplug my external HDD from my own machine
2) I plug it into someone else's infected machine, which reprograms its USB drive adapter without my knowledge
3) I do my work there
4) I unplug it from their machine
5) I plug it back into my own
6) ATTACK
Everyone seems to be sloughing this off as a Won't Happen If You Do Smart Things case, but I'm not at all sure that's true.
The issue *I* wanted to hear more about is "how wide is the universe of USB device adapters which actually *can* be reprogrammed?" (Ones on which, say, a fuse is not blown forbidding reprogramming)
BadUSB: Clever but not novel
Posted Aug 19, 2014 21:11 UTC (Tue) by dlang (guest, #313) [Link]
BadUSB: Clever but not novel
Posted Aug 20, 2014 7:32 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
BadUSB: Clever but not novel
Posted Aug 20, 2014 21:32 UTC (Wed) by dlang (guest, #313) [Link]
BadUSB: Clever but not novel
Posted Aug 21, 2014 11:48 UTC (Thu) by mathstuf (subscriber, #69389) [Link]
BadUSB: Clever but not novel
Posted Aug 21, 2014 15:24 UTC (Thu) by raven667 (subscriber, #5198) [Link]
Is this what you were thinking of. I bookmarked it because it is so obscure I was concerned it would be never found again
BadUSB: Clever but not novel
Posted Aug 21, 2014 17:55 UTC (Thu) by mathstuf (subscriber, #69389) [Link]