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

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

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.

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

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...

>destroy the Pi's SD card.

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

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.

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.

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.

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

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

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

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

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.