BadUSB Device Blocking
Since many years it is a known threat that a bad USB device can act as a USB keyboard and therefore send keystrokes to Windows for doing bad things as downloading and executing malware from the internet.
In 2014 the German company Security Research Labs showed at the Black Hat conference that it is possible to reprogram widely spread USB controller chips also used in flash drives to turn them into evil "BadUSB" devices. Meanwhile Adam Caudill and Brandon Wilson have published all required tools for creating a BadUSB device. This is a new quality of the problem.
The main attack scenario is a USB pen which acts as a keyboard device so it can issue commands on behalf of the logged-in user.
Under Windows XP this can be completely blocked by moving or changing the file extension of the C:\Windows\inf\keyboard.inf file. As long this is not present there will be no new keyboard device installed.
Since Vista new devices of certain device classes can be blocked, just search for DenyDeviceClasses.
Here is a REG file which blocks all new keyboard devices under Vista, Win7 etc: DenyNewKeyboards.reg
A bit more handy is what USBDLM does: It prepares a new USB keyboard device for safe removal immediately after arrival and asks the user if it shall be activated again. There is a short moment while keystrokes are accepted but this is by far not long enough to open a command prompt and write and start an evil script.
There is no check if there is any other input device which of course the user needs to answer the question. If required the user can bring a USB mouse...
[Settings]
BadUsbWatchKbd=1
- BadUsbWatchKbd=0 -> USB keyboard devices are installed normally (default)
- BadUsbWatchKbd=1 -> The user is asked on arrival of a USB keyboard device
- BadUsbWatchKbd=2 -> On arrival any USB keyboard device is silently prepared for safe removal
Of course the remaining attack scenario is a real USB keyboard which can perform evil key sequences. But this is true since keyboards exist, USB or not.
There is also talk about USB network adaptors which could manipulate DNS requests and/or the IP-Routing. USBDLM can block them too, the setting works equally to BadUsbWatchKbd:
[Settings]
BadUsbWatchNet=1
Title and text of the message box can be changed. Sample:
[Settings]
UsbKbdMsgTitle=USBDLM
UsbKbdMsgText=USB keyboard device attached. Activate?
UsbNetMsgTitle=USBDLM
UsbNetMsgText=USB network device attached. Activate?
White and blacklisting of device ids and USB ports
To not being asked again and again for known non-evil devices, e.g. a WiFi adapter, you can whitelist them by device id. Sample
[BadUsbWhiteList]
DeviceID1=USB\VID_057C&PID_5601
The device ID must be the one of the device with the device class keyboard or net respectively. UsbTreeView shows it.
Sample for what UsbTreeView shows for a USB composite device with an HID keyboard:
Child Device 1 : USB-HID (Human Interface Device)
Device ID : USB\VID_05FE&PID_2001&MI_00\8&1D9FC75B&0&0000
Class : HIDClass
Child Device 1 : HID Keyboard
Device ID : HID\VID_05FE&PID_2001&MI_00\9&2594D27D&0&0000
Class : Keyboard
Use the bold part only because the last part changes on each port if the device has no USB serial number.
Furthermore it might be handy for instance to say that real USB keyboards are attached at the back side ports of an PC, so these are whitelisted. Sample:
[BadUsbWhiteList]
UsbPort1=1-1
UsbPort2=1-2
UsbPort3=1-3
UsbPort4=1-4
UsbPort5=1-5
UsbPort6=1-6
Or you say that keyboard or network devices are never ever attached to the front ports. Sample:
[BadUsbBlackList]
UsbPort1=1-7
UsbPort2=1-8
For blacklisted devices or ports the user is not asked, the devices are silently prepared for safe removal. The blacklist is checked first, so it has a higher priority than the whitelist.
To determine the port names you have to attach a USB drive to each port and check the port name by means of the UsbDriveInfo tool. For non-USB devices you need UsbTreeView.
The first digit of the port name is the index of the root hub which can change when a USB controller is added or removed. Use the long notation then, see Letters by USB Port. Furthermore most USB2 controllers use separate logical root hubs for USB1 devices, so the index is different here too.
Deficits:
USBDLM handles newly attached devices only. If a BadUSB device is attached before logon then it will work normally but will play its bad keystrokes on the logon screen where they will not work.
The problem with present devices is that USBDLM cannot know which one is the regular keyboard. Disabling it would lock out the user...
White and Blacklists work too if no user is logged on and the USBDLM service already running on arrival of the device.
Plans:
- MessageBox at a random position if the USB device comes with a mouse too and thus could click the Yes button on the MessageBox
Links:
BadUSB article at arstechnica/
Presentation at Black Hat 2005 - Barrall-Dewey
After reading the Presentation from Black Hat 2005 you know that the problem isn't new at all and that USBDLM can block only the most simple USB attacks.
Hopefully Microsoft has hardened all their drivers involved with USB devices against these attacks...