Good USB – Protecting Your Ports With Two Microcontrollers

If you’ve ever needed an example of why you should not plug random USB peripherals into your computer, you need only look at BadUSB. The BadUSB attack relies on the fact that the microcontroller inside every USB device is a black box. If you plug a USB thumb drive into your computer, the microcontroller could quickly set up an additional network interface, forward all your traffic to the attacker’s server, and still keep serving up all those files and documents on the drive. Do you want a thumb drive that attaches a virus to every file? Bad USB can do that.

Until now, there is no cure or fix for a device using an implementation of BadUSB. [Robert Fisk] just came up with the first prophylactic USB device, designed to keep BadUSB off your computer. He’s calling it USG, and it’s basically a hardware firewall for USB devices.

The basic design of the system goes something like this: take an ARM microcontroller with a USB host port, take another microcontroller with a USB device port, and have these devices talk to each other over SPI. The command protocol between these two microcontrollers is very simple, and thus decreases the attack surface.

[Robert] is building USG dongles, but in the spirit of Open Hardware and verifiable hardware, he’s also released a design based on two dev boards wired together. This DIY version is basically two STM32F4 dev boards smashed together with bodge wires. The total cost – less solder and a JTAG programmer – is about $50 USD. No, it doesn’t look as pretty as [Robert]’s commercial version of USG, but it does the same job of keeping your computer safe from BadUSB devices.

43 thoughts on “Good USB – Protecting Your Ports With Two Microcontrollers

    1. Ack, my reply was lost below. Trying again:

      The current hardware uses STM32F4 micros, which have USB1 transceivers built in. So you get about 1MByte per second throughput. There is an upgrade path to USB2 by adding external ULPI transceiver chips, which I am keen to design if this device proves super-popular.

      But don’t expect the USB Consortium to go reducing attack surfaces any time soon. As evidenced by the USB3 and USB-C standards, their main concerns are more speed, more complexity, and more exploitability!

  1. Normally the PC I have is in a house and can only be accessed by people I trust when I’m home, and the door is locked when I’m not @ home…

    Apart from that,
    How effective would it be to simply reject all USB devices (on my Linux box) ?, unless they have explicit UDEV rules (vendor/product ID’s). No encryption or key exchange stuff etc.

    1. I don’t think that will work – the BadUSB attack happens at the USB controller hardware, the operating system is not involved.

      Disabling the USB port in the BIOS is likely to work… (but may not, it depends on how the bios disables the port)

    2. UDEV rules would block some attacks such as mice with hidden keyboards, etc. But it wouldn’t block attacks that use malformed device descriptors to attack the USB stack directly. UDEV wouldn’t get a chance to evaluate the device because the exploit would have fired already.

      The problem with USB devices is that they all use embedded firmware to run their functions. Even if you keep your computer physically secure, how can you trust the entire supply chain of that $4 flash drive you just picked up? This is a worldwide problem.

    1. I just love British words for things, “carpark” is a lot less of a mouthful than “parking lot” (And it covers any sort of parking facility, be it a lot, garage, etc..)

      That said, every time I hear “carpark” my Yank ass immediately goes to an image of some cars in a park, like jogging or reading a book or checking out the Porsche that just jogged by…

      1. Sorry to tell you this but that specific type of literal imagination is a symptom of schizophrenia. from an article:
        These posters contain the well known phrase ‘loose lips, sink ships’ and the idea is that not being cautious with information in correspondence might allow the enemy to obtain information and undermine the war effort. Give this to a Schizophrenic though and they might view this as a pair of giant lips trying to sink ships.

  2. What would be useful is one with a full high-speed charging pass-through, that wouldn’t permit any data. I’m always nervous about using public USB charge stations, you never know what could be slurping up data — I’d rather carry a wall wart.

          1. That only works to tell devices they can pull up to 1 amp. For higher current, there are various tricks used by Apple, Samsung and others.

            There are ‘smart’ charger chips that somehow detect what is plugged in and deliver the appropriate current level.

            What would be really useful is a charger interposer with the smarts to discover the maximum safe current available from the port, and negotiate with a device plugged into its other end to tell it how much current is available.

          2. Depending on your device it also can be helpful to add two voltage dividers. There are some codeings with voltage levels at the data pins to signal higher current capability. There are even “fast charge” adapters from china which do just that: cut the data lines and apply this signal voltages on the data lines to the device. To trick devices to fast charge even at computer USB ports. Use at own risk of overloading something.

      1. The result would be 500mA of charging current. What you can do is present a set of resistors to either side and cut the lines in the middle hoping they default back to their dumb way of negotiation, but the result would be still not fast enough and would rely on luck knowing which of the non-existent standards a device used.

        Best still would be to put a charging controller in the device. Facing upstream it could speak BC1.2 and negotiate the correct charging current. Facing downstream you could have a microcontroller also speak BC1.2 and request the appropriate charging current.

      1. I carry a SyncStop in my bag, just in case I need to charge somewhere. Although when I kickstarted them, they were called “USB Condoms.” I admit I was slightly disappointed in having the new name printed along the side instead of the original one.

        1. My phone always stops and asks me if I want to enable USB data transfer when it’s plugged into something that’s not a dumb charger. Easy to answer “No.”

          That said, I like the idea of a hardware firewall. Most AV products aren’t worth *&#* when it comes to removable drives (by the time they notice something, you’re already owned). I keep autoplay fully off, but as other noted that only addresses a small part of the attack surface. What would be cool would be to have header wiring so these could be inserted inside the case between the front panel USB ports and the motherboard.

  3. How about a standalone USB inspector? Plug in the suspect device and if it’s a USB killer it lights up red. If it’s anything else other than a clean mass storage device it blinks red. Green light means it’s OK.

    Still waiting for USB ports with a motor or solenoid to actually eject devices when I right click on them then click Eject.

    1. detecting the USB killer is easy: connect some neon lamps from data to ground lines and/or between the data lines – I am not sure where the USB killer places it’s pulses. Or use 6 diodes (1N4007 style) in a 3 phase bridge connection to one neon lamp.

    2. That absolutely sounds like something I would buy.

      However it could lead to a false sense of security.

      if it is “just” a mass storage device with files on it, but those files are innocuous looking .exe files with payloads wrapped into them, getting a handheld device to pull those apart and figure it out is a tall order.

      maybe something like a raspi with ClamAV to sweep it for the more common stuff?

  4. The timing is interesting as Hak5 just released Bash Bunny.. which emulates ethernet, HID and mass storage .. and can change at will. Pick the ID’s for the device you want to emulate and involuntary backup/inject/MTM away…

  5. The current hardware uses STM32F4 micros, which have USB1 transceivers built in. So you get about 1MByte per second throughput. There is an upgrade path to USB2 by adding external ULPI transceiver chips, which I am keen to design if this device proves super-popular.

    But don’t expect the USB Consortium to go reducing attack surfaces any time soon. As evidenced by the USB3 and USB-C standards, their main concerns are more speed, more complexity, and more exploitability!

  6. this sounds great. it should also have usb killer protection too. i could see corporations using something like this in line with the front panel usb’s. and maybe Intel’s management engine would eventually integrate it into uefi someday

  7. Pretty cool. But did anyone test it vs BadUSB? I feel like there is not much electric isolation there, and it might still pass the shock through. Consider that BadUSB generates enough voltage to likely arc across the tiny distances between the wire-bond wires in the chip. A few arcs and you’ve arced to the DP/DN pait of the host PC. Maybe optoisolators should be used on the spi bus?

    1. You are confusing BadUSB (the virus-spreading, man-in-the-middle horrible nightmare device)…
      with the USBKiller (which is just some jerk that shoved a charge pump and a bunch of capacitors into a usb drive).

      Both are bad, but the usb killer isnt going to steal my identity and ransom my bank account back to me.

      Now, if someone wanted to be a horrible person, they could make a BadUSB equipped device that did its work, and then activate a usb killer.
      You could theoretically extract sensitive data, and disable security, and say, launch ransomware or install a botnet spyware on a network device, and then destroy the computer to cover your tracks.

        1. you joke about that, but this was actually a consideration for a high security device I had built as part of my job. (it was going to be evaluated and we didn’t want them getting any ideas about it.) black epoxy, and ALOT of polishing, and you could barely tell it HAD USB ports.

    2. The arcs will probably happen in the first processor and turn it into some more-or-less conductive piece of silicon. On the board 200V do not arc very far. If you want extra security use some series resistors and ESD protection diodes at the SPI lines.

  8. Couldn’t you just setup a cheap raspberry pi to automatically share whatever is on a USB plug you connect on your local network?
    I’m not an expert but if you use a read only sdcard and bit everything in ram it should be relatively safe, shouldn’t it?

    1. You can do this with the USB/IP project. The trouble is that you are just moving the USB packets over the network to the destination computer without sanitizing them in any way. So whatever exploit was going to attack you directly is now piped through the network and attacks you remotely.

      The key point is that you need to have something that limits the USB device to only “known good” actions, and that something cannot be exposed to the USB device directly otherwise it will be exploited as well!

      1. I wasn’t thinking to something low level like USB packets, but just something like :
        – mount the USB filesystem
        – share it as a CIFS for the rest of the network
        I guess someone could make a BAD USB who target Linux too, but if everything is in RAM and the system boots from a write-protected SD card it should be safe … (oops… I just remembered that microSD no longer have a RW protection tab).
        You could add some background daemon that check the list of hardware devices every seconds or so, and shutdown if it found something new which isn’t a mass storage device (HID, network adapter, etc…)

  9. You could also build something like this with a Raspberry Pi Zero (as USB Host) plus an Arduino Micro clone (as USB Slave), or two RasPi Zeros (one Host and one OTG Slave), and it would have more functionality too.

    1. You could just use a Raspberry Pi Zero with a USB hub (e.g. and have it share drives/devices over the network as drives. I would think that would largely limit attacks to being network based unless they somehow managed to compromise the Pi itself and the drive showing up only as a drive and not as a local USB device would provide some degree of isolation.

  10. As far as SyncStop is concerned – a truly evil BadUSB maker could detect that there’s no data connection, then in retaliation dump the high voltage into the power lines. If SyncStop had a couple of fuses, that attack could be prevented too.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.