50

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?

StackzOfZtuff
  • 17,923
  • 1
  • 51
  • 86
student
  • 1,443
  • 4
  • 15
  • 23

7 Answers7

39

The BadUSB attack is based on the fact that computers allow and enable HID devices on all usb ports. Faked network adapters are no real danger. My answer tries to 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.

albert
  • 103
  • 4
user10008
  • 4,355
  • 21
  • 33
  • 1
    Can you give some details on the time based approach? – student Aug 03 '14 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 09 '14 at 07:51
  • 3
    @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 09 '14 at 18:41
  • Really nice answer, but now my question is this: what happens if your `keyboard` or `mouse`, your supposedly-good HID devices, are able to run BadUSB as well? How would you handle it in that situation? Most BadUSB attacks that I've personally seen were in the keyboard and mouse. – Mark Buffalo Nov 05 '15 at 16:34
  • 1
    Some stuff you have to trust. You can't have no trust anchor. You can prevent getting attacked by BadUSB from devices you don't use for HUD input, but devices you do use for HUD you have to trust. – user10008 Nov 11 '15 at 01:07
  • You should probably use something like `tmpfiles.d(5)` to reset the rules on startup and make sure they unblock everything. Otherwise it's too easy to lock yourself out. – WhyNotHugo Jan 11 '22 at 13:13
25

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.

tylerl
  • 82,665
  • 26
  • 149
  • 230
  • 3
    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 03 '14 at 03:58
  • 2
    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 06 '14 at 13:29
  • @tylerl, Re "this new discovery changes very little"; You sort of missed the point of the article. Before the discovery, you can buy a USB device and be confident that its safe to plug into your computer. **Now you can't.** – Pacerier Mar 06 '18 at 08:24
  • @Pacerier quite the opposite. My point was that you *never could* be confident that a usb device was not malicious, regardless of the source or packaging. This vuln in phison devices is interesting, but it's no more likely an everyday threat than, say, supply-chain attacks. – tylerl Mar 06 '18 at 08:44
  • @tylerl, Before the publication, you can take a new USB from a trusted supplier, **reformat it**, and be sufficiently safe. Now you can't even after the reformat isn't it? – Pacerier Mar 09 '18 at 12:54
16

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,

Mark
  • 34,513
  • 9
  • 86
  • 135
  • 8
    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 02 '14 at 20:29
  • Re "mounted as "noexec""; What's the command you're referring to? – Pacerier Mar 06 '18 at 08:30
  • @SteffenUllrich, But you can see it on screen while it does so right? There's just no way to do it so quickly that it wouldn't have any windows "flashing". – Pacerier Mar 06 '18 at 08:32
  • @Pacerier: not necessarily and depends on the environment. But you should see that something is happening if you know where to look, i.e. the attack is not fully stealth. As for `noexec` - a simple search leads for example to [What does NOEXEC flag mean ...](https://superuser.com/questions/728127/what-does-noexec-flag-mean-when-mounting-directories-on-rhel). – Steffen Ullrich Mar 06 '18 at 09:03
  • @SteffenUllrich, Is there any way the attack can prevent the detection system from detecting it? – Pacerier Mar 09 '18 at 12:51
  • @Pacerier: The approaches discussed here don't explicitly detect the attack but simply limit if USB devices can be attached or what devices (white list). For extended questions about this please don't discuss it in comments on a more than 3 your old post but instead ask a new question. – Steffen Ullrich Mar 09 '18 at 13:44
11

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.

Daniel Kopeček
  • 111
  • 1
  • 3
  • 1
    Hey Daniel Kopeček I had to hunt your answer down on a place that I had enough reputation to up-vote and comment that you've made a sweet tool. Ya may want to update your readme file to reflect additional packaging support because it looks like Kali Sana has added packaged support for your tool; even for ARMhf CPUs, RPi or Android with chroot. I'll be trying it out very soon and thank you for building and advertising your project. – S0AndS0 Nov 27 '16 at 19:24
4

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?)

linagee
  • 141
  • 2
  • 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... –  Oct 08 '14 at 09: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 09 '14 at 04:35
  • @linagee, Re "how would a rogue device know what's onscreen"; Is there any way for the USB to advertise itself as a "screen" too? Or is that just physically impossible? – Pacerier Mar 06 '18 at 08:37
4

The easiest way is probably to use a secure kernel, I mean the grsecurity patched kernel:

http://grsecurity.net/

Grsec is providing 2 options to disable usb after boot :

the soft one :

https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Deny_new_USB_connections_after_toggle

User can still unlock usb using a sysctl ( kernel.grsecurity.deny_new_usb )

the hard one :

https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Reject_all_USB_devices_not_connected_at_boot

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 :

http://hardened.gentoo.org/

http://pentoo.ch/about

http://www.netsecl.com/home

neofutur
  • 141
  • 4
  • This only helps if you're worried about someone else putting a flash drive in against your wishes; that doesn't help if, for instance, you plug a flash drive into an infected computer (unknowingly) and then plug it into your computer. The main problem is that you might _want_ to connect a USB device, just not a keyboard (for instance); a restriction would really have to be based on device class to be effective against that (then a device can only be malicious within the class of devices you want it to be in). – cpast Dec 18 '14 at 02:33
  • you can still reboot with your ( infected or not ) usb device to get it recognized. – neofutur Dec 19 '14 at 05:15
  • That's precisely my point. The threat posed by BadUSB is not limited to attackers plugging an infected USB into your computer; one of the main threats is a user unintentionally infecting themselves. Among the biggest issues with BadUSB, compared to out-of-band USB reprogramming that's always been possible, is that an infected computer can infect a device connected to it without the user knowing. If a user's work computer is infected, it can infect their flash drive, and doing this won't stop that flash drive from infecting their home computer. – cpast Dec 19 '14 at 06:16
1

There are projects that do exactly what you want:

I have tested, on ubuntu 18.04, usbdeath and usbcut. The difference is that usbdeath turns off the PC when inserting an unauthorized device. Instead usbcut blocks the device unauthorized (without turning off the PC)

acgbox
  • 111
  • 4