What can I do to protect my Linux laptop from BadUSB attacks as described by ArsTechnica here?
Perhaps writing an appropriate AppArmor profile would help?
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
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
and unblock with:
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.
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.
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.
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,
I've recently started to work on USBGuard which implements a USB device whitelist/blacklist with the help of UDev and the Linux kernel USB authorization feature. It's a user-space daemon that listens to UDev events and authorizes or deauthorizes USB devices based on a set of rules written in a custom rule language.
I think it makes it much harder for an attacker to reprogram a device in a way that it will bypass a good whitelist (i.e. as specific as it gets). Of course, USBGuard cannot protect you from every attack and if an attacker has physical access to your USB devices, then he has access to all the values needed to create a copy of such a device, for example a keyboard. Keyboards are especially bad cases as they usually don't export any iSerial value which would distinguish two keyboards of the same type.
However, using a whitelist of known devices is good against hidden/unexpected interfaces on a USB device. The notorious example being a keyboard or a network card added (by reprogramming on a different/malware infected machine). If you know that your USB flash disk should have only one mass storage interface and suddenly it has something more, then you know you shouldn't let it interact with your system -- and that's the main use case of USBGuard.
The same level can be implemented just using UDev rules and some helpers to parse USB descriptors, but USBGuard makes it more convenient.
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?)
The easiest way is probably to use a secure kernel, I mean the grsecurity patched kernel:
Grsec is providing 2 options to disable usb after boot :
the soft one :
User can still unlock usb using a sysctl ( kernel.grsecurity.deny_new_usb )
the hard one :
No usb at all after boot
Grsec is a set of source patches enhancing the security level of the linux kernel, and will protect you of many more security problems ( buffer overflow, stack exec and many more ), see https://grsecurity.net/features.php
You can build your own grsecurity patched linux kernel on any linux distro, but the distros supporting it are :