I hate to point out the blindly obvious, but what if you need the HID device to click on the box? So now you are stuck in a chicken/egg conundrum. You need the HID to click the box but the HID isn't installed until you click the box, great!

Unfortunately without going back to Windows 95-esk "please restart to install this keyboard" world, I cannot see how you fix this. Even blackholing some input from the HID is only at best a temp' solution (as they'd just add longer and longer sleeps before fake HID input was generated).

I guess you could redirect all HID input to a certain context (like a Virtual Desktop e.g. UAC prompt) until the user accepts it. However realistically most users would ignore this warning and just click "install" without reading it or understanding the implications.

I have an idea: Making and breaking the USB connection itself is a form of input!

1. Supposing all the more-convenient ways have broken down (no keyboard, no mouse, etc.)

2. The OS displays a random 15-60 second countdown telling the user when to unplug the device if they trust it

3. The OS displays a second (random) countdown telling the user when to reconnect the device if they trust it.

4. If both steps succeed to a reasonable level of accuracy (some fudge-factor for humans and for slow-powering-up devices) the OS will begin trusting the HID device and installing drivers etc.

This requires no additional hardware except for a monitor, and evil devices cannot reliably brute-force it without taking a lot of time and being very obvious and obnoxious about it.

So I hand you a malicious USB stick, you plug it in, the computer asks you to unplug it and plug it back in. You do so, because you trust the USB stick (why wouldn't you, free USB stick!).

Maybe it would be better to make you type some characters on the keyboard. Similar tricks with outher human interface devices. That way the user physically can't do it with fake USB sticks.

It would require that all these devices have at least some basic functionality with only some standard drivers. I don't know how true that is right now.

What? No, the operating-system is responsible for the dialog, and it would be saying something like:

"The following USB device has requested direct control over your mouse and keyboard inputs. Do you want to grant it access?"

"Note: If you are unable to interact with your computer, please wait X seconds for emergency instructions on how to enable this device."

You can't make anything totally idiot-proof, but a lot of people will be surprised/scared when a very unusual and seldom-seen dialog pops up when they plug in a particular misbehaving memory stick.

The malicious device can just fake breaking the connection and reconnecting. No way for the PC to tell the difference.

I think that's why he mentioned using random amounts of time for disconnect and reconnect. If your malicious device guesses correctly for the simulation of "fake breaking" (let's say it only has 10% chance of doing that) and similarly for reconnecting (another 10% chance), then the malicious device only has a 1% chance of fooling the PC.

Not great, but certainly a lot better than a 100% certainty of fooling the PC.

Yep, that's what the randomness is for, and you can also add entropy by randomizing the time before the dialog starts to present he user with the "emergency connect mode instructions" which explain the disconnect/reconnect process.

Plus, 99% of the time the user is not plugging in a HID device, so the "unrecognized input device" dialog can be made ominous enough that users will realize something is very strange about that one USB stick.

Well you could do this on the second keyboard that was plugged in. In normal use my machine has an HID keyboard already attached, so attaching a second one would both be unusual, and the first one would still be around to confirm or deny the input.

Until one day you see a hilarious Reddit post that makes you spit out your coffee and your keyboard stops working. Then you plug in a new one and have no way of making it work.

Unplug the broken one first, so that when you plug the new one in the OS knows that it doesn't make sense to display a prompt because there's no keyboard to confirm it with? You'd probably want to do that anyway if you'd spilt coffee on it.

Small price to pay for usb security. Also, if your only keyboard stops working, wouldn't it accept the next keyboard by default because there isn't one connected?

> I hate to point out the blindly obvious, but what if you need the HID device to click on the box?

You just have a timed dialog with allow/block options that defaults to allow the new HID after the timeout.

What stops evil devices from simply waiting for a period of time and springing the dialog at a later time or when the user is likely AFK? (Can it detect idleness by looking at voltages?)

When a HID device is plugged in, the OS presents the user with a random number and requests that it be typed (if you only have a mouse, an on screen keyboard can be used). The newly plugged in HID device would not be fully active until the OS receives the right number. Until that time only this authorization system would receive its input (so there is no chicken and egg problem).

The OS would allow you to interact only with the confirmation dialog at first and to prevent the USB device emulating a simple click on a confirmation button it should be asking you to type in a displayed random number. So basically a CAPTCHA for USB HID devices.

A way to mark certain root ports as trusted could potentially work. This would allow you to have keyboards and mice physically plugged in to a trusted USB port while all other devices are plugged into untrusted ports.

Security researchers have been saying since USB became popular that hot plugging should require confirmation from the user.

The only downside being that many users add a new HID as their only interface to the machine.

Perhaps some kind of time lapse would solve that problem. The USB won't execute anything for x minutes while you inspect what it is really doing (if it's your keyboard or mouse, do nothing). If nothing is done, allow the USB to load its drivers, etc...

Would it be possible to:

1. Connect innocently as a plain storage device 2. Wait a period of time or even monitor voltage fluctuations to guess when the user is not at the computer. 3. Disconnect and reconnect (or a new side-connection?) as a HID device

Users often won't mentally associate the long-delayed attack with the USB stick, and if it attacks when they are AFK the timer might hit 0 in total secrecy.

Absolutely true. The time lapse is only to allow the user to inspect the drive before it is allowed to execute arbitrarily. That may not actually be possible now that I think about it, so the idea is bunked anyway.

I just have to add Sleep(60 minutes) to my fake HID device and it will bypass this. You cannot blackhole HID input for an hour.

I'm not sure what that accomplishes. In order to provide input, the HID device must register itself with the OS, in order for the driver to be set up, etc. Sending HID messages without actually enumerating a HID device isn't going to work. Waiting 60 seconds to provide input doesn't change the fact that it has to tell the OS it can provide input in the first place. Yeah, it could wait 60 seconds to say "hey, a HID device just got plugged in", but that doesn't actually bypass the safety mechanism...

It can always tell the OS that it is a USB hub, so nothing precludes it from being seen as two USB devices (HID and storage)

Why not something like a USB Firewall?

Black/white list vid/pid (which are easily faked, yes). Closes the door a small amount.

But can also blacklist all HID.

I think this should already be possible under linux via udev rules.

It just needs to be wrapped in a convenient tool.

Might be worth it to at least extend the time span that an attacker would need if he had physical access to your laptop/smartphone.

I smell a software product opportunity for OSX / Windows.

In the worst-case scenario, why not use connect/disconnect events themselves as a form of user input?

https://news.ycombinator.com/item?id=8401924

Or if there is already a HID of that type installed and active, throw a huge warning.

"I see you plugged in a keyboard USB device, but you already have a keyboard installed. This may be a malicious attempt to take control of your computer by emulating a keyboard and sending keyboard presses to your computer from a USB device. Do you want to allow this? (recommended action is no)."

No more security headaches and marketers will stop their stupid tricks when they get pissy emails from clients about "sending us viruses."

Input devices are a bit painful on that regard.

The computer can't detect if I have a working and available input device connected - the fact that some devices claim to be connected doesn't imply that, as it may be damaged, a virtual device, or not wirelessly connected but simply listening for a possible connection that may appear at any time.

For example, right now I have a mouse and a keyboard connected, but Windows device manager somehow shows 5 keyboard devices and 4 mouse devices due to various connection drivers listening to devices that might be connected but currently are not. If I came home after a long vacation and found out that the batteries in them are dry, then there would still be multiple devices of the same type "available" when I'd try to connect a wired USB keyboard.

If I want to connect an input device, it is quite possible that the only way that I could allow or disallow anything is through that device itself.

My laptop has a USB keyboard (well, that's how it's presented, wiring is all internal), and I regularly connect an external USB keyboard to it.

You might think you could identify it by manufacturer/model (VID/PID) or even serial number, but all those are easily modifiable by a serious attacker for a given target.

It might make shotgun/blind attacks harder, but ultimately it wouldnt' be much more secure than MAC filtering on your network router.

There are also plenty of non-keyboard HID types that could potentially generate unwanted input of this sort, although not quite as easily.

Except that this vulnerability affects all USB devices, including HIDs.

So if you plug a keyboard or mouse into a computer carrying this malware, they could be infected. Then if you plug them into another computer, they could infect that computer.

Or more likely, you could find out your computer is infected, and decide to wipe or replace it. Then you plug the same mouse back in, authorize it as the expected HID...and now your computer is infected again.

Or consider a laptop keyboard that connects over the USB bus...

The only reliable solution to this vulnerability is to protect USB firmware via code signatures. That's going to take a long time.

In the mean time, I'm going to completely avoid USB thumb drives, and stick to Bluetooth HIDs.

That could help against some of the attacks (the ones involving virtual keyboards / NICs), but you still can't do anything against infected USB storage devices. They will appear as normal and can even be virus scanned, but will still manage to send you infected files.