BadUSB – On accessories that turn evil [pdf] | Hacker News Reader

BadUSB – On accessories that turn evil [pdf]

srlabs.de

84 pointsthefreeman24 comments

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?

> This is how the PS2, I think, was sucessfully rooted/unlocked/made-linux-run-on-it.

This was the PS3, actually.

Technical details here : https://web.archive.org/web/20120829232220/http://ps3wiki.la...

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.

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.

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.

> 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.

...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.

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

> ...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?

> are there boot orders that put USB first?

There was a time when I noticed it was getting more common and looked to be destined to be the default option, I assume it went back to being less common as people complained about it being inconvenient when they left a stick in that just happened to have a valid boot signature.

Modern chipsets have a nice convenient "press <key> for boot menu" which makes having the boot order right for anything other than the business-as-usual option (SATA first) easy to access anyway.

On most PC's in BIOS (or UEFI) you can set the default boot order however you want, to prioritize USB, HDD, CDROM, Network, even floppy still.

This has been the norm for about 10years at least, so that way you get the boot order best for your usage.

Aye, I was saying the need to go in and change it has fallen away (unless you always want something different) as there is generally an easier short-cut to make a change just for this boot.

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

not if you 'lose' couple of those pendrives labelled payroll in the parking lot - this is old cd/dvd attack vector, but this time its interactive courtesy of smarts in the firmware.

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...

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".

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 :)

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.

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?

This remainds me of sd card hacking: https://www.youtube.com/watch?v=CPEzLNh5YIo

arstechnica article on it: http://arstechnica.com/security/2014/07/this-thumbdrive-hack...

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?

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".

No, USB keyboards (or mice) can't. That's why some keyloggers use a certain sequence of capslock/numlock/scroll-lock presses to trigger output of a menu or the stored data: The status of the corresponding LEDs is the only information a PC sends to a keyboard.

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

Reply on news.ycombinator.com