Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

What can I do to protect my linux laptop from BadUSB attacks as described here? Perhaps writing an appropriate apparmor profile would help?

share|improve this question
1  
Since nobody answered about AppArmor, no it would not help. AA adds access control for userland processes, not for firmware code which AA is not even aware of. –  Steve DL Oct 8 at 14:56

4 Answers 4

The BadUSB attack bases on the fact that computers allow and enable HID devices on all usb ports. Faked network adapters are no real danger. My answer tries do describe how to use udev to temporarily disable the addition of new HID devices. I'm no udev expert, but I've tested my approach, and it works for me.

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

If you want to block other classes too, then look up the class number, and copy the line, and change the class.

Now you can block all new HID devices using the command

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

and unblock with:

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

Before you shut down, always unblock, as the setting is persistent, and your "good" HID devices would be rejected on reboot.

I don't know whether you can edit the temporary rules directory, but if changes there affect the behaviour, you should edit that instead, as then you don't need to unblock before shutdown.

share|improve this answer
2  
+1, this is the only comment that actually answers OPs question –  eric_lagergren Aug 3 at 5:34
    
Can you give some details on the time based approach? –  student Aug 3 at 13:37
    
@user53541 tried to comment but can't due to reputation limit so he had to resort to editing to talk to us. Rejected edit, but adding comment for him: "It can't work to authorize device using interface class number, the interface device will not be created if the device is not authorized." –  Luc Aug 9 at 7:51
1  
@user53541 He's right, I've now tested a new approach: authorized per default, and if there is an interface with class 3 added, the device gets de-authorized. I'll edit my answer accordingly. Hey user53541, do you want to answer it yourself? Its obvious that I'm new to udev, so perhaps you have a better solution in mind. –  user10008 Aug 9 at 18:41

The idea behind BadUSB is that a malicious agent re-flashes a device's USB controller chip to do something nasty. This is an interesting possiblity, but there are some serious assumptions here that people tend to gloss over:

1: The USB controller chip has to allow firmware flashing over the USB connection

This is a security vulnerability for sure if it's possible. If this is allowed, then any host that the device is plugged in to can permanently alter the characteristics of the device. Generally this requires special equipment and direct access to the chip's physical pins, but if a manufacturer decided to expose the functionality over the USB protocol, then that is cause for alarm in itself, and should be reported as a vulnerability in that product. It is not, however, a flaw in the protocol itself.

The fact that 3 of the 4 scheduled demos involve chips from Phison Electronics suggest that the researcher discovered just such a vulnerability in a specific product.

2: The device has to be physically capable of the activity you're attempting

By flashing your device's firmware, you can get a thumb drive to report itself as a network adapter. But that doesn't make it actually a network adapter, it just means that the computer will talk to it as if it was one. So now your computer starts talking to your Verbatim Store-n-Go using the driver for the D-Link DUB-E100. But unless the Store-n-Go has the corresponding hardware interface found in the D-Link, all you have is broken USB stick.

If the USB stick has a relatively powerful microcontroller on board, you might be able to re-program it. But "powerful" and "USB peripheral" don't usually go together.

3: The computer has to be willing to play along

One of the examples cited is teaching a device to act like a network adapter, and then assuming that all traffic will be looped through it on any computer you plug it in to. That's... a stretch. To make that happen, your computer has to be already configured to set any newly connected network adapter as the new default gateway. I'm not sure if Windows is that eager for change, but if you've ever configured networking on a Linux computer, you know that it's never that simple.

The Take-Away

This whole concept isn't all bunk. If a device allows re-flashing by any connected host, that's an issue. I can safely state with 100% certainty that it won't lead to the calamities pushed by the associated breathless news articles. But it's worth attention.

And more importantly, USB is powerful, and powerful means potentially dangerous. Connecting a device over USB necessarily means altering the way your computer behaves, and very, very dangerous things are possible. We've known this since the 90's. Use all due caution when attaching things to your computer. But this new discovery changes very little; the new attacks possible here aren't nearly as powerful as what already exists, the new danger is that it blurs the line between "trusted" and "untrusted" devices.

share|improve this answer
1  
Another very real use case for pretending to be a different device is to exploit a vulnerability in a driver for that device. The potential for such a bug is big, as you can send data that the driver was never designed to handle. This is especially tempting as exploiting a driver can give you an express route to privilege escalation. If you find such a bug in a driver that's included with the target operating system, you will also have good coverage. –  nitro2k01 Oct 3 at 3:58
1  
Unfortunately, it's not uncommon to find USB mass storage drives with reprogrammable controllers. I actually have a bunch with Alcor controllers right here. But there are many different controllers, and your modified firmware would have to be different for each controller - making self-propagating attacks infeasible at best. And if you don't need that then you might as well just use special hardware physically disguised as a flash drive. –  Bob Oct 6 at 13:29

BadUSB isn't an attack. It's a tool used when designing attacks.

When you plug a USB device into a computer, the device tells the computer what sort of thing it is, so the computer can select the appropriate driver. For example, a thumb drive declares itself as a "USB Mass Storage" device, while a keyboard is a "Human Interface Device".

BadUSB is a technique for re-writing the firmware of a plugged-in USB device from the computer. For example, it could make a thumb drive identify itself as a mouse and cause the pointer to jump around at random. Or it could make the thumb drive identify as a USB hub with connected keyboard and mass storage, that when plugged in types a sequence of keystrokes that causes a program on the thumb drive to be run.

The novel thing here isn't making USB devices that aren't what they look like -- intelligence agencies, cybercriminals, and others have been doing this for years. The novel thing is that this can be done to commodity hardware over the USB connection, opening the door to self-propagating systems, such as a virus that writes itself to any thumb drive that's been plugged into the machine, then modifies the drive's firmware to try to run the virus any time the drive gets plugged in.

This is a hard thing to defend against, since it operates on such a low level and is so flexible in what an attacker can do with it. On a Linux system, one thing you can do is ensure that all removable media are mounted as "noexec" -- this prevents programs on them from being run, and makes attacks harder. You can also check the USB device tree any time you plug something in, to see if anything unexpected has shown up.

On a non-technical level, avoid using any USB device that's been plugged into a possibly-infected system,

share|improve this answer
5  
noexec would not help much. There is not much difference for an attacker to emulate keystrokes which execute a program from the stick to emulate keystrokes which first copy the program and change the permissions and then execute it. –  Steffen Ullrich Aug 2 at 20:29

Accept the first USB HID Keyboard/Mouse, prompt on screen to accept more USB HID Keyboards/Mice. Probably the simplest way, I don't know of any OS or software which has implemented something like that yet.

Alternatively, display something onscreen that the user has to enter from the keyboard so that you know its not a rogue device. Like, a short sequence of numbers or letters. (Because how would a rogue device know what's onscreen?)

share|improve this answer
    
Just accepting the first device leaves scope to have an input box on screen & no functioning keyboard - either if the mouse comes up 1st, or the badusb device does... –  Mark W Oct 8 at 9:55
    
Magstripe and barcode readers are usually implemented as HID keyboards. If the OS enumerates one of them first, you could find yourself with no way to input arbitrary values. –  Mark Oct 9 at 4:35

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.