Wired is reporting that a software hack, aimed at rewriting a USB stick's firmware, is now in wild. The code comes directly from security researchers who believed publishing the info was the only way to force companies into taking action and fixing the problem. According to them high-level agencies like the NSA might have already had access to such code and they may already be exploiting this vulnerability. However, now that everyone knows about it companies will be forced to take action. But what's so bad about this, you might be asking yourselves. After all it's only a USB stick how much harm could it do? Unfortunately the answer is a lot. An attack using this technique, called BadUSB was demonstrated by a security researcher.

By connecting a corrupted stick to a PC he was then able to inject keystrokes, hide malware inside the stick's firmware, inject executables, and possibly spread the corruption further to other USB devices. And the worst part of this whole thing, is that due to the way the infection spreads and operates, infected devices are almost undetectable and unpatchable. And it could all blow up in an epidemic-style spreading pattern that could quickly engulf the whole digital world. If this sounds scary that's because it is. We live in an ever-more tightly connected world, where our devices and the internet have become the lifeline to our society. As such, thinking about security should always be a top priority, not an afterthought imposed by scandals and disasters.

quote:

I make a living designing and selling USB controllers and I can say
this article is very sensationalist and it is only telling a half-truth.
Yes, some USB devices rely on firmware for fundamental operation and
yes, the device firmware of *SOME* USB devices can be field-upgraded or
otherwise updated, but to claim that USB itself is fundamentally broken
due to this limited attack vector is nonsense.

There are three things that make this attack very specific and difficult to execute:

1)
Most USB device controllers are ASIC's, or Application Specific
Integrated Circuits. They are usually highly optimized to perform their
intended function very well, and they usually do not have extensibility
to become other devices. For example, one of my company's products is a
USB 3.0 to SATA Bridge, which is used in USB 3.0 external drives. Our
USB 3.0 to SATA bridge contains USB endpoints for USB Mass Storage Class
and that's it. Even if you re-programmed our device firmware, all it
could be is a USB Mass Storage Class device since the USB endpoint
number and types are fixed in hardware. We did this to make the chip as
lean as possible. It is impossible to program our chip to become a
functional networking controller or a keyboard device since we don't
support those features on the silicon.

>>>> Not All
USB Devices can be infected! Even if you managed to infect the device,
chances are you'd brick it rather than make it into something malicious.
Manufacturers are usually cost sensitive and they find ways to trim
costs everywhere they can ~ releasing general-purpose controllers for
commodity devices is, by definition, wasteful.

2) Device
manufacturers are generally very protective of their device firmwares,
since the device firmwares usually contain stuff device manufacturers
don't want other people to know about such as work-arounds for bugs in
the silicon, or proprietary algorithms which may enhance performance or
reliability, etc. The source code for most device firmwares are never
published, and even if they are, there is very little documentation or
active support. Finally, device manufacturers often have at least
rudimentary checks in place within their controllers to check if the
firmware is "valid" though these checks can vary between cryptographic
hashing to simple checksums to length checks.

>>>>>
Getting access to and mucking around with a device's firmware is hard.
Many ASICs use customized MCU cores and without published
register/programming guides, it is very difficult to reverse-engineer.

3)
Assuming that you've found a USB device controller that for some reason
can be programmed arbitrarily to support other USB classes and
endpoints and assuming again you found the firmware source code or
otherwise reverse-engineered the device's firmware, you still need to be
able to program the device. The vast majority of USB 2.0 and 1.1
devices have fixed firmwares that cannot be updated. The firmware code
is often stored on a metal layer in the silicon itself, and there is no
way for it to be changed. If the firmware is stored on an external
memory device, you still need to find a method to reprogram it, either
using (undocumented) vendor commands or using a dedicated hardware.

>>>>>
Most USB device controllers don't support being reprogrammed at all,
even if they run on firmware. Some ASIC's don't have an MCU and instead
rely purely on a logical state machine so that entire subclass is
immune. Many IC's have a MASK ROM such that the firmware program is
stored in some type of unwritable read-only medium and they are totally
immune to this attack as well.