Hacker News Reader

Comment by reallymental | Hacker News Reader

"Tip: Additionally, you may use a cord to attach a USB key to your wrist. Then insert the key into your computer and start usbkill."

This line particularly caught my eye. I wonder what's the percentage of people (I'm presuming people working in security or those who are trying to avoid detection) go to this extreme?

Is is even extreme?

View on HN

"To prevent Ulbricht from encrypting or deleting files on the laptop he was using to run the site as he was arrested, two agents pretended to be quarreling lovers. When they had sufficiently distracted him, according to Joshuah Bearman of Wired, a third agent grabbed the laptop while Ulbricht was distracted by the apparent lovers' fight and handed it to agent Thomas Kiernan. Kiernan then inserted a flash drive in one of the laptop's USB ports, with software that copied key files."

https://en.wikipedia.org/wiki/Ross_Ulbricht

> Kiernan then inserted a flash drive in one of the laptop's USB ports, with software that copied key files.

How exactly does this work? Is there a sort of software that runs automatically when you insert the stick, or did he have to click on it?

On Windows, autorun.inf. This technique has been around since at least the 90s when CD-ROM drives were introduced to PCs... it is how a newly inserted CD (and later usb disk) can automatically execute software on insertion:

https://www.instructables.com/id/Autorun-anything-off-of-a-u...

Autorun has been disabled by default for a long time (with good reason). And it has never worked with USB drives, only ones which emulated a CD drive such as U3 USB drives.

Autorun attempts results in a prompt since Vista.

Apparently, autorun from USB volumes was enabled for XP SP2:

https://support.microsoft.com/en-us/help/967715/how-to-disab...

>Before Windows XP SP2, AutoPlay was disabled by default on removable drives, such as the floppy disk drive (but not the CD drive), and on network drives. Starting with Windows XP SP2, AutoPlay is enabled for removable drives. This includes ZIP drives and some USB mass storage devices.

Autorun and AutoPlay are different things. AutoPlay is what asks you if you want to open media in File Explorer or some other application.

I've always been surprised that autorun wasn't re-enabled when app stores / code signing was introduced. If Microsoft or Apple is willing to sign an installer saying that it's something safe to install, isn't that proof enough to let it run when you insert the USB key it's on?

I know this isn't really very relevant for the specific combination of installers and physical media any more, since it's rare for anyone to be trying to install something off a CD/DVD/USB these days (other than a new OS, of course.)

But I could see the use case for physical media doing something other than running an installer (e.g. DRMed disks launching the equivalent of a FUSE server to mount the "rest" of the disk); or for non-physical media (e.g. macOS DMG disk images) being able to autorun their embedded installer. Either way, the code signing that the platforms are already doing would be enough to make these safe, no?

Windows code signing does not include a step where Microsoft inspects the code. The developer gets a certificate from a commercial CA and signs the code. If the certificate is an EV certificate, that's basically it. If it's a regular certificate, Windows does a callback to Microsoft that seems to just be a popularity check --- if the certificate has been used a lot, then the prompts go away.

At best, Windows code signing lets you know who signed it and that that person was able to pay a CA some money, not that it's safe to run.

Regular developer code-signing, yes. But I'm talking about the code-signing that's done by Microsoft (rather than by your own Microsoft-signed cert) on the Microsoft Store backend; or the code-signing that's manually done by Microsoft when a third party submits a driver package to them for inclusion as a Windows update.

Microsoft limited autorun about two decades ago, and finally got rid of it completely in 2011.

https://www.theregister.com/2011/02/08/microsoft_windows_aut...

You should try Windows 10! It's very good. At least give it a whirl so you can have accurate facts to what it does, and not spread FUD about it.

Maybe rubber-ducky style keyboard emulation?

Speculation: It's possible to produce keyboard and mouse inputs, and also present as a storage device -- autorun isn't even necessary (though spurious inputs would be quite visible to somebody using the computer and something like a mirrored mouse, custom keyboard layout / shortcuts could foil this)

That would only work on a known operating system and window manager with known keyboard shortcuts, unless a terminal is already focused.

In theory, you could fingerprint the host OS first and then run the appropriate commands (of course more tricky with more custom Linux setups, does CTRL+ALT+Fn still work to get to a text console?): https://www.cise.ufl.edu/~butler/pubs/sadfe11.pdf

Yeah, I was thinking of custom window-manager setups. You can usually get a tty console by ctrl-meta-f1 etc., but that wouldn't help, since you'd have to enter a password. I suppose an advanced version could try different combinations and test each by entering a command that would be detected by the stick.

On Windows, it's just 'Win+R 'CMD' [Enter]' and you have a terminal/console. Presumably, if the agents were monitoring the perp properly, they would know what OS they would be targeting.

I type the above SO often every day, it should be on my gravestone. :D

One of Atmel's USB-capable microcontrollers had a HID Keyboard example program that when you pressed a button (on a Windows host) would start Notepad (via the run command) and type "Hello, I'm an Atmel SAMXXXX".

Great bit of example code, but opens a world of possibilities for what you could do with, say, a HID + Mass Storage composite device.

You can present yourself as a standard file system or some device you know has a known exploit in the driver on the other side. Then on the USB 'drive' side you have a full out arm CPU. It can issue commands too as it is connected to the serial bus. Many USB drives already have small embedded CPU in them.

>Many USB drives already have small embedded CPU in them.

For most common hardware this is just an 8051 variant that sets up the USB and DMA peripherals. It's easy enough to get something more powerful, but I am doubtful you'd want to reuse consumer hardware.

The 8051 is a decently capable CPU (it is the cpu at the heart of the furby toy). At one point they built whole computer ecosystems around it. Remember the point here is to take over the computer not have a full out modern OS. They USB manufactures use them because they work well on low power and are decently cheap and small. Now most usb sticks do not do much more than like you say. But that would not stop someone from reflashing the firmware in it who is making one of these things. The use case here is different than what most people would use it for. Sometimes you will see an older ARM design too.

Mfrs use them because they are not patent encumbered. There are some fairly high power 8051 clones, true. But in most applications they are barely sufficient.

In this case any kind of MCU is making life harder than it needs to be.

not a security expert but a commonly heard phrase is 'depends on your threat model' :)

I don't think that wrist-key is an extreme (never seen it actually, but I still think this solution is a cautious one).

For me an extreme measure would be to modify my motherboard in a way that I could connect RAM to my wrist and tear it away when necessary.

Now that would be interesting: have your RAM strapped to your wrist and connected to your Mobo by a breakaway cable.

Bonus points if they cut it when the tackle you because they thought it was a deadman switch, like mentioned in the link.

How about a bluetooth dongle in your pocket? Less visible, and unless there hostiles know about it, they will separate you from the computer.

A phone could work. An apparent car key would be better. Best would be a piece of clothing, like a belt.

There are bluetooth low energy key fobs that work for this.

That would work great for half an hour, until your Bluetooth connection drops for no reason, the dongle pairs with your car or phone instead, decides it's a headset now, or one of the hundred other things that inevitably go wrong with Bluetooth.

hehe, Do not think like an engineer in this case. Think like someone who only has to get it right once but can try 100 times. So even if you have a flake connection. Just so long as it works that 'one time'. You are good.

Reply on news.ycombinator.com