5

I have these group policies set on my personal computer and it seems to me they should protect against Rubber Ducky attack (however I've read other threads that say it's hard to protect against, hence I'd like to verify):

1. Block all devices:

gpedit.msc -> Computer Configuration\Administrative Templates\System\Device Installation\Device Installation Restrictions -> Prevent installation of devices not described by other policy settings [enabled]

2. Whitelist only specific instances of devices you trust (doesn't enable entire device categories but specific devices by their instance ID):

gpedit.msc -> Computer Configuration\Administrative Templates\System\Device Installation\Device Installation Restrictions -> Allow installation of devices that match any of these device instance IDs [enabled]

Would these indeed suffice to protect against Rubber Ducky attack?

Improve this question

1 Answer 1

Reset to default
3

A complete whitelist of trusted devices should block Rubber Ducky specifically as I don't think it has a programmable device ID, but I'm not 100% sure.

However if the question is more generic, then no!

The more programmable Bash Bunny can do the same thing and it supports programming it's device ID. I've bypassed whitelist device lockdowns by using a Bash Bunny and setting it's ID to that of an approved keyboard. I even defeated a keyboard rate detector by programming delays into the Bash Bunny.

Improve this answer
4
  • Interesting, so it doesn't offer complete protection after all. Though I guess it's still a valuable practice as it should mitigate all attacks where the attacker doesn't have specific knowledge of the whitelisted devices (eg: the attacker doesn't have direct physical access like in the case of devices "left to be found", the attacker have limited time to act etc).
    – Amit
    Dec 28, 2020 at 0:31
  • 1/2 I was thinking about something that may work although I'm not sure (as I'm not familiar with the exact process used by Windows to match between the device and its drivers) - the idea is to first install all required devices on the computer and then apply a group policy to block all devices without whitelisting new devices (then whenever needs to install a new device can disable the group policy, install device and immediately re-enable it).
    – Amit
    Dec 28, 2020 at 10:31
  • 2/2 Whether this would work depends on if Windows allows to change the drivers of a device that has an instance ID that had already been installed before the group policy was enabled. If Windows doesn't allow it then it would narrow the attacker's options leaving him only the possibility to access through the instance ID of an already installed keyboard which may be much harder for him to obtain (especially if the already installed keyboard is internal like a laptop keyboard and he doesn't have access to the laptop and possibly admin / device manager permissions).
    – Amit
    Dec 28, 2020 at 10:39
  • AVR microcontrollers can be programmed with V-USB to implement a software USB stack that is completely programmable, meaning that anyone can trivially implement their own ducky clone with any arbitrary device ID. The only mitigation I can really think of is to block installation of any new HID devices more than 60 seconds after boot.
    – Polynomial
    Dec 29, 2020 at 1:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .