Research and Development

This post discusses the BadUSB research published by Karsten Nohl recently at Black Hat. You might want to check out the slides and/or video before reading on.

It’s also worth noting that more recently Adam Caudill and Brandon Wilson figured out how to implement the attacks and have published proof-of-concept code which makes the challenges of defending against the original research seem somewhat more acute.

The challenges of defending against the attacks presented in the BadUSB talk largely break down into two areas:

  • Defending USB devices from tampering
  • Defending workstations and servers from bad USB devices

In this post only the latter will be discussed. However, with regard to the former, applaud the work done by Karsten Nohl. You should now be pretty wary about all your USB devices being subverted by attackers. Next time you use a keyboard or mouse that’s left lying around, you should be thinking about this research. Next time someone hands a USB stick to you, you should think if it has been reprogrammed to be a BadUSB stick. A word to our colleagues in the industry, we look forward to hearing from the USB device manufacturers about devices that can’t be tampered with in the way the researchers describe.

In the remainder of this post it has been considered how computer systems can defend or mitigate against malicious USB devices using vanilla good security practice and to what extent this is sufficient. It should be understood that this wasn’t the main crux of the research done, but as a security industry member, you should admit that it is quite interesting to consider the different USB-based attack vectors that could be used in order to gain access to computer systems as well which could be used to access a security researcher’s machine.

Defending workstations and servers from bad USB devices

If someone can plug a USB device into a workstation/laptop/server, there’s a chance that the employed USB device can subvert its normal workflow in a very clever way. The researchers Karsten Nohl and Jakob Lell presented some example attacks that were pretty innovative. Some they’ve proved work, some are just ideas for further development in this area.

The following examples can be summarised to illustrate some of the ideas outlined from their research:

  • If the USB device pretends to be a USB network interface and abuses DHCP to set a default route or a target DNS server, network traffic can be diverted to the bad guys
  • If the USB device pretends to be a keyboard it can start sending commands to a computer controlled by an attacker
  • If the USB device is left connected when the computer reboots, the computer could be attacked as it boots. The target machine may boot off it – and if the USB device is cleverly configured, the user or system administrator might not be able to detect that the device is capable of being a boot disk. Alternatively, the device might send keystrokes to modify the boot order or even modify the BIOS configuration
  • If the USB device pretends to be a USB display, it might be able to scrape what’s on a computer screen and make it available to attackers

Some of the attacks weren’t new (e.g. the Rubber Ducky has been pretending to be a keyboard for some time), but presenting these ideas together made a pretty compelling case that USB is bad.

Should we really be worried about protecting our computers from bad USB devices?

In short, yes. In some attack scenarios, these ideas really are quite worrying and and they’re pretty hard to fix or mitigate, but not in all scenarios! Some of the attacks can be mitigated fairly easily by following existing vanilla good security practice which can be found below.

Defending the boot process

Firstly we’ll examine how to protect the boot process against malicious USB devices using vanilla good security practice.

  • Configure the BIOS of computers to only boot from the internal hard disk

This should stop attackers booting off USB devices. But the bad USB device might reconfigure your BIOS to boot off some other device – specifically if it sends keystrokes during system boot.

  • Set a BIOS password to prevent modification of BIOS settings

This should make it pretty hard for anyone to boot off a USB device whether or not they are using a bad USB device. So, in short I don’t think it’s necessary to worry about your users being tricked into booting off malicious devices in this context. It’s fairly simple to secure the boot process against the attack scenario described.

Defending servers

Clearly servers are key assets and physical security controls probably provide a good level of protection already. In my experience, server rooms are access controlled – so relatively few people are allowed in and those who are have their identities checked, an access log is maintained and they might even be vetted to a certain extent first. Once they’re in, their access is (sometimes at least) restricted to only the racks they need to work in. The racks prevent the poking of usb devices into other people’s servers. However, everything in the exposed racks is certainly vulnerable to potential USB attacks.

Pragmatically, if the attacker has physical access to your server, you probably have bigger problems than a USB-based attack.

  • How to protect against bad USB devices that pretend to be keyboards?

Lock your laptop/workstation when it’s not in use. Then all the fake keyboard can do is try to log in. If the the bad keyboard doesn’t know your password, you’re reasonably safe. It could conceivably lock out your account or other AD users, but that’s not an awfully compelling attack.

  • How to protect laptops when they’re not being used?

Use a full disk encryption solution and make sure that laptops are powered down when not in use. This will make sure that a password is required to boot/resume the OS. Some of the USB attacks discussed are effective even with the host booted and the screen locked. Specifically the USB network device intercepting your traffic. Full disk encryption (FDE) is pretty essential anyway for laptops in most companies. To get the full benefit from FDE, hosts should be powered down when not in use, so this lines up with our requirement of keeping hosts protected from USB attacks by not leaving hosts unnecessarily booted and therefore exposed to attack.

  • How to protect workstations from fake keyboards?

Locking down the desktop environment

This is fairly difficult to do well, but good security practice can help to mitigate. Using lockdown technologies like group policy, SRP, app locker and kiosk software, devices can be restricted to only run the application they need to run. Clearly this is appropriate in some environments, but not in others. Corporate workstations can be and sometimes are locked down – you can’t run any old program, you can’t browse the C:\ drive, you can’t Start|Run or WindowsKey+R.

How does this help? Well, the bad keyboard is probably going to send a series of keystrokes in order to download and run some malware. If a user’s login session has been restricted, the bad keyboard’s attempt to use Windows-key+R or launch IE may not work at all.

  • Anti-Virus, Content Checkers

…and if the attacker’s going to be downloading malware, using a content checker for web traffic and having AV installed might (and I stress might) save the day.

  • USB Lockdown

This will be an interesting area to watch. Will there be a rush to buy third party software to block certain types / classes of USB device? Some vendors are claiming to protect against BadUSB attacks (but I haven’t tested their software, so am not linking to them from this post). Google for terms like “usb endpoint device control”, “usb endpoint protection” and possibly adding the term “badusb” should lead you towards what the market’s currently offering.

The idea of some sort of USB Firewall is an attractive one, particularly one that ships as part of the OS. It remains to be seen how well this could be implemented, how easily it could be bypassed and to what extent is impairs business operations.

As a closing thought, if you haven’t considered the perils of uncontrolled access to Firewire ports and PCI Express slots, maybe worry about those first.

Mitigations

Windows

Windows can help to mitigate this issue by using GPO as IronGeek described in the following post Plug and Pray Malicious USB devices

GNU/Linux: udev rules

The BadUSB attack bases itself on the fact that computers allow and enable HID devices on all usb ports. On Linux, a temporarily fix could be employed using udev to temporarily disable the addition of new HID devices as described on StackExchange by user10008 . For preparation, create a file /etc/udev/rules.d/10-usbblock.rules with the content:

    #ACTION=="add", ATTR{bInterfaceClass}=="03" RUN+="/bin/sh -c 'echo 0 >/sys$DEVPATH/../authorized'"

To block other classes, It is needed to look up the class number and substitute copy the line, and change the class. To block all new HID devices the following command can be employed:

    sed -i 's/#//' /etc/udev/rules.d/10-usbblock.rules; udevadm control --reload-rules

To unblock all new HID devices the following command can be employed:

    sed -i 's/^/#/' /etc/udev/rules.d/10-usbblock.rules; udevadm control --reload-rules

Note that before powering off the system, It is required to remove the block as udev’s setting are persistent, and thusly legitimate HID devices would be rejected on boot.

FreeBSD

The people from FreeBSD already submitted a patch to remediate this issue. The patch files can be examined at FreeBSD SVN web. This patch adds some system tunables that can be controlled by the well known sysctl.

hw.usb.disable_enumeration: 0
dev.uhub.0.disable_enumeration: 0
dev.uhub.1.disable_enumeration: 0
[...]

It should be noted that these system tunables can be also set through /boot/loader.conf

Conclusion

So with these potential mitigations in mind, let’s restate the attacks above and review how concerned we should be:

It could pretend to be a USB network interface and abuse DHCP to set your default route or your DNS server. Either way, you could end up with network traffic being diverted to the bad guys.

I am pretty worried about this attack. But it only works when my computer is booted. It even works when my screen is locked. The attacker obviously requires physical access, but that’s entirely possible in a corporate environment.

If the USB device pretends to be a keyboard it can start sending commands to your computer – as if you typed them.

This one is worth bearing in mind. It’s possible to mitigate to an extent if you prevent users from running unnecessary programs. It remains possible that your bad USB device might suddenly become a keyboard when you’re least expecting it.

Limiting the amount of time your USB device is connected narrows the attack window. But that doesn’t really fix the problem. Your keyboard and mouse are plugged in all the time, right? And are you sure they haven’t been tampered with?

If the USB device is left connected when the computer reboots, you computer could be attacked as it boots. The computer may boot off it – and if the USB device is cleverly configured, you might not be able to tell the device is capable of being a boot disk. Alternatively, the device might send keystrokes to modify the boot order or even modify the BIOS.

I’m not worried about this really. It’s possible to secure the boot process against these attacks.

If the USB device pretends to be a USB display, it might be able to scrape what’s on your screen and make it available to the bad guys.

I’m fairly worried about this one. Obviously my screen can’t be locked for this attack – if it were the attacker doesn’t really win by screenshotting the log in screen. However, if my screen is unlocked – maybe someone passes me a USB stick, this could really work.


Request to be added to the Portcullis Labs newsletter

We will email you whenever a new tool, or post is added to the site.

Your Name (required)

Your Email (required)