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