[Discuss] code for hacked USB drive (BadUSB) released on Github

[tmetro+blu at gmail.com (Tom Metro)]

Chuck Anderson wrote:
> Tom Metro wrote:
>> I don't think it can pose as both simultaneously.
> 
> Why couldn't it pose as both simultaneoulsy?

As Drew pointed out, a bus reset is required to get the host computer to
recognize it as a new device.


> Couldn't it embed a USB hub to present more than one device id to the host?

That may be possible too. Definitely the case if you are fully
customizing the hardware in the USB drive. But it may be beyond what the
 existing controller chips in cheap USB flash drives can do.


> I wonder if the OSes can be tweaked to refuse new USB keyboards/mice
> after the first one has been connected.

You wouldn't necessarily want that either, as on a laptop you often
attach mice and keyboards that duplicate the built-in hardware, but the
OS could compensate for that by adjusting its rules when on a laptop.

How you defend against this attack vector will probably vary over time.
You'd expect that eventually the chip vendor will redesign their product
to require digitally signed firmware, or at least make it so it can't be
reprogrammed over the USB port.

Another short-term fix the researchers mentioned in their talk was
dumping the firmware and comparing the hash of it to a list of known
good values (which the vendor could publish). Though it is less clear
whether you can extract the firmware without giving malicious code a
chance to run.


Richard Pieri wrote:
> ...my quick perusal of how the BadUSB code works indicates that
> it does not do anything of the sort. It's an all or nothing change. It
> may be possible to use the BadUSB code to make some devices work as 
> you describe but the code as it currently is does not appear to do so.

It may be true that their released sample code doesn't demonstrate how
to pull off a personality switch, but that was the primary attack method
described by both these researchers and the ones that proceeded them
(and inspired them).

Give it a few weeks. The code will be out there.


> Rubber Ducky is a different thing entirely. It's actually a full
> computer on a thumb-sized circuit board. As such it runs a software
> stack that can emulate different device classes and present virtual 
> mass storage devices to hosts. The same thing that Android devices do.

They're all "full computers" by some definition. :-) I would expect the
Rubber Ducky to have a beefier micro controller, but I don't know that
to be the case.

I did notice in the talk the researchers point out how the common chips
in the USB thumb drives used paged loading of their firmware (presumably
from the flash chips), and thus you could load them up with a lot of
complex code.

 -Tom

-- 
Tom Metro
The Perl Shop, Newton, MA, USA
"Predictable On-demand Perl Consulting."
http://www.theperlshop.com/