When creators of the state-sponsored Stuxnet worm used a USB stick to infect air-gapped computers inside Iran's heavily fortified Natanz nuclear facility, trust in the ubiquitous storage medium suffered a devastating blow. Now, white-hat hackers have devised a feat even more seminal—an exploit that transforms keyboards, Web cams, and other types of USB-connected devices into highly programmable attack platforms that can't be detected by today's defenses.

Dubbed BadUSB, the hack reprograms embedded firmware to give USB devices new, covert capabilities. In a demonstration scheduled at next week's Black Hat security conference in Las Vegas, a USB drive, for instance, will take on the ability to act as a keyboard that surreptitiously types malicious commands into attached computers. A different drive will similarly be reprogrammed to act as a network card that causes connected computers to connect to malicious sites impersonating Google, Facebook or other trusted destinations. The presenters will demonstrate similar hacks that work against Android phones when attached to targeted computers. They say their technique will work on Web cams, keyboards, and most other types of USB-enabled devices.

"Please don't do anything evil"

"If you put anything into your USB [slot], it extends a lot of trust," Karsten Nohl, chief scientist at Security Research Labs in Berlin, told Ars. "Whatever it is, there could always be some code running in that device that runs maliciously. Every time anybody connects a USB device to your computer, you fully trust them with your computer. It's the equivalent of [saying] 'here's my computer; I'm going to walk away for 10 minutes. Please don't do anything evil."

In many respects, the BadUSB hack is more pernicious than simply loading a USB stick with the kind of self-propagating malware used in the Stuxnet attack. For one thing, although the Black Hat demos feature only USB2 and USB3 sticks, BadUSB theoretically works on any type of USB device. And for another, it's almost impossible to detect a tampered device without employing advanced forensic methods, such as physically disassembling and reverse engineering the device. Antivirus scans will turn up empty. Most analysis short of sophisticated techniques rely on the firmware itself, and that can't be trusted.

"There's no way to get the firmware without the help of the firmware, and if you ask the infected firmware, it will just lie to you," Nohl explained.

Most troubling of all, BadUSB-corrupted devices are much harder to disinfect. Reformatting an infected USB stick, for example, will do nothing to remove the malicious programming. Because the tampering resides in the firmware, the malware can be eliminated only by replacing the booby-trapped device software with the original firmware. Given the possibility that traditional computer malware could be programmed to use BadUSB techniques to infect any attached devices, the attack could change the entire regimen currently used to respond to computer compromises.

"The next time you have a virus on your computer, you pretty much have to assume your peripherals are infected, and computers of other people who connected to those peripherals are infected," Nohl said. He said the attack is similar to boot sector infections affecting hard drives and removable storage. A key difference, however, is that most boot sector compromises can be detected by antivirus scans. BadUSB infections can not.

Transforming a brand-name USB stick into a computer keyboard that opens a command window on an attached computer and enters commands that cause it to download and install malicious software. The technique can easily work around the standard user access control in Windows since the protection requires only that users click OK.

Transforming a brand-name USB stick into a network card. Once active, the network card causes the computer to use a domain name system server that causes computers to connect to malicious sites impersonating legitimate destinations.

Programming a brand-name USB stick to surreptitiously inject a payload into a legitimate Ubuntu installation file. The file is loaded onto the drive when attached to one computer. The tampering happens only after it is plugged into a separate computer that has no operating system present on it. The demo underscores how even using a trusted computer to verify the cryptographic hash of a file isn't adequate protection against the attack.

No easy fix

Nohl said there are few ways ordinary people can protect themselves against BadUSB attacks short of limiting the devices that get attached to a computer to those that have remained in the physical possession of a trusted party at all times. The problem, he said, is that USB devices were never designed to prevent the types of exploits his team devised. By contrast, peripherals based on the Bluetooth standard contain cryptographic locks that can only be unlocked through a time-tested pairing process.

The other weakness that makes BadUSB attacks possible is the lack of cryptographic signing requirements when replacing device firmware. The vast majority of USB devices will accept any firmware update they're offered. Programming them in the factory to accept only those updates authorized by the manufacturer would go a long way to preventing the attacks. But even then, devices might be vulnerable to the same types of rooting attacks people use to jailbreak iPhones. Code signing would likely also drive up the cost of devices.

"It's the endless struggle between do you anticipate security versus making it so complex nobody will use it," Nohl said. "It's the struggle between simplicity and security. The power of USB is that you plug it in and it just works. This simplicity is exactly what's enabling these attacks."

Promoted Comments

So, does turning off autoplay on USB devices mitigate or prevent this attack or are we still screwed even if it is turned off and someone plugs a malicious USB thing into our computer?Yes, I read the article but by the middle I was going "Wha?" and scratching my head puzzling over this.

My understanding is that if you plug it in, it will infect, auto play or not, and that this is not limited to any one operating system. This attack vector uses the actual firmware on the USB device, which tells the computer the type of device being plugged in. So you plug in an infected usb storage device, and it tells the computer that it's also a keyboard. Then it types commands as though you were doing it at your actual keyboard.

Call me thick, but wouldn't it be rather obvious that your USB memory stick is being a keyboard, because it can't also be a memory stick. i.e. where the hell have all my files gone?

You aren't being thick, but you're wrong in thinking a USB device can only be one thing. There's nothing stopping a USB Flash Drive being fully functional as a USB Flash Drive whilst also surreptitiously acting as a keyboard if it's firmware has been modified to advertise it as such. A USB device can have multiple device ID's and able to process commands as any of them.

Back in the early days of 3G dongles, they would show up as both the dongle itself and as a virtual CD drive from which to install the device driver from. this attack vector is the same concept, only for malicious intent and not built into the device intrinsically.

This one, people can protect themselves from by using charging cables that do not actually have the data pins. Which are a good idea to carry while traveling, if you're not bringing your own trusted charging devices with you.

I have a hard enough time convincing my parents-in-law to stay off the "Free WIFI" SSIDs at the airport; now I need to convince them to use a special charging cable because of "malicious USB ports"? Ha. Fat chance. That's not only a behavior change but also an expenditure of money, all for a threat they can't identify.

Hacks where there is no visual difference in the operation of the device, like this one, are completely stealthed to the majority of end users. Trying to explain it just sounds like paranoia. "See? My phone is charging just fine and I can play my games, check my bank balance, and everything."

So, does turning off autoplay on USB devices mitigate or prevent this attack or are we still screwed even if it is turned off and someone plugs a malicious USB thing into our computer?Yes, I read the article but by the middle I was going "Wha?" and scratching my head puzzling over this.

Edit: Also, isn't the firmware usually read only on these devices and/or in order to overwrite them, you have to use very specific tools AND know which device you are trying to overwrite firmware on, down to the specific model? So, how would they be able to be compromised when that is the case?

Security experts that work with/for the federal government have been saying this for years, begging them to completely block (not by policy or banning the use, but actuall physically prohibiting access) USB thumb drive access, and to the best of my knowledge, not a single agency listened. Hopefully this proof of concept will change their minds....

Now, the actual vector isn't detectable by software scans, but wouldn't a good chunk of what they're using to do be noticeable? Downloading malware will trigger normal malware detection. And redirecting common sites would still result in the imposter sites not being able to produce matching certificates. Unless the modified USB device could conduct some pretty sophisticated man-in-the-middle attack and/or some pretty sophisticated heuristics to predict the necessary keyboard strokes/mouse clicks.

Security experts that work with/for the federal government have been saying this for years, begging them to completely block (not by policy or banning the use, but actuall physically prohibiting access) USB thumb drive access, and to the best of my knowledge, not a single agency listened. Hopefully this proof of concept will change their minds....

It won't change their minds because in too many cases, these people NEED USB drive access to do their work. Bottom line, period and done with... they need them to do their work.Since this could ALSO be done with a mouse USB thing, wired or wireless? Doubt that they are going to ban ALL USB devices, which would be the only way to totally prevent this attack from what I am getting from the article.

So, does turning off autoplay on USB devices mitigate or prevent this attack or are we still screwed even if it is turned off and someone plugs a malicious USB thing into our computer?Yes, I read the article but by the middle I was going "Wha?" and scratching my head puzzling over this.

My understanding is that if you plug it in, it will infect, auto play or not, and that this is not limited to any one operating system. This attack vector uses the actual firmware on the USB device, which tells the computer the type of device being plugged in. So you plug in an infected usb storage device, and it tells the computer that it's also a keyboard. Then it types commands as though you were doing it at your actual keyboard.

This is a terrible security flaw but it's also kinda awesome from the perspective of a "cyberpunk dystopia is now" point of view. This is the sort of paranoia I would've thought illogical just a few years ago but its now a thing we really have to worry about. Makes me wonder what else I'm taking for granted that could be compromised...

So, does turning off autoplay on USB devices mitigate or prevent this attack or are we still screwed even if it is turned off and someone plugs a malicious USB thing into our computer?Yes, I read the article but by the middle I was going "Wha?" and scratching my head puzzling over this.

Edit: Also, isn't the firmware usually read only on these devices and/or in order to overwrite them, you have to use very specific tools AND know which device you are trying to overwrite firmware on, down to the specific model? So, how would they be able to be compromised when that is the case?

Just as turning off autoplay does nothing to stop your USB keyboard from working, it does nothing to counter a USB stick that has been reprogrammed to act as a keyboard. From there, BadUSB causes this improvised keyboard to enter malicious commands shortly after it's attached.

Does this affect all systems or are systems that implement a permissions based OS safer than, eg, Windows?

I assume that you are referring to Linux or OSX? I doubt if they are anymore safe when it comes to this then Windows computers are.

Why wouldn't they be safer? Windows installs drivers for USBs without asking for permission but for anything that changes / in *nix you are asked for an administrator password/authorisation.

Surely that would add a layer of security that windows lacks?

It might prevent auto-infection of your computer... maybe (and that's a big maybe), but it's not going to do much good when you try to use the device. Even if it did nothing else, the device could hand windows a virus when it asks for a file, and that virus would be completely hidden from anti-virus because the firmware would do the Jedi mind trick if anything asked for the memory directly (*these are not the files you are looking for, there is nothing here...)

And that's the rock bottom, easy peasy, doesn't require changing any interaction with the OS. You own the firmware on the device, you can make the device do what you want, OS restrictions just define the limits of what it might be able to do on the target's machine, not it's own capabilities.

So, does turning off autoplay on USB devices mitigate or prevent this attack or are we still screwed even if it is turned off and someone plugs a malicious USB thing into our computer?

This bypasses autoplay, and even the file system itself.

Basically, when you plug a USB device in, the PC asks the USB device what it is, and installs the correct drivers for it. In this hack, they modified the firmware so a USB stick tells the PC, "hey, I'm a keyboard too." The PC installs both USB flash driver and a keyboard driver for the stick. The user sees the regular USB flash drive appear, but unless they go into Device Manager, probably don't notice the extra keyboard install. The stick's firmware then sends keyboard commands to the PC to open a command prompt, initiate a download, and execute the downloaded file.

The problem I see is that, as described, this hack would cause a visible command prompt window to appear and run commands. The authors even state that a user would have to click OK on a UAC prompt to get elevation. So it's not as bad as it first appears, assuming the PC user doesn't indiscriminately click "OK" to every UAC prompt, especially unanticipated ones.

Does this affect all systems or are systems that implement a permissions based OS safer than, eg, Windows?

Windows is a permissions based OS, it just has historically been pretty lax in enforcing permissions in a default install. However, this hack can affect any OS, since all Operating Systems implicitly trust USB devices to be what they say they are. Whatever payload one of the hacked devices tries to deliver, however, will need to be OS specific. The article mentions a Ubuntu specific attack.

So, does turning off autoplay on USB devices mitigate or prevent this attack or are we still screwed even if it is turned off and someone plugs a malicious USB thing into our computer?Yes, I read the article but by the middle I was going "Wha?" and scratching my head puzzling over this.

Edit: Also, isn't the firmware usually read only on these devices and/or in order to overwrite them, you have to use very specific tools AND know which device you are trying to overwrite firmware on, down to the specific model? So, how would they be able to be compromised when that is the case?

Just as turning off autoplay does nothing to stop your USB keyboard from working, it does nothing to counter a USB stick that has been reprogrammed to act as a keyboard. From there, BadUSB causes this improvised keyboard to enter malicious commands shortly after it's attached.

To clarify a little, the computer isn't the part being infected, just the USB device. In the Ubuntu example, it's rewriting the flash drive's programming so that the flash drive itself modifies an Ubuntu installation file as it's being read from the flash drive.

The problem I see is that, as described, this hack would cause a visible command prompt window to appear and run commands. The authors even state that a user would have to click OK on a UAC prompt to get elevation. So it's not as bad as it first appears, assuming the PC user doesn't indiscriminately click "OK" to every UAC prompt, especially unanticipated ones.

I obviously haven't seen the demo yet, but Nohl told me the command window appears for such a very short period of time that people won't notice it unless they know to look for it.

So, does turning off autoplay on USB devices mitigate or prevent this attack or are we still screwed even if it is turned off and someone plugs a malicious USB thing into our computer?Yes, I read the article but by the middle I was going "Wha?" and scratching my head puzzling over this.

Edit: Also, isn't the firmware usually read only on these devices and/or in order to overwrite them, you have to use very specific tools AND know which device you are trying to overwrite firmware on, down to the specific model? So, how would they be able to be compromised when that is the case?

Just as turning off autoplay does nothing to stop your USB keyboard from working, it does nothing to counter a USB stick that has been reprogrammed to act as a keyboard. From there, BadUSB causes this improvised keyboard to enter malicious commands shortly after it's attached.

Yes, but from what I am reading, they are saying that they could ALSO have malware that as per course, scans when you put a USB stick in the computer and automatically compromises it. That seems... strange to me considering that each manufacturer has their own 'quirks' in firmware and therefore the firmware that works on one device would not work on another.

The problem I see is that, as described, this hack would cause a visible command prompt window to appear and run commands. The authors even state that a user would have to click OK on a UAC prompt to get elevation. So it's not as bad as it first appears, assuming the PC user doesn't indiscriminately click "OK" to every UAC prompt, especially unanticipated ones.

I obviously haven't seen the demo yet, but Nohl told me the command window appears for such a very short period of time that people won't notice it unless they know to look for it.

Wouldn't the big 'screen blank' UAC prompt tell them? Or does this automatically click on the "OK" button, something that Windows DEFINITELY should not darn well allow.

I can see where this would be bad. There are certain classes of USB devices where at the lowest level their IO isn't even handled by the OS but rather by system services (BIOS).

Imagine a two-stage attack - BadUSB device infects the system BIOS with malware. Then it doesn't even matter if you discover the device or any payload at the OS level, the system is compromised for life.

Why is this particular vector bad? Who doesn't plug their portable USB device into whatever available USB port to charge the battery... this could easily become a pandemic.

The problem I see is that, as described, this hack would cause a visible command prompt window to appear and run commands. The authors even state that a user would have to click OK on a UAC prompt to get elevation. So it's not as bad as it first appears, assuming the PC user doesn't indiscriminately click "OK" to every UAC prompt, especially unanticipated ones.

Clicking on the UAC would be a function of the mouse or trackpad. Many of these devices are also USB enabled.

I can see where this would be bad. There are certain classes of USB devices where at the lowest level their IO isn't even handled by the OS but rather by system services (BIOS).

Imagine a two-stage attack - BadUSB device infects the system BIOS with malware. Then it doesn't even matter if you discover the device or any payload at the OS level, the system is compromised for life.

Unless you reflash the BIOS or there is a way to 'password protect' the BIOS from being overwritten, yeah... that could get seriously messy. It is like I have been saying for years: Computers need to get more DIStrustful of everything plugged into them and run on them, unless they are on a specific whitelist.

Security experts that work with/for the federal government have been saying this for years, begging them to completely block (not by policy or banning the use, but actuall physically prohibiting access) USB thumb drive access, and to the best of my knowledge, not a single agency listened. Hopefully this proof of concept will change their minds....

It won't change their minds because in too many cases, these people NEED USB drive access to do their work. Bottom line, period and done with... they need them to do their work.Since this could ALSO be done with a mouse USB thing, wired or wireless? Doubt that they are going to ban ALL USB devices, which would be the only way to totally prevent this attack from what I am getting from the article.

Does USB make their jobs easier? Sure, but I'm not sure government workers absolutely NEED it (for example, the military banned USB drives serveral years ago, but it was merely a policy measure). There are other ways to transfer files and data without having systems physically interface with a USB drive that could be carrying this type of malware. Would this transition be easy? No, of course not. We're talking about the government here. But with the flurry of new mobile devices, including ultra-thin laptops with no USB ports, plus the increase of cloud storage and file sharing options, I'm not sure that USB access is a must have for any job anymore.

The problem I see is that, as described, this hack would cause a visible command prompt window to appear and run commands. The authors even state that a user would have to click OK on a UAC prompt to get elevation. So it's not as bad as it first appears, assuming the PC user doesn't indiscriminately click "OK" to every UAC prompt, especially unanticipated ones.

Clicking on the UAC would be a function of the mouse or trackpad. Many of these devices are also USB enabled.

UAC is very bypassable programmatically. Even more so by a device running at kernel level where UAC doesn't even exist.

The problem I see is that, as described, this hack would cause a visible command prompt window to appear and run commands. The authors even state that a user would have to click OK on a UAC prompt to get elevation. So it's not as bad as it first appears, assuming the PC user doesn't indiscriminately click "OK" to every UAC prompt, especially unanticipated ones.

Clicking on the UAC would be a function of the mouse or trackpad. Many of these devices are also USB enabled.

Infecting the firmware is an impressive advancement, but a purpose-built device has been around for a while. Hak5's USB Rubber Ducky even comes with its own programming language to make it dead simple. https://hakshop.myshopify.com/collectio ... cky-deluxe There's an impressive library of scripts now, including typing a uudecoder script that lets you enter uuencoded binaries!

Are there any motor vehicles (cars, trucks, vans, etc) with USB ports/interfaces ? That could get seriously messy.

Except that those USB interfaces are usually just for charging and access to things like music players and music storage. Unless the car is designed specifically to be controllable from USB, it wouldn't make a difference. It works in computers because computers *can* be controlled via USB (i.e. keyboards and mice).

Even if you did have a car designed to be operated via USB, you'd need to know ahead of time exactly how the vehicle responds to commands.

Sounds like there's a market for a USB firewall device. You plug untrusted USB devices in via the intermediate firewall device, which is designed to prevent these sorts of attacks. It would only allow basic file-system access that is prompted via the OS.

So how could this work? Each USB device has the same type of CPU and it is enough to write one malicious firmware or write many firmwares for each variety of devices and pack them into one firmware? How does the firmware know what operating system it is communicating with? How can it type in the commands to open a console in Windows, download something from the web without wget? Would it patch the Ubuntu installer to skip self-check and somehow prevent verifying the signature while installing? It sounds like only a very specific targeted attack would work, but then it seems to be too much fuss. If this is so simple and straightforward, why wasn't this discovered earlier? The properties listed in the article sound pretty much like BadBIOS; I'm skeptical.

Does this affect all systems or are systems that implement a permissions based OS safer than, eg, Windows?

I assume that you are referring to Linux or OSX? I doubt if they are anymore safe when it comes to this then Windows computers are.

Why wouldn't they be safer? Windows installs drivers for USBs without asking for permission but for anything that changes / in *nix you are asked for an administrator password/authorisation.

Surely that would add a layer of security that windows lacks?

From reading the article, it's because the firm ware make the device masqurade as a different device that probably doesn't need drivers - e.g. a keyboard or mouse.

It depends, my mouse which has a few extra buttons for gaming also reports itself as a keyboard. You then can map either keys, macros or other things both default and to individual games (or whatever programs has focus) if so desired.