Why the Security of USB Is Fundamentally Broken | Hacker News Reader

Why the Security of USB Is Fundamentally Broken

wired.com

95 pointsjustinpaulson74 comments

To the skeptics here -- the problem is that malware can turn one kind of USB device into another kind of USB device, and that creates a massive attack surface given the scope of USB.

Check out all the things that a USB device can claim to be.[1] You don't just need your OS to be secure against a malicious storage device; you need it to be secure against a malicious keyboard and mouse, speaker/microphone/sound card, printer/scanner, CNC machine, webcam, ethernet or wifi adapter, bluetooth adapter, infrared adapter, RNDIS adapter (whatever the heck that is, but it's supported by BSD as well as Windows), an ActiveSync device, a smart card reader, a fingerprint reader ...

As I understand it (and I wouldn't mind being wrong), a hostile USB stick could claim to be a hub running all of these at once, and orchestrate them in an attack. Consumer-oriented OSes will happily load up standard drivers to talk to most of them in an attempt to be user-friendly, each with their own hooks into the OS. And the hostile device can detect what OS and probably specific hardware it's talking to,[2] so it can target an attack at the drivers that are likely to exist.

If that's true, I don't see how anyone could be confident that such a stack could ever be secured on the OS side. A secure bulk storage driver is one thing, but your laptop has to be secure against a hostile keyboard working with a hostile CNC machine, sound card, and ethernet device?

At a minimum it seems like devices should be locked at the hardware level to the kind of device that they are. Code signing makes a lot of sense too, although it's sad to lose the (hypothetical?) ability to install alternative drivers.

[1] http://en.wikipedia.org/wiki/USB#Device_classes [2] http://ix.cs.uoregon.edu/~butler/pubs/sadfe11.pdf

I think, one of the problem here, is the universality aspect of USB. When we had different plugs for different things, no keyboard could pretend to be a mass storage device and vice versa. Now, when you plug something into your USB port, it could be anything.

It is similar to the scripting languages, Microsoft included into their office products. Before their where also some scripting possibilities in office products, but most of the time not that powerful. When they did it into the most popular office suite existing, the way for a new kind of virus was paved. The universality of office scripting also made the products more vulnerable to attacks.

Seems to me that pluggable USB is no different from installable software. So why not just the same sort of sandbox + permissions model that iOS/Android apps live in?

Discussed in other thread: https://news.ycombinator.com/item?id=8115002

Qubes OS is evolving in this direction for all peripheral devices (even some of the ones on the motherboard such as NICs). USB is taking more time, but controllers will in future automatically be sandboxed in Service VMs. For now, a Qubes user can quickly create their own USBVM that uses the system IOMMU (if present) to reassign USB controllers to that VM; Likewise, you can also assign particular USB controllers to individual VMs. These VMs can be selected for autostart at boot time with a couple mouse clicks.

A more granular and hence flexible way to sandbox and handle USB devices will be coming to Qubes by way of Xen's PV USB feature.

https://qubes-os.org

Seems the problem is basically one of "physical access to the machine is hard to secure against." Combining with "multi purpose computing device attached to your computer is dangerous."

Would it not be simple to offer up "non generic" USB port support? That is, the problem is that plugging a USB device could be plugging in a variety of things, which makes it tough. You have to assume that every stack on your machine is hardened against attack.

Instead, make it so that a user can designate that a port can only be used by mass storage devices or keyboards. A basic UI could be devised showing all of the ports and what is expected to be plugged in to them. If something different is actually plugged in, it is not allowed to connect.

That make sense? Something like this already exist?

So, essentially a Specific Serial Buss? We'd be going back to pre-USB times, except without the advantage of differently shaped connectors.

Yes, except I'm saying to do it by software. Make sense? The port could take in anything. But there is no reason for it to expect anything. It should really only expect things I have indicated for it to expect.

Wouldn't that just end up working like this?

1) User finds USB stick in parking lot

2) User takes USB stick back to desk and plugs it into workstation

3) Workstation throws up a dialog saying "Hey! I don't recognize that thing you just plugged in! Are you sure you want to let it connect?"

4) User blindly clicks "OK" on dialog without reading it while surfing porn in another window

The UI should instead say "The device plugged in is not a storage token" or some such. Even better if it lists what the device is claiming to be.

And, really, if we are concerned with people blindly clicking "OK", I'm not sure of what you can do.

I like this idea. It doesn't even have to be turned on by default, it could be an opt-in kernel module that doesn't load until you ask for it.

In other words, use the same sort of sandbox + permissions model that iOS/Android apps live in. For example:

- "USB device 'Kensington 16GB' is trying to take over as your computer's keyboard. Allow?"

- "USB device 'Kensington 16GB' wants read access to your files. Allow?"

- "USB device 'Kensington 16GB' wants write access to your files. Allow?"

The latter two could be more specific about the source/target directories.

“These problems can’t be patched,” says Nohl, who will join Lell in presenting the research at the Black Hat security conference in Las Vegas. “We’re exploiting the very way that USB is designed.”

‘In this new way of thinking, you have to consider a USB infected and throw it away as soon as it touches a non-trusted computer.’

So now we need a USB abstinence campaign?

When you have a USB with someone, you are having a USB with everyone they had a USB with for the last ten years, and everyone they and their partners have had a USB with for the last ten years.

Also, we're just calling it a USB now? Not a USB thumbdrive, USB hard drive, or whatever? This article sounds like it was written by my mom.

It most surely can be patched. Allow a USB device to offer up a signature that the PC can verify. The CA would be the manufacturer which has a private key for each USB key manufactured (so hackers can't steal one private key and copy it). Make sure the manufacturer revokes keys that are compromised. Bam, instant manufacturer guarantee that the hardware is genuine. That is, until the private key is uncovered by the hackers, but that's what expiration dates are for I suppose.

That will work in the same way that DVD copy protection worked - briefly and ineffectively.

It's not a good DRM protection. It is a reasonable way to verify hardware for a user though.

How would the manufacturer know that an individual thumb drive has been compromised?

The user would need to receive the equipment in some secure fashion. Direct from the manufacturer in tamper-proof packaging or something. And from there it's up to the user of the key to ensure it is not physically compromised.

How do you ensure that a malicious firmware is not just impersonating the valid firmware for the device?

With a signature

What prevents the firmware replaying a transaction with a valid signature? You're relying on the device to give you a true copy of the firmware it's running, but that means trusting something that's not trustworthy.

One could use some sort of RSA secure token technology that would be very hard to replicate the state of at the time of the attack. I guess my point is that there's loads of ways USB could be used in a secure fashion. To say it can't be "patched" is completely unfounded in reality.

The firmware on a USB stick should not be writeable.

When will you ever update the firmware on your storage device. Never, USB sticks are cheap and disposable. Mass produced ones should have their firmware burned into ROM.

This does nothing to protect you. Malicious users will just make their own usb stick. The parts aren't exactly expensive.

Of course it does something to protect me. It means that I can plug my USB drive into a friend's computer, then plug it back into my own computer without worry.

Only if you fully trust the entire supply chain down to you. Do you have any way to verify that the mass storage device you bought was not a forgery?

I'm not aiming for perfection, just aiming to improve. It is easier for me to trust that the sealed USB drive I bought has not been tampered with than it is for me to trust that all of my friends are knowledgeable and avoid malware.

yes I agree that this looks like a good step, vendors should also probably release some tools to verify the integrity of their firmwares if possible.

When? All the damned time. Maybe you have an external HD or SSD based on USB, updating the firmware is perfectly acceptable. Same thing for HIDs and NICs. High performance USB drives are basically little SSDs, and there's plenty of reasons for wanting to update the controller firmware on them to improve features or performance.

It should not, however, be generally possible for arbitrary programs to update the firmware on a USB device without both the consent of the computer host's current user/administrator AND the device's manufacturer (subject to certain hedges and caviats of course). Right now many USB devices are just wide open, allowing this chaos of security vulnerabilities, that should not be.

> So now we need a USB abstinence campaign?

What's your risk assessment?

Some places already have a USB abstinence campaign - they remove the ports and do as much as they can to remove the functionality from their OS. Or they remove as many ports as they can and lock other cables in place.

Seems to be lacking in technical detail.

I suppose the fundamental problem is treating the thing on the other end of the wire as a "peripheral" (i.e. inside the computer's logical boundary) rather than as another computer on the end of a network (which might be expected to be hostile).

Firewire and Thunderbolt are much worse: the peripheral has potential DMA access to the whole of system memory. http://support.microsoft.com/kb/2516445

This article is severely lacking in actual information. They also make no distinction between Windows, Macs, or Linux. I seriously doubt that if I plug in an infected USB device to my Linux laptop its firmware will be able to alter the DNS settings (/etc/resolv.conf which is owned by root). That sounds like a very OS-specific (probably Windows-specific) vulnerability. My best guess is it has something to do with the "automated whether you want it to be or not" printer driver installation mechanism whereby Windows PCs inherently trust the driver that's provided by the device.

The ability to modify the data as it's copied seems like the only actual vulnerability to me. As in, I write some executable to the USB drive and the firmware modifies the executable to perform other functions. Once the file is copied off of the device though it should be pretty easy to detect such shenanigans with something as simple as a hash check.

You could also have separate flash storage on the device that isn't visible to the OS where you could store whatever data you want but that's less of a concern when you consider that a perhipheral like a keyboard can't record the keystrokes of another perhipheral (not directly, anyway--you'd have to get the user to execute some malware).

I agree that more detail is needed. (Somehow when they said network sniffing I thought maybe the thing presented itself as a NIC. I dunno.)

However, let's not get too dismissive. I always remember reading about the security problems in firewire for example. These were OS independent. A malicious device could do DMA into the host machine without the OS being able to validate. This type of hardware design issue leading to security problems is not unheard of.

Lastly, printer drivers? Huh? Can you point at an actual Windows feature that is currently shipping or are you thinking of 1990s Windows and autorun? When you plug in a device these days, it will check Windows Update based on the device ID but I am not aware of anything that will trust unverified code coming from elsewhere without the user doing something.

There's a reason why you have to add printer drivers to shared printers... Windows will install those automatically. The same mechanism can work for a USB device but I forget the details (it's been a long time). I remember reading about it when that signed driver from HP had a serious privilege escalation vulnerability back in the day (it let you gain "Trusted" level access which was higher than "Administrator" which basically meant re-imaging was the only option to correct such a compromise).

Also, if you configure your USB device to emulate certain other devices those drivers will also be installed automatically via Windows Update. Such drivers may have vulnerabilities or just flat out provide all sorts of privileged access to the system. It's not that complicated, actually... Just change the USB device manufacturer/ID and let Windows compromise itself.

If the bar is loading a vulnerable driver, Linux has a lot of drivers for uncommon devices in-tree. Sure, they are open and largely not written by hardware manufacturers, but I bet some of them are vulnerable to malicious hardware.

It's easy to make a USB device to randomly type dangerous things, open URLs and download, then start applications (anything you could do with a keystroke). That sort of thing is achievable with an Atmel chip wired to a USB plug. See http://macetech.com/blog/?q=node/46

I don't know whether it's possible for such a device to snoop on other devices. I suspect not, unless it is a hub which contains the bad firmware. It might be interesting for capturing passwords, then playing them back later.

Of course any device could compromise the device driver using buffer overflows, etc, to gain control of some aspect of the computer.

This kind of attack has been around for some time, but so far you needed a special, programmable chip for that. And yes, it can attack nearly every OS, including Linux.

Check out this for more information: https://github.com/hak5darren/USB-Rubber-Ducky/wiki

The USB Rubber Ducky just emulates a keyboard. That's not a vulnerability, really. Unless I'm actively logged in it won't compromise anything. It just speeds up the process of installing back doors (and the like) if you've already got physical access to a system that is already logged in.

I could do the same with any $5 Arduino Leonardo device (of which I have several).

I have written firmware for USB devices. These attacks are a genuine threat, because a USB device can pretend to be whatever it has to be to get the OS to load an exploitable driver, and then the exploited system can infect other USB devices by rewriting their firmware.

The initial access patterns to the device are likely to be different for different platforms, which should permit OS detection. Now it can launch a tailored payload - for instance, on Gnome, something like:

a) present as keyboard b) windows key terminal enter c) cat >.libevil.so.base64 <<EOF d) dump a base64 library in there e) base64 -d .libevil.so.base64 >.libevil.so f) echo "LD_PRELOAD=~/.libevil.so" >>.bash_profile g) exit h) turn into a USB mass storage device again

This applies to all USB devices indeed and can even be made OS-agnostic.

USB stacks have been proven to be buggy (one of the PS3 exploits iirc used a modified Android phone giving malformed USB descriptors to the host). Add DMA to the mix and you have root access...

This is an interesting statement; I'm not sure how you can substantiate it -- I will not be able to evaluate the impact of the vulnerabilities until everything is published after the Black Hat presentation next week.

I looked to see if USB could 'do' DMA (similar to i1394) and the general consensus seemed to be that it was in the hands of drivers several layers below what was normally accessible to device developers - so unlikely but perhaps possible if there was an exploit. (It sounds like all DMA by the USB device would have to go through driver software on the computer, instead of direct memory access as is possible with firewire.) http://www.osronline.com/showthread.cfm?link=243802

This all sounds similar to how 3d graphics drivers are a new security frontier as web browsers rush to support arbitrary shaders: any usb device can claim to be something with a 'ships-with-the-OS' exploitable driver (eg. a 10-year-old usb network adapter) and then pop the exploit to run arbitrary code with device driver level access.

The solution will require sandboxing device drivers (in user-space or with virtualization) and will probably affect performance to such a degree that it will have to support opt-out.

Unfortunately I'm on mobile so cannot do any further research.

I'd just google for ps3 usb exploit, that should give you the iformation.

The DMA stuff was basically just imagination. With Firewire, it has been proven to work as the port itself gives DMA access. USB has something like this not built-in, but most people use the same or similar controller chipsets, so that, like in GSM baseband processors, a single exploit could target loads of devices.

The main problem is that hardware was usually built with full trust in mind... I wonder what Lightning does, given it is essentially a PCI lane in optic wire. Lightning stuff is hellish expensive at the moment, but I'm just waiting...

Does USB promise any security? If so I never heard about it before. Otherwise it's not much surprise that an unsecured protocol is not secure, though.

> Does USB promise any security

I don't believe so. It's just a bus and protocol for easily connecting external peripherals and it doesn't look like it does much else.

Others have compared it to networking technologies, but a more apt comparison for its use and design would be the PCI r PCI-E bus. You're connecting things to act as the local machine, by that point you're implicitly trusting them.

By this logic, if "USB" (the bus) is broken, so are i2c, SPI, etc. PS/2 is equally broken, because a nefarious PS/2 keyboard or mouse can do exactly what that USB thumbdrive can do too. Also your RAM bus. And that IDE/SATA/Whatever Hard Drive. And even that sneaky VGA cable. A microcontroller in the connector could alter your display to cause you to click on dangerous things/delete files/etc. I could give you a laptop power supply cable that will destroy years' worth of your work, along with your laptop. There are lots of attack vectors involving things you stick in your computer, but I really don't think a bus protocol is the problem.

The attack the article is describing can be used to infect USB devices that are plugged in to a compromised machine. They do not require a malicious actor to provide a compromised USB device. The attacks you describe involve altering, physically, a peripheral in order to perform the compromise. That has been possible as long as computer peripherals have existed.

I think you're vastly underestimating the devices that have a modifiable firmware on them that connect to busses other than USB.

However, the one thing that is unique to USB is the nature in which USB storage devices are shared between multiple devices.

> However, the one thing that is unique to USB is the nature in which USB storage devices are shared between multiple devices.

That was half of my point. I was not underestimating the vulnerability of SATA and other on-board communications protocols. I was ignoring them because the parts connected to these are generally not moved between machines. Yes, you could infect these devices and hope they spread through the secondary market to a desirable target, but the utility of such an attack is very limited.

Can you re-write a USB thumb drive's firmware, over USB? the only reference to that I saw in the article was that it can "spread from USB to PC and back" which is kind of vague. Is there a specific vulnerability on a specific chipset that is exploited?

I understand the point that USB drives are more, well, promiscuous than other bus hardware, but saying "A thumbdrive with modified firmware can affect a computer it is plugged in to" and equating that with "USB security is fundamentally broken" seems like a bit of a reach. i.e. there is no specific provision in the USB protocol for re-flashing device/USB stack firmware. I think "Certain USB thumbdrive chipsets are vulnerable to a specific exploit that allows the USB host to modify the thumb drive's firmware" is a much more accurate headline, given the content of the article. Right now it is no different than saying "I got a virus over email, therefore Ethernet is fundamentally broken"

Stating the problem:

1.) You want to trust your USB device. 2.) You want to use your USB device on another non-trusted computers. 3.) Non-trusted computers can update your device's firmware behind your back.

So how can you handle firmware upgrades on your USB without trusting computers? One way to do this is to have an firmware update approval mechanism directly on the device.

For keyboards the mechanism could be the following:

- The computer initiates a firmware update. - The keyboard leds start to blink - You have to enter your keyboard's UUID (which is on the bottom)

Now you only have to make sure that you don't lend your keyboard to someone that you don't trust.

Why does a keyboard even have/need a firmware update mechanism? USB devices are disposable commodities. Their firmware should be permanently burned into whatever minuscule ROM they need to function.

To answer your first question: There exists a great number of programmable keyboards that are, frankly, awesome. I used to use a Fingerworks TouchStream LP keyboard that let you program the hell out of it. It was great... I had macros that would auto-type all sorts of handy things like my username, email address, etc. You could also program mouse movements into the thing.

It supported ten finger gestures so basically the sky was the limit in terms of what you could program it to do. It had only one flaw: There was no tactile feedback so it was easy for your hands to get out-of-alignment resulting in incorrect characters being typed pretty often. On the other hand it was much faster to move the cursor around than a regular keyboard so correcting mistakes was less of a hassle.

The main issue I think is having an active vs intert system as a data storage mechanism. A usb drive must interact with the computer in order to transmit data, a CD or DVD are ultimately inert disks which are read without any back and forth alterations. There is a higher degree of security inherent in that I believe.

Unfortunately, the popularity (and honestly the convenience) of USB flash drives has made it hard to switch onto safer mechanisms.

While true for commercially pressed optical media, this is not true for writable media. Although in that case the fix is straightforward, only use a read-only drive.

I am missing one information here (maybe one hw-hacker can give the answer):

Is it possible (for some or many) USB-sticks or USB devices to reprogram the firmware from an PC that it is connected to it?

The article plays a little with the threat, that I (I want to put it this way:) lent my USB stick to a friend, he uses it, but clears it afterwards and gives it back to me and the stick now contains an infected firmware (that I can not find out by normal means). And also the friend knows nothing, since his computer was infected before.

Of course, I know that it is possible to change a firmware by hw-means (replacing the chip or reprogram it with special hw) but when the firmware of some or all USB-devices would be alterable just by plugging them into a computer, a new kind of virus would be possible spreading more silently and dangerously as all of them before.

HW hacking the firmware of USB devices of course is possible, but would be more in the field of industrial or real espionage. Reprogramming firmware "on-the-run" would cause a new mass-threat for computers.

The firmware on today's USB drives is flashable from Windows (usually XP) using the manufacturer's proprietary utility for that particular flash memory controller. Sandisk remains mysterious as their utility if it exists has not been leaked.

This is likely because the firmware has not been perfected yet, so ugrades are continuing. Plus completely different characteristics can be obtained to arrive at multiple device brands or behaviors from the same hardware. "Identical" flash drives from the same manufacturer containing the same exact chips can often have different firmware revisions, and different resulting performance.

On most units an additional CDROM device, or extra partitions (hidden, private/secure or not) can be configured to be detected (or not) when plugged in to any OS. The controller provisions the available flash memory among the dictated devices and makes them available to you.

I've been adjusting the firmware for a couple years now as I do the continuous improvement on my rapid multibootable sticks.

Thanks. So, if anybody reverse engineers the proprietary utility, a virus could be coined that spreads via USB devices and infects thousands of computers and USB sticks and the like. Scary.

I'm not so sure that security should be built into peripheral connect protocols like USB. We could just as easily treat a usb device like we do a network device, and harden the drivers against attack.

If you plug in a usb stick and it pretends to be a keyboard/mouse, it can do anything it wants to your system [within the context of a keyboard and mouse] as soon as it's plugged in. Hardened drivers do not prevent this. Granted, this is less dangerous if a machine is locked, but you can leave it plugged in and wait for someone to log on.

It does point out the most glaring flaw in the lack of a security model, though: you should be able to approve or deny a new peripheral connection before the drivers are loaded or DMA is allowed.

typing =/= full control of system.

Since the typing is made with the full privileges of the current user and he might be totally unaware of this, it is nearly as good -- the dongle has only to wait until some administrator is on the computer. It gives all sorts of new attack vectors at least.

That's true, and people should be very wary of plugging in USBs. I, for one, would like the option to sandbox usbs: when it gets plugged in, ask my goddamn permission before granting it driver privileges. I'd probably be ok with a keyboard one, but write-only. But that doesn't mean USB is an inherent security risk, like something with DMA might be. One huge benefit of the serial bus is that by serializing the operations, you don't have to grant it access to bypass the cpu.

First of all, I think the title has been chosen to click-bait the reader. Second, maybe the real problem is that USB was never designed to be the main way to physically share data, or not even to be used with external storage? Please correct me if I'm wrong. Maybe people should start exchanging data on media that are designed to store data, like a memory card, but maybe this medium can also be compromised.

I don't understand what you're saying. At the simplest level, there is no such thing as a bus which doesn't exchange data... even my keyboard and mouse are just sending data. At multiple levels there is software (therefore the potential for security bugs) in this process. My keyboard has software to convert a set of input pin readings into a form to put on the bus. It has a bus communications chip that has software (firmware whatever) to talk to a host. The other side has a similar set of software to send data from the bus to memory or to input pins on a chip. The chip runs software to interpret these signals into usefulness. There are lots of places for problems in there.

Further, USB was designed from the beginning to allow block devices to transfer data. I don't quite get why this means it wasn't designed for data sharing - moving around physical, removable disks was the standard for data sharing for a long time when usb came out - back then most people couldn't reliable send big stuff over the network. The plan was definitely for sharing data.

Basically the security issues come from the shape of the problem rather than a specific implementation of it. For example there's always someone doing "fun" things with network cards - another example of a device with DMA access and a microprocessor. If you can root the network card, you can get access to other parts of the device.

So yeah - usb seems to be particularly easy to break, but it part of a generally hard problem. It would be nice to see a standard that takes the lessons of USB into account, and makes it much harder to break things.

I meant to say "share files" instead of "share data". But you're right, as I said, "Please correct me if I'm wrong". What I really wanted to say is that USB has been designed with so many different usages in mind that if you plug something in it, you should expect this "something" to be doing anything the USB has been designed for. And if you only want to share files and be sure it's not doing anything else, maybe you shouldn't be using USB. But at least this "problem" with USB is not as bad as with firewire or thunderbolt external storage.

> maybe this medium can also be compromised.

Indeed it can. Bunnie & xobs recently showed how to get code running on the controller chips of SD cards [1]. With your own implementation you could have the card present alternative files (clean vs infected) to different machines based on read patterns [2] or just a mount count. Without an exploit for the kernel, you'd still need the user to click on one the files, however.

That's not to say your suggestion isn't safer; SD cards don't present a threat to HID attacks (where a USB stick pretends to be a keyboard and is trusted to send inputs), but as with anything, it's not totally safe.

[1] : http://www.bunniestudios.com/blog/?p=3554

[2] : http://events.ccc.de/congress/2012/Fahrplan/events/5327.en.h...

I don't understand how code on a USB drive can be executed on a PC. I seriously thought that USB was (as a protocol) a generic data interface.

However, if it is something else (like, e.g., something that executes code from time to time), isn't it insecure by design?

And if so, why did nobody see it and was it malice or stupidity?

Protection against most attacks: The first time I connect a device, the OS should show me what type it is (keyboard, mouse, etc.) and ask me if I want to use it. Only at that time it gets activated.

How do you uniquely identify a device?

You could have the OS randomly generate a token and give it to the device and require it to repeat it each time it's plugged in.

Devices without tokens or with unrecognised tokens would need user approval, those with the correct one would be trusted. That still doesn't solve the problem of deciding if a device should be trusted or not though.

That would require modifications to the spec.

OK - so if I plug it into my computer, I'll get the same unique information that lets you identify it. Now I can plug my USB stick into your computer and pretend to be that device.

Well, that certainly isn't good. As if companies needed another reason to be obnoxiously paranoid about flash drives.

Well..... duh.

if you are goign to plug unknown hardware into your machine what do you expect

Reply on news.ycombinator.com