12 ms·

This might protect against malware infecting your device unexpectedly, but I think there's a need for OS manufacturers to consider this as part of the holistic

This might protect against malware infecting your device unexpectedly, but I think there's a need for OS manufacturers to consider this as part of the holistic security. Why not pop up a dialog when a new USB device with HID profiles shows up that the OS hasn't seen?

Guvante 12y ago
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.
- jedunnigan 12y ago
  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...
  - Someone1234 12y ago
    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.
    - Nacraile 12y ago
      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...
      - deleted 12y ago
        [deleted]
      - FreeFull 12y ago
        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)
  - Terr_ 12y ago
    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.
    - jedunnigan 12y ago
      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.
- linuxlizard 12y ago
  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.
  - the8472 12y ago
    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.
    - linuxlizard 12y ago
      I smell a software product opportunity for OSX / Windows.
- Terr_ 12y ago
  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 https://news.ycombinator.com/item?id=8401924
joosters 12y ago
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.
Someone1234 12y ago
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.
- cvosteen 12y ago
  > 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.
  - Terr_ 12y ago
    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?)
- Terr_ 12y ago
  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.
drzaiusapelord 12y ago
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."
- shabble 12y ago
  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.
- PeterisP 12y ago
  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.
snowwrestler 12y ago
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.

Guvante 12y ago

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.

jedunnigan 12y ago
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...
- Someone1234 12y ago
  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.
  - Nacraile 12y ago
    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...
    - deleted 12y ago
      [deleted]
    - FreeFull 12y ago
      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)
- Terr_ 12y ago
  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.
  - jedunnigan 12y ago
    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.
linuxlizard 12y ago
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.
- the8472 12y ago
  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.
  - linuxlizard 12y ago
    I smell a software product opportunity for OSX / Windows.
Terr_ 12y ago
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 https://news.ycombinator.com/item?id=8401924

joosters 12y ago

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.

Someone1234 12y ago

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.

cvosteen 12y ago
> 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.
- Terr_ 12y ago
  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?)
Terr_ 12y ago
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.

drzaiusapelord 12y ago

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

shabble 12y ago
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.
PeterisP 12y ago
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.

snowwrestler 12y ago

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.