7 ms·

BadUSB – On accessories that turn evil [pdf]

84 points by thefreeman 12y ago

raesene3 12y ago
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=UUJ6q9Ie29ajGqKApbLqfBOg https://www.youtube.com/watch?v=nuruzFqMgIw&list=UUJ6q9Ie29a...
j_s 12y ago
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
sobkas 12y ago
This remainds me of sd card hacking: https://www.youtube.com/watch?v=CPEzLNh5YIo https://www.youtube.com/watch?v=CPEzLNh5YIo
biggerfisch 12y ago
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 12y ago
  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".
- cnvogel 12y ago
  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.
canvia 12y ago
arstechnica article on it: http://arstechnica.com/security/2014/07/this-thumbdrive-hacks-computers-badusb-exploit-makes-devices-turn-evil/ http://arstechnica.com/security/2014/07/this-thumbdrive-hack...
asdffdsajkl 12y ago
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 12y ago
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?
- kelmop 12y ago
  sure, your device can mimic keyboard.
deathanatos 12y ago
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.
- dspillett 12y ago
  > 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.
  - danelectro 12y ago
    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.
    - dspillett 12y ago
      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.
leni536 12y ago
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 12y ago
  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 :)
cnvogel 12y ago
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?

84 points by thefreeman 12y ago

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=UUJ6q9Ie29ajGqKApbLqfBOg https://www.youtube.com/watch?v=nuruzFqMgIw&list=UUJ6q9Ie29a...

j_s 12y ago

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

sobkas 12y ago

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

biggerfisch 12y ago

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 12y ago
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".
cnvogel 12y ago
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.

canvia 12y ago

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

asdffdsajkl 12y ago

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 12y ago

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?

kelmop 12y ago
sure, your device can mimic keyboard.

deathanatos 12y ago

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.

dspillett 12y ago
> 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.
- danelectro 12y ago
  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.
  - dspillett 12y ago
    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.

leni536 12y ago

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 12y ago
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 :)

cnvogel 12y ago

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?