
Unpatchable Malware That Infects USBs - joosters
http://www.wired.com/2014/10/code-published-for-unfixable-usb-attack/
======
anemic
My dad collected some usb memory sticks from a trade show and he tried to
empty them for his own use. One of the sticks he could't use: when plugged in,
it sent keystrokes <windows key> \+ r +
[http://whatevermarketingsite.com](http://whatevermarketingsite.com) \+ enter.

So it was just a dummy usb hid device that emulates a keyboard. No exploit or
anything but a simple marketing gimmick that people take because of 'hey, a
free usb stick!'.

Here's some more info: [http://blog.opensecurityresearch.com/2012/10/hacking-
usb-web...](http://blog.opensecurityresearch.com/2012/10/hacking-usb-
webkeys.html)

~~~
chiph
A common social engineering trick is to drop some USB sticks that have
keyloggers, etc. loaded on them in the employee parking area of the target
firm. Sooner rather than later, someone will plug one into a corporate
machine...

~~~
eli
Sure, but my recollection is that depended on either Windows Autorun (which
hasn't been the default for quite a while) or people being curious/foolish
enough to execute a file they find on the drive. This is a lot more insidious.

~~~
shabble
IIRC a talk by Travis Goodspeed mentioned that it was only internally disabled
for USB and writeable media. If a USB device presents itself as a CDROM, it
can still autorun things unless globally disabled by the user.

Or it could emulate a disk + HID keyboard, and enter the win+r filename.exe
<RET> keystrokes necessary to launch it, or one of several other tricks.

It could also intercept mass storage requests, wait til you're copying an exe
onto there (even if you've reformatted the drive since), and inject a payload
into it.

~~~
TazeTSchnitzel
This is how U3 drives, when they existed, were able to work. They emulated a
tiny CD drive with an autorun bootstrap.

------
chrisBob
I have been thinking about creating an active "USB Condom" for a while, and
this might be the right time to work on it. It would be pretty straight
forward to make a device that sits between a PC and a USB device and monitors
the traffic. It could allow only certain device classes, or it could ask you
to press a button for each file moved. My original thought was to stop the
spread of viruses that are designed to move between computers over USB drives
(my last job had a lot of trouble with these), but preventing it from showing
up as a HID would also be useful in this case.

One option would be to build this into the chassis of a PC so that you know
anything plugged into the green USB port will only work as a drive.

~~~
drivingmenuts
You mean like this?

[http://syncstop.com/](http://syncstop.com/)

~~~
chrisBob
I knew someone would mention that, and I almost put a note about it in my
post. I think all that does is disconnect the data pins, so it wouldn't be too
useful when you are attaching a flash drive to your computer.

~~~
drivingmenuts
Good point.

However, if the exploit is in the bios of the usb device, you can't trust
_anything_ coming off of it. All you've got left is recharging it.

------
mmastrac
This might protect against malware infecting your device unexpectedly, but I
think there's a need for OS manufacturers to consider this as part of the
holistic security. Why not pop up a dialog when a new USB device with HID
profiles shows up that the OS hasn't seen?

~~~
Someone1234
I hate to point out the blindly obvious, but what if you need the HID device
to click on the box? So now you are stuck in a chicken/egg conundrum. You need
the HID to click the box but the HID isn't installed until you click the box,
great!

Unfortunately without going back to Windows 95-esk "please restart to install
this keyboard" world, I cannot see how you fix this. Even blackholing some
input from the HID is only at best a temp' solution (as they'd just add longer
and longer sleeps before fake HID input was generated).

I guess you could redirect all HID input to a certain context (like a Virtual
Desktop e.g. UAC prompt) until the user accepts it. However realistically most
users would ignore this warning and just click "install" without reading it or
understanding the implications.

~~~
Terr_
I have an idea: Making and breaking the USB connection _itself_ is a form of
input!

1\. Supposing all the more-convenient ways have broken down (no keyboard, no
mouse, etc.)

2\. The OS displays a random 15-60 second countdown telling the user _when_ to
unplug the device if they trust it

3\. The OS displays a second (random) countdown telling the user when to _re_
connect the device if they trust it.

4\. If both steps succeed to a reasonable level of accuracy (some fudge-factor
for humans and for slow-powering-up devices) the OS will begin trusting the
HID device and installing drivers etc.

This requires no additional hardware except for a monitor, and evil devices
cannot reliably brute-force it without taking a lot of time and being very
obvious and obnoxious about it.

~~~
freehunter
So I hand you a malicious USB stick, you plug it in, the computer asks you to
unplug it and plug it back in. You do so, because you trust the USB stick (why
wouldn't you, free USB stick!).

~~~
elsjaako
Maybe it would be better to make you type some characters on the keyboard.
Similar tricks with outher human interface devices. That way the user
physically can't do it with fake USB sticks.

It would require that all these devices have at least some basic functionality
with only some standard drivers. I don't know how true that is right now.

------
angry_octet
The only way to mitigate against these attacks is to treat the USB bus the
same way we treat the network: \- Communication with devices should only occur
once they have been identified & authenticated \- Authenticated devices can
only send type specific messages and can't change type without re-
authentication. \- Data should be written as encrypted volumes to storage
devices. (You should be doing this anyway.)

This is more like how bluetooth works. However that still leaves significant
problems for HIDs. The only solution I see is remote attestation and securing
the comms channel with encryption.

Even if USB is patched like this it doesn't solve the problem of having un-
trusted peripherals or appliances. For example, would you trust that the
signed firmware for a USB scanner is actually secure? It is quite easy for a
scanner driver to be subject to a buffer overflow caused by data from the
scanner. Scanner embedded malware could be triggered by scanning a specific
form, or anywhere it sees interesting text, like 'SECRET' headers on a page.
Networked scanner/photocopier/printers are even worse because they return PDF
documents and are serviced by outsiders, and anything on the network can often
send them a PDF to execute. I've managed to crash my printer many times by
sending large/complex PDF/postscript/PCL5.

------
EvanAnderson
Here's the talk from DerbyCon that the article is talking about:
[http://www.youtube.com/watch?v=xcsxeJz3blI](http://www.youtube.com/watch?v=xcsxeJz3blI)

------
userbinator
It's been nearly 2 decades since USB was invented and I'm still of the opinion
that USB keyboards provide no significant benefits over PS/2 in the majority
of applications today - a keyboard that is always plugged into the same port.
All the extra driver complexity and security holes like this could be avoided
if people realised this simple fact.

USB tries to make peripherals "universal" \- and I don't think one of the
primary input devices of the computer should be mixed in with the others in
this way. (Trying to troubleshoot problems with USB controller drivers when
the keyboard itself is USB can be... frustrating. The BIOS has its own USB
keyboard driver but hands control to the OS after booting, meaning that any
flaw in the rather complex USB stack can cause a loss of an important input
device. On the other hand, I've never had any problems with PS/2 keyboard or
mouse drivers.)

~~~
rbobby
> significant benefits over PS/2

Being able to unplug a keyboard and plug it back in again while the PC/server
is on without the PC/server freezing is a pretty significant benefit.

Also... though not a tech limitation... the only access point for a PS/2 plug
being at the far back of the PC case can be really annoying (though I wonder
what would happen if you had 2 PS/2 ports on a board and you actually plugged
in 2 keyboards... probably a small explosion).

~~~
userbinator
> Being able to unplug a keyboard and plug it back in again while the
> PC/server is on without the PC/server freezing is a pretty significant
> benefit.

What are you doing where being able to hotplug keyboards frequently is a
"pretty significant benefit"? If you are working with multiple servers a KVM
switch is a better solution.

(The problem with hotplugging PS/2 was that it originally wasn't designed for
that so the interface lacked the necessary protection components, but more
recently manufacturers have been realising that it's far cheaper to add the
protection components than deal with returns from those who either
accidentally or purposefully hotplug PS/2\. There's still considerable
variance between when manufacturers did this, so it's still officially "not
supported" but recent motherboards and keyboards/mouses should be robust
enough to handle the occasional hotplug.)

The PC spec also only allows for 2 PS/2 ports and no more: one for a keyboard
and one for a mouse. They use the same physical protocol so no catastrophic
effects from putting in two keyboards/mouses or switching them around, but
they just won't work since the commands are slightly different; some newer
motherboards with a single PS/2 port can detect whether a mouse or keyboard
has been plugged into it, and configure accordingly.

~~~
rbobby
I had 5 or 6 1u servers in a rack. I would roll up a monitor and keyboard
(provided by the data center folks). Twice just plugging in a ps2 keyboard
froze the server. The fix was a usb keyboard (kept in the cabinet).

A kvm would be a solution... but for the rare visit to the colo it just wasn't
worth it. One of those 1u rack mount with integrated monitor would have been
nice (though the 1/4 cabinet was the top one so I don't think it would have
worked very well).

Also with KVMs... wires and wires and wires. Blah!

------
aus_
Not to understate the severity of this issue, but how is this any different
than if I built a custom device that contained a USB hub + emulated HID
keyboard to fire off a malicious macro + flash storage housed inside a plastic
shell that looked like a normal flash drive? I guess that would require
developing and manufacturing custom hardware.

So maybe it's not different. And this just significantly lowers the barriers
to entry to an extremely easy process using only off the shelf hardware. And
now the malicious device can be anything from flash drives to keyboards to USB
Missile Launchers.

That seems like a problem the manufacturers need to resolve, however
inconvenient it is to have read-only firmware.

~~~
InclinedPlane
It's very different because your device is just one device. "BadUSB" type
malware can spread like a virus/worm by infecting other devices. In your
scenario the specially crafted device is the only infection point. With BadUSB
an infected device is just patient zero. It infects computers, which in turn
infect other devices plugged into it, which infect other computers, and so on
and so forth.

~~~
aus_
Ah! Got it now. Thanks.

Ok. Now I'm concerned.

------
kazinator
> _To prevent USB devices’ firmware from being rewritten, their security
> architecture would need to be fundamentally redesigned, he argued, so that
> no code could be changed on the device without the unforgeable signature of
> the manufacturer._

Complete rubbish. No thrusted computing is required to protect a device from
surreptitious programming by malware.

All you need is a write protect switch ("fuse") that is burned when the device
is programmed for the first time, so that for subsequent in-field updates, it
requires a physical override to enter into a programming state (the user has
to flip some switch, or hold some pin-operated button or whatever).

~~~
angry_octet
But how do you know the write protect switch actually works? Maybe the
manufacturer implemented it as a flag to the microcontroller. Maybe your
'trusted' USB stick was replaced by one that looks exactly the same but that
has a different chip inside that mimics the vendor/device ID.

So you are back to requiring trusted hardware and trusted handling, which is
impractical except for strictly controlled systems.

~~~
kazinator
The trusted USB stick being replaced by a lookalike is a breach of physical
security somewhere in the delivery chain between manufacturer and you. In that
case, the programmability issue is moot; neither the original USB stick nor
the rogue one have to have field-programmable firmware. The rogue one is hard-
coded at manufacture time to do harm.

This is a different issue from white hat USB devices that turn black due to a
remote exploit, and it is addressable by some form of trusted computing, like
authenticating that USB devices are genuine. With this authentication in
place, it's possible that there could be remote exploits that somehow retain
the device's ability to authenticate while changing its behavior.

As far as trusting the manufacturer to implement the switch: it is hard to get
away from trusting the manufacturer. You're plugging in their hardware into
your device. Under the assumption that the manufacturer is working in good
faith to prevent rogue reprogramming, it is in their interest to implement the
switch properly, so it cannot be overridden in software.

Basically, the situation is that if someone wants to sell you, say, a rogue
keyboard that steals your keystrokes, they can do that without even involving
the USB protocol. A keyboard can have its own storage for keystrokes and its
own channel for transmitting the information, not involving the USB interface.
For instance, it could have on-board Wi-Fi, and a rogue firmware that finds a
free hot-spot, makes a connection and sends its logged data to its "mother
ship".

------
S_A_P
So from my possibly naive understanding of this article the new researchers
want to publish the exploit on GitHub to ensure it gets fixed. But even they
hold off on some of the worst exploit vectors because of an ethical dilemma.
It would seem to me that any of this being published is probably as good as
all of it for bad actors to reverse engineer the exploit and then study the
usb spec and create new attacks. Just the mention of this sort of exploit is
probably enough to make someone try and find it. So they seem to be
contradicting themselves here. If it needs to be fixed and releasing will spur
the industry into fixing it, it should be published.

Is there something I am missing here? Serious question.

------
spullara
There needs to be a built-in pairing button on the computer that you have to
press to allow a new device to be activated. Sadly, it probably won't stop
this attack because when they plug it in they will just press the button.

------
sauere
Do we really need to repost this every 2 months? The first proof of concept
for this kind of attack has been demonstrated 7+ years ago at the CCC. It pops
up every year and every time people act like this is news.

~~~
fyrabanks
Source?

------
pmontra
The rule in the '80s and early '90s was never ever exchange floppy disks with
anybody and never insert other people's floppy disks in your PC. Enter the LAN
and the USB sticks, problem solved. Not.

I'm afraid we have to go back to exchanging files over the LAN. Or turn on our
WiFi cards in hotspot mode and create a LAN ourselves. There are going to be
good opportunities for desktop and mobile apps. Obviously Evernote and Dropbox
are already here but they are not exactly the same thing.

~~~
xeroxmalf
> I'm afraid we have to go back to exchanging files over the LAN.

1 horribly infected computer on a LAN can be a nightmare for everyone else
connected.

~~~
freehunter
That's the definition of a worm.

------
mark-r
Is there something in the USB spec that requires the internal processor to be
updatable? Couldn't they just lock the firmware down at the factory?

~~~
johnsmith83756
No, there's nothing in the USB spec that requires the internal processor to be
updatable. The headline is clickbait.

To get this to work, you need to solder wires onto the USB flash drive's PCB,
and then program a "burner" firmware image into the microcontroller. Only then
you can remove the wires, and further program its firmware over USB. The stock
firmware for nearly any USB device would never allow itself to be upgraded
over USB.

This strategy allows you to give someone a malicious flash drive that enters
keyboard commands into the computer (this has been done before), or infects
the computer by pretending to be a device whose driver has a security flaw. It
would not allow you to infect the other USB devices connected to that
computer, because they don't have burner firmware.

~~~
joosters
I think you're wrong: as I understand it, many of the consumer USB sticks can
be flashed over USB. No soldering required.

~~~
johnsmith83756
Yes, you're right - I've done some more research on the github site, and
figured out how they do it. The burner image can be sent to RAM over USB, to
cause the microcontroller to boot from it. Then, that burner is used to flash
the malicous firmware image.

------
Animats
This attack vector could also be used by USB charging devices. That's been
done before using Windows vulnerabilities, but this is more general.

------
trarman
Since this is like the old floppy disk days, where any disk could be infected,
would a version of the same solution apply? I'm thinking of the old boot-
sector protectors that would announce your disk is clean, thereby occupying
the space a virus would otherwise claim. Of course there would have to be
something in place to verify this wasn't just malware calling itself a
protector.

~~~
angry_octet
What this requires is called remote attestation. People have been working on
this for smart cards and embedded systems, though PCs and VMs/cloud get more
attention. It is very complex though.

[http://web.cs.wpi.edu/~guttman/pubs/remote_attest.pdf](http://web.cs.wpi.edu/~guttman/pubs/remote_attest.pdf)

------
rblatz
When I bought my last car, they sent what appeared to be a USB flash drive. It
had some warranty documents on it, and also emulated a keyboard. I think it
popped up a browser went to a webpage and prefilled my VIN and some other
details so I could register my car. This was several years ago. How is this
different?

~~~
drivingmenuts
That was probably done as an application that ran from the USB stick, similar
to the way AUTOEXEC.BAT works on Windows (it sees it on mount, it runs it).

I think the exploit version occurs at a lower level down in the bios of the
stick, where it's far more insidious.

~~~
rblatz
I thought I remembered windows saying it detected a new keyboard device, or my
brain may have invented that part. I'll see if I can't find it laying around
and see how it actually worked.

------
mariusz79
Have usb device supply some kind of a checksum/key of its firmware when
connecting to the computer.. the driver would then compare that checksum/key
to the list of trusted checksums. But of course, hackers could extract the
checksum from the driver, and hack the firmware to always return it :/

------
ambrop7
> showing that it’s possible to corrupt any USB device with insidious,
> undetectable malware

That is surely false. It depends on the type of microcontroller used and its
configuration. And indeed the github link in the article is only for certain
types of USB flash drives (Phison 2251).

------
greedo
USB is just so vulnerable... Kali Nethunter is now exploiting some of its
idiocy.

[http://www.kali.org/kali-linux-nethunter/](http://www.kali.org/kali-linux-
nethunter/)

~~~
verbatim
Is USB vulnerable or are many USB implementations vulnerable?

------
jorgem
Can't some of this be patched at the USB driver level in the OS? A storage
device shouldn't be acting like a keyboard, etc.

~~~
Someone1234
That's not how this works.

The device acts like a USB hub which happens to mount both a keyboard and a
USB drive.

So unless you ban all USB hubs then this isn't workable.

~~~
jdmichal
Banning USB hubs isn't really workable either. Any keyboard which has USB
slots would be blocked, for instance.

------
methodology
USB devices need to be regulated to ensure this kind of thing can't happen.
Perhaps the FCC's arm reaches far enough that they could tackle this issue,
otherwise maybe a separate task force should be created for this.

------
kalleboo
Am I the only one cringing at the use of the lone term "USB" to describe "USB
flash drives" in this article? I would have expected more from Wired.

~~~
nobodysfool
Because it's not just USB flash drives. Any device, a cell phone, a mouse, a
webcam, anything that connects via usb, could essentially connect as a USB HID
(human input device) and start issuing commands on the computer as if it were
a human. But that's not the only thing it could do. You should read the
article.

~~~
kalleboo
> Because it's not just USB flash drives

As for the actual flaw, yes that's true. But that's not what this article is
talking about.

> You should read the article.

I did. It says:

> “People look at these things and see them as nothing more than storage
> devices,” says Caudill. “They don’t realize there’s a reprogrammable
> computer in their hands.”

It's clearly talking about the storage devices. If they were talking about the
bus protocol they'd say "USB is nearly impossible to secure in its current
form" instead of "USBs are nearly impossible to secure in their current form"

~~~
eli
I think you're being kinda pedantic. It's like people who write "ATM Machine."
It's wrong, but it's not a big deal and the reader understands what they're
saying.

~~~
kalleboo
> I think you're being kinda pedantic

Possibly. I wouldn't care if it was speech. I wouldn't comment if it was a
regular newspaper. But WIRED writing like this?

~~~
eli
I used to really enjoy Wired in the pre Conde Nast days....

------
parktheredcar
Why so many Wired Magazine articles lately?

~~~
JustSomeNobody
Somebody catching up on their reading, maybe?

