4 ms·

It seems pretty scandalous to me that most operating systems still haven't implemented any mitigation for pretend-to-be-a-USB-keyboard attacks. Fixing it isn't

It seems pretty scandalous to me that most operating systems still haven't implemented any mitigation for pretend-to-be-a-USB-keyboard attacks. Fixing it isn't trivial, but it's hardly insurmountable. The solution is fairly simple: Whenever a new keyboard is plugged in or types its first keystroke, lock the screen, and don't accept key input to places other than the login form from a new keyboard until that keyboard has typed the user's login password. (You also need to build a way to authorize legit-fake-keyboard devices like barcode scanners that type the barcodes they scan, but that's not to difficult.) Given the high prevalence of USB devices with infectable firmwares, and the large number of USB cables of questionable provenance that no one pays much attention to, it doesn't seem okay to leave this vulnerability open.

pitaj 4y ago
That's actually a really good idea, but I think it could cause problems for things like external numpads. Maybe require the user to type a random combination of keys shown on the screen before enabling a given input device, instead of their own password?
- paranoidrobot 4y ago
  > require the user to type a random combination of keys shown on the screen before enabling a given input device If you could type it on any device, and you could guarantee that the OS could remember that device, I could see that being workable. I would also worry about: Ensuring that the keys shown bit is properly accessible to screen readers/braile devices, etc. Ensuring that automation could authorise a device, or disable the prompt requirements Ensuring that the OS actually remembered it. Plugging into different docks at home/work/conference room and having it prompt you to re-authorise your keyboard would drive people up the wall. eg: because during USB Enumeration the port numbers on your dock got switched, or they plugged the dock into the other side of their computer, or the Wireless USB controller is slow at starting up. How to handle an unauthorised device when there's no other usable input devices. eg I started up my HTPC, and a few seconds later the IR receiver wakes up and is now marked as unauthorised - the device may not have a keyboard but that receiver appears as one. Or maybe I'm trying to fix a laptop and the on-board keyboard is broken, so how do I plug in a USB keyboard to get at the data on it (Maybe I can't reboot) Some of these things might conflict with having such a lockout.
dzhiurgis 4y ago
That doesn't stop a keyboard that is actually backdoored to execute payload sometime much later after setup.
- skybrian 4y ago
  Sure, but it's not intended to. It's to prevent a device from pretending to be a keyboard without any user's knowledge.
- anamexis 4y ago
  No, but it does stop you from getting pwned by a plasma ball.
godelski 4y ago
I think it is a hard problem to solve BUT I think OSs should offer a compromise. That you are notified each time and can grant or deny. This should be an optional setting for those that want to easily add hardening (I think there's no excuse that linux distros don't have a "hardening" setting in their advanced or security settings). I don't know the answer to this, so I'll ask. Can USB ports be programmed to only output voltage but not data? If so, this seems like a cool way to implement the above as you can have Deny, Access (power), Access (data) as options.
- pabs3 4y ago
  Grant/deny just leads to people clicking accept, you want something where the user has to choose what kind of device the plugged in and if it doesn't match what the device says it is then you reject the device or something. On Linux GNOME already has USBGuard support btw.
  - godelski 4y ago
    > Grant/deny just leads to people clicking accept I was imagining this being in some advanced setting with a "here be dragons" warning. Or even a bit more relaxed like Firefox's strict or custom tracking protection. It comes with warnings and I feel pretty confident to say that most users don't touch these settings. > On Linux GNOME already has USBGuard support btw. Yeah I know there are plenty of hardening tools out there, but I was suggesting that they come pre-installed. There's so much bloatware on most systems these days that this seems minor. Or maybe someone could put together a bundling script to make adding all this (e.g. USBGuard + Fail2Ban + Faillock + Firejail + etc) easy to install and configure. I'm not aware of any such tool. But maybe even an Ansible script could go a long way.
    - pabs3 4y ago
      > I was imagining this being in some advanced setting ... most users don't touch these settings That just leaves most users unprotected. > I was suggesting that they come pre-installed GNOME's support for USBGuard is installed by default, but USBGuard itself may not be depending on the distro. Agreed that it and other security/safety/robustness (for eg SMART disk warnings need to be supported) stuff (should be enabled by default. GNOME should use Flatpak-style sandboxing for natively installed apps too.
mmh0000 4y ago
For those wondering, there is an easy defense against this on Linux, USBGuard (https://usbguard.github.io/ https://usbguard.github.io/) RHEL7+ include USBGuard as part of the standard repo [0] [0] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-using-usbguard https://access.redhat.com/documentation/en-us/red_hat_enterp...
- jimrandomh 4y ago
  This isn't very practical as a defense. You can't configure it to ban keyboards, because you still need a keyboard, and you might need to swap keyboards if your original one breaks.
  - mmh0000 4y ago
    That's not correct, it can block and does block USB keyboards. If your main keyboard was totally dead and you needed to whilelist a replacement keyboard you'd do so by booting into single-user mode.
duped 4y ago
How do you distinguish between a new keyboard and a bad USB cable that gets wiggled a bit?
- smegger001 4y ago
  check the Device ID, if its the same as the one that was in the port a second ago it the same.
  - MisterTea 4y ago
    What about spoofing?
  - duped 4y ago
    An attacker can lie about what their device id is
    - Scoundreller 4y ago
      How would it know the right device id to spoof? (Definitely doable in a MITM scenario, but more complicated in others).
      - duped 4y ago
        Pick one of the most popular keyboards used by your target and reuse it. That's how I'd do it. It's not going to get everyone but I think it's a legitimate approach. The alternative methods looking at the time between keystrokes seems more reliable.
        yencabulator 4y ago
        Keystroke delay based heuristic is just naive, all that means is that the attack needs to happen on an idle system. In an ideal world, vendors would actually populate the serial number field with a number that's at least semi-random. On this computer, only the USB-C HDMI adapter and the fingerprint reader have a serial number that looks random :-(
marssaxman 4y ago
Don't yubikeys register themselves as keyboards? You can definitely tap the button to get a code typed into any input field.
- yencabulator 4y ago
  By default, yes. You can disable the "long-press to send password" feature. (I kept triggering it by accident, and disabled it.)

pitaj 4y ago

That's actually a really good idea, but I think it could cause problems for things like external numpads. Maybe require the user to type a random combination of keys shown on the screen before enabling a given input device, instead of their own password?

paranoidrobot 4y ago
> require the user to type a random combination of keys shown on the screen before enabling a given input device If you could type it on any device, and you could guarantee that the OS could remember that device, I could see that being workable. I would also worry about: Ensuring that the keys shown bit is properly accessible to screen readers/braile devices, etc. Ensuring that automation could authorise a device, or disable the prompt requirements Ensuring that the OS actually remembered it. Plugging into different docks at home/work/conference room and having it prompt you to re-authorise your keyboard would drive people up the wall. eg: because during USB Enumeration the port numbers on your dock got switched, or they plugged the dock into the other side of their computer, or the Wireless USB controller is slow at starting up. How to handle an unauthorised device when there's no other usable input devices. eg I started up my HTPC, and a few seconds later the IR receiver wakes up and is now marked as unauthorised - the device may not have a keyboard but that receiver appears as one. Or maybe I'm trying to fix a laptop and the on-board keyboard is broken, so how do I plug in a USB keyboard to get at the data on it (Maybe I can't reboot) Some of these things might conflict with having such a lockout.

dzhiurgis 4y ago

That doesn't stop a keyboard that is actually backdoored to execute payload sometime much later after setup.

skybrian 4y ago
Sure, but it's not intended to. It's to prevent a device from pretending to be a keyboard without any user's knowledge.
anamexis 4y ago
No, but it does stop you from getting pwned by a plasma ball.

godelski 4y ago

I think it is a hard problem to solve BUT I think OSs should offer a compromise. That you are notified each time and can grant or deny. This should be an optional setting for those that want to easily add hardening (I think there's no excuse that linux distros don't have a "hardening" setting in their advanced or security settings). I don't know the answer to this, so I'll ask. Can USB ports be programmed to only output voltage but not data? If so, this seems like a cool way to implement the above as you can have Deny, Access (power), Access (data) as options.

pabs3 4y ago
Grant/deny just leads to people clicking accept, you want something where the user has to choose what kind of device the plugged in and if it doesn't match what the device says it is then you reject the device or something. On Linux GNOME already has USBGuard support btw.
- godelski 4y ago
  > Grant/deny just leads to people clicking accept I was imagining this being in some advanced setting with a "here be dragons" warning. Or even a bit more relaxed like Firefox's strict or custom tracking protection. It comes with warnings and I feel pretty confident to say that most users don't touch these settings. > On Linux GNOME already has USBGuard support btw. Yeah I know there are plenty of hardening tools out there, but I was suggesting that they come pre-installed. There's so much bloatware on most systems these days that this seems minor. Or maybe someone could put together a bundling script to make adding all this (e.g. USBGuard + Fail2Ban + Faillock + Firejail + etc) easy to install and configure. I'm not aware of any such tool. But maybe even an Ansible script could go a long way.
  - pabs3 4y ago
    > I was imagining this being in some advanced setting ... most users don't touch these settings That just leaves most users unprotected. > I was suggesting that they come pre-installed GNOME's support for USBGuard is installed by default, but USBGuard itself may not be depending on the distro. Agreed that it and other security/safety/robustness (for eg SMART disk warnings need to be supported) stuff (should be enabled by default. GNOME should use Flatpak-style sandboxing for natively installed apps too.

mmh0000 4y ago

For those wondering, there is an easy defense against this on Linux, USBGuard (https://usbguard.github.io/ https://usbguard.github.io/) RHEL7+ include USBGuard as part of the standard repo [0] [0] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-using-usbguard https://access.redhat.com/documentation/en-us/red_hat_enterp...

jimrandomh 4y ago
This isn't very practical as a defense. You can't configure it to ban keyboards, because you still need a keyboard, and you might need to swap keyboards if your original one breaks.
- mmh0000 4y ago
  That's not correct, it can block and does block USB keyboards. If your main keyboard was totally dead and you needed to whilelist a replacement keyboard you'd do so by booting into single-user mode.

duped 4y ago

How do you distinguish between a new keyboard and a bad USB cable that gets wiggled a bit?

smegger001 4y ago
check the Device ID, if its the same as the one that was in the port a second ago it the same.
- MisterTea 4y ago
  What about spoofing?
- duped 4y ago
  An attacker can lie about what their device id is
  - Scoundreller 4y ago
    How would it know the right device id to spoof? (Definitely doable in a MITM scenario, but more complicated in others).
    - duped 4y ago
      Pick one of the most popular keyboards used by your target and reuse it. That's how I'd do it. It's not going to get everyone but I think it's a legitimate approach. The alternative methods looking at the time between keystrokes seems more reliable.
      - yencabulator 4y ago
        Keystroke delay based heuristic is just naive, all that means is that the attack needs to happen on an idle system. In an ideal world, vendors would actually populate the serial number field with a number that's at least semi-random. On this computer, only the USB-C HDMI adapter and the fingerprint reader have a serial number that looks random :-(

marssaxman 4y ago

Don't yubikeys register themselves as keyboards? You can definitely tap the button to get a code typed into any input field.

yencabulator 4y ago
By default, yes. You can disable the "long-press to send password" feature. (I kept triggering it by accident, and disabled it.)