8

Have any devices been released which protect against BadUSB attacks?

I'm particularly interested in buying a USB hub which has the following protections:

  • The USB hub itself won't allow reflashing of its own firmware or will at least require new firmware updates to be signed with a strong cryptographic key (>2048bits RSA).
  • The USB hub will not allow firmware write commands to devices connected to it.
  • The USB hub will have single or dual/purpose ports:
    • "Block device" ports which only allow devices plugged in here to act as block devices.
    • "Keyboard" ports which only allow devices plugged in here to act as a keyboard.
    • "Mouse" ports which only allow devices plugged in here to act as a mouse.
    • "Keyboard/Mouse" devices which allow devices plugged in here to act as both a keyboard and a mouse, think a hybrid keyboard/mouse combo.
    • "Other" ports which allow things to be anything other than a block device, keyboard, or mouse. Think Bluetooth dongles, cameras, microphones, etc.

Have there been any hardware devices which do something similar to this to defend against BadUSB?

Naftuli Kay
  • 6,745
  • 9
  • 47
  • 76

2 Answers2

3

I hope someone will contradict me with solid arguments, but "The USB hub will not allow firmware write commands to devices connected to it.": this seems to be the wrong assumption which makes all the hardware BadUSB protection system to vanish.

There is indeed a related and very informative post: How to check if my USB stick firmware can be rewritten via the USB port?. One could learn there that there is no generic "write" command: each vendor use their own commands for this purpose. Even worse: with some vendors we should more talk about "tricks" than actual commands, LvB mentions "USB stick's or USB HDD's that when written to an extreme address instead of writing it to disk, write it to the internal memory".

How could such a hardware filter something which cannot be detected and is just part of the normal device communication flow?

WhiteWinterWolf
  • 19,142
  • 4
  • 59
  • 107
  • If that's the case, then USB as a whole needs to go. – Naftuli Kay Aug 18 '15 at 22:04
  • @NaftuliTzviKay: or maybe at least crappy (creepy?) implemented update features needs to go: reserve update functionality to device able to handle it correctly, and remove update functionality from all dumb devices for which there will most probably be never any published updates anyway. BTW following your message I've created a new question wondering [why there was this update feature in the first place](https://security.stackexchange.com/q/97246/32746). – WhiteWinterWolf Aug 19 '15 at 15:51
  • Simple solution: the "firewall" will only allow whitelisted commands to pass, none of which will be a firmware write command - unless a particular device uses an unusual case of a normal command (e.g. writing to block number 0xFFFFFFFFF...) – user253751 Sep 18 '15 at 02:32
2

I think this is not possible by design. When USB was invented it was made to replace cumbersome communication methods like parallel and serial cables, proprietary interfaces with a standardized cable and plug. It would also address programming issues by standardizing the lower layer driver model so that drivers could be programmed more easily.

Finally I would say USB exists because of it hotplug capabilities. This for sure is one of the most comfortable features of todays computers. I remember what pain in the ass it would be if you forgot to plug in the keyboard at boot time (server for example): Some of them needed a complete reboot to detect the PS/2 keyboard at all.

Nobody was thinking of security issues by that time. USB sticks were not existing, and all devices connected to USB were more or less stupid. So USB does not use standardized ways of flashing firmware or detecting "illegal" behaviour.

A USB hub is a really stupid device: It handles the hot-plug-insertion of a new device into the communication (AFAIK by shortly interrupting forcefully all others) and the removal. It can see what are the power requirements of a device and forbid a new device to become online if it draws too much power. That´s mostly all, and it´s OK like that: They can be cheap and very fast.

A USB hub will not inspect the data that´s passing through, nor will the controller. It is simply not designed to do it, and this is not written in any specification. One could argue now that restricting port use to only allow certain classes could be compatible with the specs BUT: Class devices are also complicated: Think of a combined mouse/keyboard wireless transmitter. It will show up as multi-device, exposing both a mouse and a HID component. Most of them can run with basic OS drivers, but also can be used with specific vendor software to permit enhanced features like additional function keys or high DPI rates. I love my Roccat gaming mouse for havin 3200 dpi for example. So after being registered as a class device, it somehow switches mode if the right driver is installed on the PC.

All other stuff must be handled by the OS. Allowing a driver load or not is fully in the hands of the OS core. There is software on the market to control the use of USB ports which could behave in the way you want.

IMHO you try to fix the wrong problem: If you are concerned about USB safety, you should simply turn off all USB ports or find/demand operating software that can achieve the policies you want on the OS level. Linux for example, could be restricted to use only cvertain USB drivers via a custom kernel.

flohack
  • 547
  • 3
  • 8