What are malicious USB keys and how to create a realistic one? | Hacker News Reader

What are malicious USB keys and how to create a realistic one?

elie.net

124 pointsliotier77 comments

A few years ago, a co-worker came back from a MongoDB event with a bag of swag, including a MongoDB branded USB drive.

When he plugged it in, it acted as a keyboard and managed to open the browser to a MongoDB promotional page.

Needless to say he freaked out a bit. Some marketing goons (not restricted to the people at MongoDB) seem to think this kind of thing is a great promotional tool.

Now that I think of it, my wife has a similar story about her University distributing this same kind of USB/botnet thing to students.

Who needs USB keys?

If you have Python (and preferably a handy virtualenv so you can throw it away afterward), do `pip install rickroll`.

It will do exactly what it sounds like it should do.

A HID-based attack has to spawn a terminal and very quickly inject a set of commands that is very visible but only for a short period of time. Once the attack has been carried out, there is nothing left to see, so this type of attack is less obvious than the social engineering one.

MEMS microphones are tiny. It should be possible to combine data from that and a light sensor, that would make an HID based attack far less likely to be detected. The frequency profiles of keystrokes and someone pushing away an office chair should be fairly easy do discern. You'd want to make it more likely that the attack would occur after someone had left their desk. (Hopefully with the machine unlocked.)

EDIT: Another idea: The USB key uses autorun to pop up what looks like a spammy ad for a PC "cleaner" utility, or something you'd expect on a USB key conference swag item. It's actual purpose is to cover up the shell's window, or to contain the exploit itself.

Another approach - controlling the USB device over WiFi, so it can be remotely triggered at any time: https://www.sensepost.com/blog/2016/universal-serial-abuse/

I recently made a few of these with Cactus Micro Rev2's. :D

I think it would be unlikely that the user would step away from his machine before unplugging the device. If it was discovered on the ground, I would think the likely sequence of events is: 1.) plug in, 2.) open finder, notice nothing of interest. 3.) unplug, 4.) discard

So then, one tactic would be to fill it with nested folder after folder of something that might be interesting. Like "Studio Rough.mp3" If you make it large enough, a lot of people will procrastinate going through it all.

Making a mold and casting a custom case seems incredibly cumbersome compared to just buying a USB key case and fitting the board into it: http://www.mouser.com/New-Age-Enclosures/Enclosures/Enclosur...

If you look closely there might be two issues with that. First the device that was used doesn't have the USB connector centered and second, the board sticks out the edge a little so I would guess that it would need a larger than normal case.

I think the parent might have been suggesting to develop your own board. Using something like a USB enabled Atmel chip (ATMega32u2) should be relatively simple, and there are plenty of HID libraries out there for it. If you were trying for a bulk attack, or had the funds, this would be by far the best solution.

Even a non-bulk attack can be done pretty cheaply these days. Places like seeed will do boards for a buck a piece if your design's small enough and you get a ten pack. Doing smt work is honestly more bark than bite compared to pth; a $20 toaster oven will work Well Enough for something like this.

For small run electronic prototyping it's hardly worth stuffing your own boards any more. Macrofab or circuithub can get you fully assembled boards in a few weeks in the $20-$50/unit range.

Even easier: just buy a cheap usb stick of correct size, preferably one with a recognizable brand, open it up and replace the innards.

A really sneaky method would be to create a USB suppository, that looked like a large USB key but would leave the active part inserted inside the socket after the target pulls out the seemingly defective key.

And how is the port supposed the stay functional upon removal of the key? The point of this attack is stealth.

There's a fourth class of malicious USB keys: those which discharge -100V across the USB data lines, aka "usb killers". Drop a couple of these on a huge parking lot to create a boatload of damage.

Most ICs can handle at least -3000V static discharge. You need to pump about -5000V to start doing real damage. Even LEDs are so robust now days as to take 3X-5X their rated forward voltage as reverse voltage regardless of what their spec sheet says; I make 120V rectifiers from strings of them all the time.

the killers don't do a low-current static discharge; they do high-current through the protection diodes and seriously mess things up. https://www.youtube.com/watch?v=3hbuhFwFsDU

The 3 kV rating is most likely 3 kV on a human body model, which is a small capacitor (few picofarads) with a series resistor. This says nothing about what happens if you charge a large capacitor to 100v and then dump it through as low a resistance as possible into the victim port.

Meh, a couple tens of thousands of dollars in destroyed equipment via a very crude vandalism attack. Sounds like a lot until you realize you can cost someone millions with a medium sized botnet and a long standing DDoS. For most large targets, a USB that fries a laptop or two is no big deal (assuming automatic backups or devserver or etc), one that installs a rootkit would be a much worse scenario.

Also, if you are talking about harming individual users, and you are the kind of person who would drop "killer" USB drives on a parking lot, how is that any different from just keying every car? You get no benefit, it only causes damage, it takes near zero sophistication and the end results is it costs people a bunch of money and police start an investigation for vandalism.

> how is that any different from just keying every car?

People will notice that some dude is walking around and keying cars. If you happen to come across a car owner, you might be in for some pretty violent payback (at least that's what I'd do with someone keying my car).

Dropping USB keys, on the other hand, won't cause any suspicion.

A zero-day key wouldn't have hardware costs that would be significantly different from an HID key. A lot of microcontrollers will gladly announce themselves to be whatever sort of device class you want them to be, and which vendor and device IDs to use. Also, if you're worried about bulk, putting an LED or something that flashes and looks pretty would also lower peoples' guards as to why it's so big. USB hacking is an area where there are wide open fields to play with.

If one finds a USB key in a parking lot, is there any safe way to find out what's on it?

Plug it into a machine you don't care about?

Sand-boxed environment I would have to say. But as the article states this attack vector could become more sophisticated (if it has already not gotten to this level for sectors that can afford this).

If anything I would say it's not worth it all, just turn it in to your nearby local law enforcement or trash it, not worth what could be the last thing you plug into your computer.

most paranoid I can think of: Use an Atmel AVR (Harvard architecture means no code execution, and it doesn't have low-level firmware that could be vulnerable) to read the filesystem and sanitize data, then feed it over serial to a host machine to analyze?

If you trust your hardware and VM hypervisor to be secure, pass the USB controller to a VM?

I'm wondering if even this route is no longer safe - stcredzero comment [1] points out things that could be added to completely circumvent even a system that is essentially "off-the-grid" or just uses the USB for power.

[1] https://news.ycombinator.com/item?id=12694843

Right, you can't tell if there is a hidden malicious component that hasn't been activated yet. You can extract assumed non-malicious data without giving a malicious component the ability to do anything, if it hasn't an build-in data exfiltration channel (microphone and wireless transmitter could spy on you without attacking your system)

I guess one could setup a jammer or some room that could completely cut off any signal possibility. However then they could put something even more malicious then just spying into the device. As much as a tin foil hat theory that is, maybe it's just best to not know what's on the drive cause it's more than likely not worth even the slightest bit of trouble. Sad the world has come to this

...or you could just plug it in a public PC (eg library ones) and that's it.

That's not a very responsible thing to do if you believe the drive could be malicious.

It's easy enough to get free or cheap computers off craigslist. Don't need a modern one to see whats on a thumb drive.

I am interested in this too; so far my best solution has been to just burn a Rasbperry pi on it.

Use a VM and assign the USB drive to it?

To whomever down-voted me: will that not work? I know on my system at least I can tell it to prompt me when a new USB device is inserted to mount it to the VM directly. In which case key presses would go to the VM. So as long as it doesn't issue a key sequence to escape keyboard capture all key presses should go to the VM... or am I missing something?

If you plug a keyboard in your system the system doesn't take key presses from it until you've confirmed what to do with it? That's at least an unusual configuration. Otherwise it could run the malicious sequence before you had time to switch the connection to the VM.

One way around that would be to passthrough the entire USB controller.

You're missing that 0-days and other stuff can get around that.

Or even just the USB killers that use capacitors to fry your motherboard.

Plug it in a Raspberry Pi that's not connected to a network. After you're done, destroy the Pi's SD card.

>destroy the Pi's SD card.

Don't forget to use tinfoil gloves and hat while you eject it

Put the SD card in Read only mode. Save yourself $10.

Not enough by a far margin.

There's a computer inside that SSD that reads a soft signal to decide if writing is enabled or not. More often than not its firmware is full of known bugs.

Correct me if I'm wrong, but that's because SD cards are half duplex, right? So there's no way to disable writing through a "disconnect pins x and y" because those pins are needed for reading.

SD cards implement a simple four-pin mode (SPI) for which there's public documentation, and a proprietary mode parallelizing data over more pins. I know more about the former than the latter, but it's probably a similar situation.

SPI is full duplex; it has a dedicated line per data direction (MISO and MOSI), however the same lines are used for commands and data. So with MOSI (master out, slave in) physically disconnected, it'd be impossible to send the command asking to read data, even though that data would be delivered on the separate MISO (master in, slave out) line.

> After you're done, destroy the Pi's SD card.

Or sell it on eBay...

Nope.

Author of this piece didn't talk about USB electrical attacks, which (IMHO) are a bit more potent and harder to spot by the untrained eye: http://www.tomshardware.com/news/usb-killer-2.0-power-surge-...

Don't even need to go that far. Just short all the pins and you will will kill a lot of motherboards.

My friend accidentally jammed his headphones into the front USB socket on his PC and killed the motherboard. Of course it doesn't work on all computers, my old laptop would just shut down (which is still inconvenient), and I'm not sure what would happen to my Macbook (and don't want to find out).

Jammed a dinner knife in my usb 3 port and I just got a windows notification that one of my usb ports had a power surge...

How do you accidentally jam a headphone plug into a USB receptacle?

Blindly trying to plug it in and getting the location wrong? I've seen people jam USB sticks diagonally in Ethernet ports...

Right next to each other, and a usb port is apparently just large enough to take a 3.5 mm plug.

> Don't even need to go that far. Just short all the pins and you will will kill a lot of motherboards.

Interesting. USB 2.0 spec mandates overcurrent protection on the power rail and ability to withstand continuous short circuit to ground or power on the data pins. I think 3.0 lifted the latter requirement, though.

But I never tested actual hardware for that, besides power short-circuit protection which seems to work on my machine (YMMV).

Buy an old computer (or a Orange Pi or other cheap RPi clone) and plug it into that?

Depends on which parking lot. The one for the DefCon conference?

There are commercial test products that are "dumb" enumerators. I used to have some in the lab I worked at. You can script low level usb commands to them and see how the device responds. Here is an example that is pretty simple.

http://www.rpmsys.com/root_flyer.pdf

I can't remember what it costs, I think it was about $2k

This is a more expensive elaborate one.

http://ellisys.com/products/usbex260/index.php

Again I can't remember the cost, but I think it was about $30K or so.

Anyway in theory with a device like this you could develop a test to check a device actually only performed the functions it was supposed to, like for instance it never changed its USB descriptors from the function it was supposed to have.

This might be a dumb question but wouldn't one solution to the HID-based attack be for the OS to ask the user for permission to allow the new keyboard? As in "New Keyboard Detected: Allow? Y/N" That wouldn't protect against driver 0 days but hey, one step at a time.

Do any OSes have an option to ask the user if connection is ok before allowing it?

Tails does something like this!

What if it's the first HID you connect? How do you confirm?

Whitelist if present at logon and confirm if inserted later ?

I don't know about OSes, but some security solutions do exactly that.

Another good reason to run something like Little Snitch. Of course it's also another good reason not to plug random USB keys into your computer.

It also seems to me like your OS should warn and confirm when a new input source is detected.

It's interesting to see mention of 0-days against USB drivers as a vector, says "AFAIK, none of those have been publicly discussed." It seems very likely there are vulnerable drivers.

Block layer or filesystem driver vulnerabilities would be even better – no special hardware needed. Just buy a load of cheap flash drives, copy over your malicious partition table or filesystem, and you're set.

that seems a little optimistic, I figure there must be some moderately obscure device drivers that get much less scrutiny.

I suspect a lot of machines still have old floppy disk drivers...

Relevant to this discussion: https://www.crowdsupply.com/inverse-path/usb-armory

I'm surprised nobody has made something for testing; how much would it take to make something you plug a USB into and see what it does?

(I.E. "USB is typing"/"USB is doing")

There is usbpcap which captures all the packets.

He forgot the electrical attacks; fry your motherboard with a malicious USB device.

I think that was not the point of this, let's call it "experiment". Although I saw on Hackaday some "USB devices" that held huge capacitors in them, so when you plug it in, caps would discharge and your motherboard would be damaged.

"(I didn't know about it!)"

The reference is to the existence of /dev/tcp when using the "Bourne again" shell. Some other large shells, and gawk, have this "feature" as well.

Then I noticed he is head of something technical at Google.

We are always reading about the rigor of this company's interviews in testing candidates for practical knowledge.

I guess knowledge of important capabilities of widely/universally installed software is not something they are testing for?

I mean, I am sure there are probably hundreds of employees there who know these things. And they have some legendary programmers on the payroll. It is like a miniature Hall of Fame of computer programming.

I am not even sure what this all means, but I find it interesting to see the gaps in knowledge considering jobs with this company are so highly sought after.

And they are entrusted with protecting an enormous quantity of other people's data.

"important capabilities"? It's a fairly exotic feature nearly nobody is actually using, so the only people I'd expect to know about it are old-timey sysadmins and security people who've looked into stuff like discussed in the article. And while "lead of the anti-abuse team" is a security role, there are many possible backgrounds where you'd never come across this, and anti-abuse likely is working on a higher level.

Testing for stuff like that would be worse trivia checks than the algorithm-bingo people like to complain about in Google developer interviews.

I just checked. The only presence of this feature in the Bash man page is under REDIRECTION with the following, as the fifth and sixth elements of the list:

     /dev/tcp/host/port
       If host is a valid hostname or Internet address, and port is an integer
       port number or service name, bash attempts to open the corresponding
       TCP socket.
     /dev/udp/host/port
       If host is a valid hostname or Internet address, and port is an integer
       port number or service name, bash attempts to open the corresponding
       UDP socket.

It's not a feature with a large documentation footprint. I've known about it for a while, but mostly only in the context of security too. I have wondered whether the majority use of this feature is to provide hacked network shells before. It's probably a feature that never should have been added, though I understand the initial appeal.

It's a terrible "feature". Not only is it poorly documented (as noted) and redundant to common shell utilities (like nc), it's also implemented in a way that confusingly implies that it's part of the operating system. (And if your OS ever implemented a "real" /dev/tcp, I suspect that this Bash feature would make it inaccessible.)

We've used it for simple health ping scripts before in systems where bash is the only language guaranteed to be available and compiling a binary was overkill.

I've also used it to issue Redis and other text based protocol commands without having to have a large runtime or library.

But in both those scenarios the environment was pretty restrictive.

Maybe the jobs are so highly sought after because they understand that practical knowledge is different from esoteric knowledge, and it's worth having gaps in knowledge of bash arcana if it means that you spent your time learning more important things.

The feature is pretty useless because it doesn't easily get you a two-way pipe, and there are lots of easier-to-use, more reliable ways to get a two-way pipe (or a one-way pipe, even).

Just to clarify to the commenters: The reason it is "important" IMO is because it is a liability not an asset. I do not even use Bash myself; still, I am aware that it has this liability^W capability.

Reply on news.ycombinator.com