

BadUSB – On accessories that turn evil [pdf] - thefreeman
https://srlabs.de/blog/wp-content/uploads/2014/07/SRLabs-BadUSB-BlackHat-v1.pdf

======
cnvogel
I think the "no effective defense" slide (#20) is kind of disappointing. Their
whole talk, for me, circles around the "someone plugs in a USB device with
surprising functionality" narrative... And there are two possible things that
can go on. First, the device could try to exploit flaws in parsing of USB
descriptors. This is how the PS2, I think, was sucessfully
rooted/unlocked/made-linux-run-on-it.

But the talk linked to mainly focuses on the second possibility: "the OS
automatically loads the driver for keyboards and network adapterse", and this
is trivially defended against, at least on Linux. I assume you can do
similar/identical things on other operating systems (e.g. Windows probably has
a registry key for that, because it always has registry keys for
everything...)

    
    
            # echo 0 >/sys/bus/usb/drivers_autoprobe
    

Now, no drivers are bound to USB devices automatically. Just try it. I plugged
in peripherals into the computer, the only thing you'll get (running
3.15.8-1-ARCH, archlinux x64) is the following text in the dmesg:

    
    
            [ 6765.949361] usb 5-1: new low-speed USB device number 3 using uhci_hcd  **mouse**
            [ 6846.469357] usb 6-1: new high-speed USB device number 3 using ehci-pci **harddisk**
            [ 7062.616021] usb 7-4.4: new high-speed USB device number 7 using ehci-pci **eth/network**
    

Now, if I am convinced that one of the devices hasn't been tampered with, I'll
run the following command, that triggers automatic probing for a single USB
device (1.0 is configuration 1, function 0, I think...)

    
    
            # echo 7-4.4:1.0 >/sys/bus/usb/drivers_probe 
    

dmesg shows....

    
    
            [ 7193.076584] ax88179_178a 7-4.4:1.0 eth0: register 'ax88179_178a' at usb-0000:00:1d.7-4.4, ASIX AX88179 USB 3.0 Gigabit Ethernet, 00:0a:cd:22:b4:40
            [ 7193.099754] systemd-udevd[10470]: renamed network interface eth0 to enp0s29f7u4u4
    

But if I only want to allow USB storage devices, I can manually bind to the
usb storage driver.

    
    
           # modprobe usb-storage # was not loaded on my machine, yet...
           # echo 1 >/sys/bus/usb/devices/6-1/bConfigurationValue  # enable 1st configuration
           # echo 6-1:1.0 >/sys/bus/usb/drivers/usb-storage/bind 
    

dmesg, again...

    
    
           [ 7583.801824] usbcore: registered new interface driver usb-storage
           [ 7729.898188] usb-storage 6-1:1.0: USB Mass Storage device detected
           [ 7729.898404] scsi6 : usb-storage 6-1:1.0
           [ 7730.900552] scsi 6:0:0:0: Direct-Access     TOSHIBA  MK4309MAT        G5.0 PQ: 0 ANSI: 0 CCS
           [ 7730.904913] sd 6:0:0:0: [sdd] 8452080 512-byte logical blocks: (4.32 GB/4.02 GiB)
    

Now, this of course is completely ridiculous, from a user-interface
perspective, but, I think if you only want to cover mounting of USB sticks,
you can script this in shell/perl/python/awk, using "lsusb -v" for parsing the
binary USB descriptors and only start usb-storage on USB sticks.

 _EDIT_ / _ADDED_ : -----

And also note: The mechanism described above concerns the binding of drivers
to devices. There's a different facility in place to make USB devices
inaccessible to the drivers/the user, and that's using the "authorized" flags:
You set the "autorized_default" flag in /sys/bus/usb/devices/usb<N> to 0, then
every device that is connected to the machine is initially disabled:

    
    
           [ 9162.809251] usb 7-4.4: new high-speed USB device number 11 using ehci-pci
           [ 9162.912337] usb 7-4.4: Device is not authorized for usage
    

If you are sure that this particular device is allowed to connect, authorize
it...

    
    
           # echo 1 >/sys/bus/usb/devices/7-4.4/authorized 
    
           [ 9214.302656] ax88179_178a 7-4.4:1.0 eth0: register 'ax88179_178a' at usb-0000:00:1d.7-4.4, ASIX AX88179 USB 3.0 Gigabit Ethernet, 00:0a:cd:22:b4:40
           [ 9214.302678] usb 7-4.4: authorized to connect
           [ 9214.326028] systemd-udevd[10771]: renamed network interface eth0 to enp0s29f7u4u4
    

That way, you could have the publicly accessible USB connectors (say... usb2
and usb4) in "autorized_default=0" mode, and the internal USB connectors, or
the ones on the back of a device that is somewhat physically secured set to
"autorized_default=1" to not impede usage and comfort... But, of course, if
you have scripts in place implementing a "USB ACL", that doesn't really sound
as if it's worth the added complexity?

~~~
pdkl95
USB devices that can attack the host computer have been known for some time,
and are not the point of the talk. The demonstration methods of attack that
use them are only examples. This threat is about the other direction, where
the (compromised) kernel attacks the USB devices firmware.

Nothing the kernel can do defends against the BIOS trusting the mass storage
device and booting from it (possibly with an extra HID to press F2 or F12 or
whatever to enable the correct boot order), which was covered in the talk.

Also, there's nothing the kernel can do to detect a device that is modifying
the data during some of the reads, which was also discussed.

More importantly, it doesn't matter what a handful of technical people do to
try and defend their own computers: there is currently a _very_ large set of
users that are currently wildly vulnerable running Windows or stock-and-
never/rarely-updated Ubuntu. These people like to use their devices in the
manner in which they were intended to be used. This has the potential to
spread malicious firmware very quickly.

The main vulnerability this talk was trying to demonstrate was not that the
USB port on a traditional computer has poor defenses; they are showing that
USB devices are easily re-flashable; _any_ USB hardware could _become_
infected, closing the loop.

This possibility of recursive infection over sneakernet suggests that _normal,
non-technical people_ need to learn to not trust any kind of shared USB until
new devices with unchangeable firmaware can be made.

~~~
cnvogel
I agree that the current default config in popular operating systems (I.e.
what normal non technical people use) is insecure and needs to be fixed. It's
just that the defense, in my opinion, is not difficult at all.

The main attack vector given by the talk is: device with an additional,
unexpected, function. That's the USB stick emulating a keyboard, or the
smartphone presenting a network device (which, by the way are functions
legitimately found on real hardware).

And the only defense against this is a stricter policy on what a computer will
talk to, which again technically is binding of drivers. This defense can be
implemented rather trivially.

The fact that a malicious payload itself reflashes the target is really a very
nice hack, and I don't want to belittle this in any way... But in the end,
considering the huge amount of updates everybody installs all the time, it's
not surprising at all. I have several devices that reflash the connected
device to match an updated driver... Of course we are not used to USB sticks
doing that, yet.

The BIOS is a different problem, and I have no easy solution for that. But in
my opinion it's not as important, because in the normal use case (of the non
technical user) an OS is running. (And in fact, e.g. on some cromebooks, the
keyboard isn't even looked at to boot faster if a special button isn't
pressed... So this could be a solution.).

A harddisk/stick tinkering with returned data is indeed one of the more
interesting things, and has been used to root some devices that first verify a
file, then read it again to execute it... But that deserves a completely
different defense and itself isn't the topic of this discussion.

------
deathanatos
To some extent, this feels like the old "if you have physical access…"¹ rule.

It is good to see more awareness of the fact that USB devices can be quite
arbitrary things. I remember trying (hard) to convince people that a cell
phone was a computer years ago. It's basically the same thing: a USB device
can certainly house a computer, for some definition of that.

It would seem that page 11's attack would require that the machine is unlocked
and just sitting there. If not, how would it install the keylogger? (It'd be
at the password screen, and input would go there.) Otherwise, this is simply a
shortcut to install a keylogger and capture sudo. (Which again brings us back
to "physical access".)

Page 13: Are there really that many distros that just DHCP any interface?
Gentoo (at least mine, I suppose? it is configured by the user, but I thought
I chose the defaults here?) doesn't?

Page 17: are there boot orders that put USB first? I feel like HDD is almost
always first, given the number of times I need to beg for a prompt in BIOSes,
but again, maybe just me?

However, if anything, the above does show how much of a minefield this is…

¹then it's really hard to be secure.

~~~
Nanzikambe
> To some extent, this feels like the old "if you have physical access…"¹
> rule.

Do you completely trust the manufacturer, previous owners and every person
that ever had opportunity to touch any of your USB devices for more than a
couple seconds? (Including before you purchased them)

> It would seem that page 11's attack would require that the machine is
> unlocked ...

No, many Linux distributions have a daemon that will auto mount USB mass
storage devices.

~~~
gpvos
...but how will it install the keylogger then? The USB device can do that if
it's a keyboard, but not if it's a mass storage device.

~~~
cnvogel
...keep in mind that a USB device can be both, or more...

~~~
deathanatos
> ...keep in mind that a USB device can be both, or more...

Fine: let's assume the device can fake being both, or more (which it can), and
that my machine will automount any USB mass storage device. (I actually think
this is accurate.)

So it automounts the USB mass storage device somewhere… and then what? The
machine is still locked, and I presume it would need to run something off that
mass storage device to do any real harm, but how would it accomplish that?

------
raesene3
The Video is also up on Youtube and adds quite a bit to the slides including
some good demos

[https://www.youtube.com/watch?v=nuruzFqMgIw&list=UUJ6q9Ie29a...](https://www.youtube.com/watch?v=nuruzFqMgIw&list=UUJ6q9Ie29ajGqKApbLqfBOg)

------
leni536
Once you can install arbitrary programs on a device (or a single program, the
firmware) you should treat these devices with a general mistrust.

The main problem here that you can't use your usb devices at public places
safely, since they can patch your usb device's firmware at will. The problem
here that you use your trusted usb device on a not-trusted computer which can
do anything it wants with your device's firmware. There should be an approval
mechanism directly, physically on the device to prevent this.

For example on usb thumb drives there could be a switch on the device which
turns it to "firmware upgrade mode".

~~~
rasz_pl
there are ide/sata/usb write blockers, but they would need to be modified to
filter specific custom SCSI commands used for firmware update.

Best defence for this kind of attack is running your own firmware on all USB
devices :)

------
asdffdsajkl
Really the key thing to focus in here, IMO, is the fact that arbitrary USB
hardware firmware can be overwritten - anything taking place after complete
control of the USB hardware has already been exploited and well documented;
for example the teensy device and the usb rubber ducky.

------
iwalton3
I can think of 2 solutions to this issue offhand.

\- Accept general input from a keyboard or mouse only after the user's
password has been entered into a confirmation window. (Even just a yes/no
would work here.) \- Change all key shortcuts and menus that can execute
things (WinKey+R, Alt+F2, etc.) to something nonstandard. You could also
remove them altogether or prompt for a password if afraid of a targeted
attack.

The question then becomes this: Are there other attacks that can use USB to
execute code beside mimicking input devices?

------
sobkas
This remainds me of sd card hacking:
[https://www.youtube.com/watch?v=CPEzLNh5YIo](https://www.youtube.com/watch?v=CPEzLNh5YIo)

------
canvia
arstechnica article on it: [http://arstechnica.com/security/2014/07/this-
thumbdrive-hack...](http://arstechnica.com/security/2014/07/this-thumbdrive-
hacks-computers-badusb-exploit-makes-devices-turn-evil/)

------
biggerfisch
Sorry for the silly question, but the slides seemed to indicate that any USB
keyboard can read any other keyboard's keystrokes? Is that a correct
understanding? Otherwise, I don't see how they can steal passwords. Am I just
missing something obvious?

~~~
tedunangst
Their evil keyboard runs commands to install malware which capture your
password when later entered on the good keyboard. i.e. Their keyboard types
"install keylogger".

------
j_s
Here is the speculative discussion from one week ago based on the summary of
the talk before it was given at BlackHat today:

[https://news.ycombinator.com/item?id=8112942](https://news.ycombinator.com/item?id=8112942)

