One morning, a balaclava-wearing hacker walks into your office. You assume it’s a coworker, because he’s wearing a balaclava. The hacker sticks a USB drive into a computer in the cube next door. Strange command line tools show up on the screen. Minutes later, your entire company is compromised. The rogue makes a quick retreat carrying a thumb drive in hand.
This is the scenario imagined by purveyors of balaclavas and USB Rubber Duckys, tiny USB devices able to inject code, run programs, and extract data from any system. The best way — and the most common — to prevent this sort of attack is by filling the USB ports with epoxy. [pmsosa] thought there should be a software method of defense against these Rubber Duckys, so he’s created Duckhunter, a small, efficient daemon that can catch and prevent these exploits.
The Rubber Ducky attack is simply opening up a command line and spewing an attack from an emulated USB HID keyboard. If the attacker can’t open up cmd or PowerShell, the attack breaks. That’s simple enough to code, but [pmsosa] has a few more tricks up his sleeve. Duckhunter has a ‘sneaky’ countermeasure feature, where one out of every 5-7 keystrokes is blocked. To the attacker, the ‘sneaky’ countermeasure makes it look like the attack worked, where in fact it failed spectacularly.
There are a number of different attacks similar to what the Rubber Ducky can accomplish. Mousejack performs the same attack over Bluetooth. BadUSB is a little more technical, allowing anyone with access to a device’s firmware to turn your own keyboard against you. Because of the nature of the attack, Duckhunter shuts them all down.
Right now the build is only for Windows, but according to [pmsosa]’s GitHub there will be Linux and OS X versions coming.
So “rm -rf ./” might become “rm -rf /”? Sneaky!
Assuming GNU Coreutils, you’d need a –no-preserve-root in there.
kinda kills the humor a little
Recently,last week, RS components sent out a promotional thingy that looked like their catalog on a USB stick.
Beauty I thought and plugged it in and WTF it was a USB HID keyboard emulator which opened the command app and ran a command that told my IE to connect to their web site. Benign enough but RS components your marketing ideas stink!
where was my copy of duck hunter then!!!
In college, the Student Government was doing an awareness campaign and was handing out USB drives with their logo on them, labeled as 8GB. I grabbed one, and being the professional cheapskate that I am (I’m Jewish, what can I say?) I circled back and got two more.
I get home and plug one in, and discover it was actually a HID keyboard emulator that opened IE to the Student Government website. Apparently you can’t trust student politicians either.
I used to have garage sales and sell sticks for 1$. You dont wanna know what was on them.
I wanna know what was on them…
– Study this device
– Create a fork with “Open IE -> type in www_xvideos_com”
– Drop it at your youngest brother/syster desk
– Call your mom when he/she plugs in
– Laugh out Loud
lels jp. get a lyfe.
I am not jewish and I did five times the queue for 5 USB of 4gb…
I got one of those about a month ago from RS.
Its an advertising group based in HK, also they were directly posted from there to which means RS gave that company your name and address.
What is even worse is it doesn’t go directly to their website. it goes via a URL re-director controlled by the marketing company. it has the word ‘secure’ in the URL but doesn’t use HTTPS either.
If the company ever goes under someone just has to buy that domain and redirect to something dodgy if someone plugs the device in later.
There are 2 tiny little pads near the head of the USB connector. If its like other ones of these advertising devices i was able to find then its probably a connection to the flash chip that stores the URL. I don’t have a bus pirate or similar but its probably a simple i2c interface. Would be fun to find out and reprogram the URL
or simply lock your computer when afk
> Duckhunter has a ‘sneaky’ countermeasure feature, where one out of every 5-7 keystrokes is blocked.
i can see the senior management team quickly shutting that feature down…because employee would be unable to get any work done since 14-20% of the time their keyboard fails to work, the users and the management team will be bombarding the IT tech support team with complaints of failing keyboards, and that will be the end of that.
Agreed. For hunt-and-peck guys like me it would hardly be noticeable, but for anyone touch-typing at a decent speed it’d be crippling.
I wonder if it could limit the blocking effect to devices that were not connected at boot? Regular keyboards would usually be unaffected unless the user plugs in a new one that day, and even then it could be solved with a snarky “Hello this is IT. Have you tried turnin’ it off and on again?… You’re welcome.”
I don’t know if it would be a good idea to block it from devices that were connected at boot — simply because an attacker would do their best to ensure that the rubber ducky would not stand-out, such as connecting to the usb ports on the back of the machine (and would be present at boot).
The duckhunter, litteraly, sounds like the nuclear option — it might get the job done, but the collateral damage would be, too, high.
I think it would be better to use the tried and true method — as the article points out — epoxy the ports or physically block them.
I disagree. The scenario presented implies the PC is already turned on and the attacker plugs the rubberducky in like a thumb drive. If the attacker is willing to reboot the PC with the device plugged in, they might as well just plug in an actual bootable USB drive with Linux or even DBAN, depending on their goal. Nothing you can do to prevent that, unless you can get away with disabling USB booting (I know I can’t).
>epoxy the ports or physically block them.
That still leaves at least 2 USB ports open, one for the keyboard and one for the mouse, and possibly a PS/2 port too. If rebooting the PC is an option for the attacker, the PS/2 port becomes an attack vector.
Yeah there are several ways, to Sunday, to attack a system.
All and all — that basically makes the Duck hunter ineffective (especially since, I as a stated earlier, it disrupt normal operations, to the point that work cannot be completed).
And sure, the scenario depicts a running machine, but if the machine can be rebooted to fool it (as with blocking the function against usb-devices connected at boot) that, too, renders it ineffective.
I guess the only real way to prevent hardware access would be to encase the computer’s tower (including ports, etc) in some type of protective material (such as a safe, etc) — the only way that an attacker would do anything physically to the system would be cut and modify cables and that would be very noticeable.
Also, I don’t see many attackers wanted to spend the time to boot up into linux from a usb drive (mainly because that would require more time than they probably have, and would expose them).
Could it selectively apply this only to commands sent to CMD or Powershell?
The speed at which it is set it right now is simply unachieavable by humans (even if you let a key pressed), so thankfully you wouldn’t have that issue.
from the hack a day article back in 2009
http://hackaday.com/2009/09/18/how-to-write-udev-rules/#more-15328
any USB thumb drive in my linux machines that hasn’t been “authorised” gets formatted EXT2.
I get people bitching “they lost their data” after coming in and without asking inserting a thumb drive!!!!
This won’t work on the usb rubber duckie. It’s not a usb drive, it just looks like one.
Just use a DENY ALL at Udev, replicate to initrd or initramfs as well.
But yeah, i agree with you since Rubber is not a storage usb.
You’re not wrong, Walter…
Thank god i use linux-grsec on Arch based desktop :)
https://wiki.gentoo.org/wiki/Allow_only_known_usb_devices
How do you install a new keyboard if your current one dies?
Its a desktop. Just hit power, wait for the shutdown process to finish, plug new keyboard, boot again. A Keyboard death is not an event as common as “plug a disk”, and i don’t think this should be the end of the world
Also, you could simply find what is the new keyboard with any virtual keyboard solution, and then:
echo “1” > /sys/bus/usb/devices/xxx-y/authorized
I think the virtual keyboard solution will take more time ;)
So then this won’t work, the ducky shows up as a hid device, not a drive.
Did you read the documentation?
GRKERNSEC_DENYUSB will make ALL USB DEVICES BLOCKED, except the ones connected on boot, or the ones you allow with echo 1 at the device identification file, no matter if disks or hid. When is said that a keyboard death is not as common as a disk being connected through USB, that does not mean GRKERNSEC_DENYUSB does not work with HID hardware.
You are just making a mountain out of a molehil for a simple solution on desktop: Reboot(to have your device recognized on boot) or use a virtual keyboard to enable you newly connected keyboard
Unfortunately, that is still not secure enough and can be bypassed/fixed on reboot and someone with enough skill, and determination, can figure out how to get back-in to the system at boot.
Also, if a usb device is connected at boot — it’s possible that device will be authorized.
More security also means less convenience. You could also create a udev/eudev rule that would block ALL DEVICES, except the ones you know/trust. Take a look at the Writing eudev rules topic.
If someone have access to your machine and CAN reboot it, you have other problems to deal with.
There is full disk encryption or BIOS set password that would block reboot, but again, is the eternal struggle of security agains convenience…
Well when it comes right down to it, attacker has physical access to machine… game over, you’ve lost. All you’re really preventing is skiddie level BS.
If you want to get ridiculously sophisticated and targetted, there’d be attack vectors like endoscope type equipment for finding the CMOS reset, or could install SATA interposers that report on all traffic, or PLCC sockets that clip over the legacy KB/IO chip and transmit everything, or inject stuff. Hell, BT chips are small enough now you could pry off the plastic motherboard pin header shell and put a replacement back on that has a BT device inside it, so even regular visual inspection of the machine would not clue you in. You can probably hide quite a sophisticated device in something that looks like a clip on ferrite suppressor.
If this sounds too “James Bond” remember classic JB gadgets were the limit of technological conceivability in the 70s and 80s, presented as the work of an agency with a huge black budget for such stuff. This was the time that the computing capability of a Pi Zero cost several million dollars. Hello, McFly, it’s 2016.
Sure, but all that’s a bit more complicated and difficult than just plugging in a Rubber Ducky. Which doesn’t need access inside the case. One problem at a time!
How about a Bluetooth transmitter which plugs onto an unused USB or 1394 pin header, and looks like some jumper caps?
and this, not totally true. Initrd can load udev rules, to avoid “pre-kernel” exploitation
https://wiki.archlinux.org/index.php/Mkinitcpio
You can go as far as it takes to prevent thus usb exploitation and MAYBE boot based atacks(aka Evil Maid Attacks)
– UEFI Secure Boot
– Also denying boot of BIOS/MBR based pendrives.
– Full disk Encryption(letting only EFI partition unencrypted).
– Sign your grub efi BOOTx64.efi with your own keys(remember that the kernel is inside your encrypted partition)
– Revoke Microsoft keys on UEFI configuration.
– Hide UEFI variables after control is passed to the kernel.
– Password on UEFI
People will find a way to break it, if they have physical access. Or maybe, the user will just buy vPro(SME) enabled processors and let the corporates spy on you, cause hackers wearing suits are always the coolest ;)
So STOP creating more and more scenarios. We all know where this security circle will get if you implement all the available mitigations.
That’s why i use linux-grsec on my Arch Linux
https://git.archlinux.org/svntogit/community.git/tree/trunk/config?h=packages/linux-grsec
Hardened Gentoo guys have a good documentation about it:
https://wiki.gentoo.org/wiki/Allow_only_known_usb_devices
Security options —>
Grsecurity —>
[*] Grsecurity
Customize Configuration —>
Physical Protections —>
[*] Deny new USB connections after toggle
[ ] Reject all USB devices not connected at boot
GRKERNSEC_DENYUSB
Related sysctl variables:
kernel.grsecurity.deny_new_usb
If you say Y here, a new sysctl option with name “deny_new_usb”
will be created. Setting its value to 1 will prevent any new
USB devices from being recognized by the OS. Any attempted USB
device insertion will be logged. This option is intended to be
used against custom USB devices designed to exploit vulnerabilities
in various USB device drivers.
For greatest effectiveness, this sysctl should be set after any
relevant init scripts. This option is safe to enable in distros
as each user can choose whether or not to toggle the sysctl.
Unintended consequences # whatever, I’m not keeping count….
Your user who has a terrible memory for passwords finds his mooltipass or similar no longer works, and goes back to using password1, password2, football, swordfish, pa55w0rd, etc etc,
Hey RW, thats a good point. As of right now, I just updated it such that it works with tools like LastPass, Breevy, KeePass or other similar software solutions that AutoType passwords (so that they don’t get caught like false positives). I’d have to look a bit deeper into Hardware solutions such as Mooltipass. :)
Instead of skipping every x keystrokes, why not only recognize one keystroke every x milliseconds. that way a human typist will not see any difference. Then again, skid kystrkes culd b entrtainin. (if you never spell check, but who does that?)
Better yet, allow a certain maximum rate averaged over 5 keystrokes or so — so particularly fast sequences (double letters, alternate-hand home-row keys, etc.) in natural typing are less likely to be jammed, while still catching automated machine-gun typing.
This approach is tempting, but of course the minute such a countermeasure becomes popular, attacking devices will self-limit to just below the common rate, so long-term you’re not rejecting attacks, you’re just making them slower. That makes the attack more obvious, and could buy enough time to pull the USB device before the attack completes, but the intended victim of these things probably won’t realize what’s going on in time to react.
Dumb question; can you detect a second keyboard and not allow 2?
I was thinking that too. I bet a udev guru could create a rule, this should be in all distros. Hell, code it into the kernel…….
What am I missing, is there a reason that would not work?????
The only reason I would want a second keyboard is for those few times I plug my USB-converted Model M into my laptop. For that reason, there should be a simple override for a second KB. The trick is to make it easy for me to do without making it easy for a hacker to do.
‘Tis most annoying when BIOS setup recognizes a keyboard, and USB legacy support is enabled, and Windows Setup recognizes the keyboard – then suddenly Windows has total amnesia about the keyboard until setup is all finished and it goes “Oh hey! I found a keyboard! Want me to install the generic HID keyboard driver for it?” Then it’s also forgotten the USB mouse which has been working up to then.
Then I have to dig through my old stash for a PS/2 mouse or sometimes just plugging in a second USB keyboard or mouse will have that one working while Windows “installs” the ones it had been working with.
How about writing a HID/keyboard driver that would require you to type a secret pass phrase before you can actually use it?
E.g. plug in keyboard, num lock led lights up so you know the driver has been loaded, type password and press enter, password good? light up all three leds… Password wrong? blink num lock led..
After you’ve typed the password wrong 3 times block all new HID devices from registering for 10 seconds or so in order to prevent devices from simulating different VID PID combinations to instantly try again..
^– pretty ingenious way of handling that
How about something that detects when 2 keyboards are attached? Then it pops up a window on screen asking you to type something in, a random collection of letters, from the attached keyboard? A sort of Captcha for hardware.
You could even hack something like this into the standard USB keyboard / HID drivers. You could even, even, require it for all keyboards, even 1, attached to the system. It could perhaps remember previous legitimate keyboards, if different keyboards send different data to the USB host when they enumerate. In that case it’d only need doing once per keyboard.
Or some totally different way. It seems like Rubber Ducky only had a chance when people didn’t know about it, as it becomes more widely known, the problem will be fixed.
Hi guys, I’m the dev from Duckhunt. I’m excited to see this in hackaday.com
This article left out an important detail that I would like to further explain:
– As many of you have noted, this is not a comprehensive solution, however my big motivation to start this project was to begin a discussion discussion and engage with others about potential ways to protect users from these kinds of attack.
– I’m honestly really happy to see all the comments and feedback from different protection angles, fixes, issues, etc. and definitely will keep looking into it.
– I know that protecting a user 100% from a targeted attack might be unrealistic, but I would want a user to at least be protected from the most common case scenarios.
– Definitely feel free to contact me or engage in the repo :)
Cheers!
Konuko II
Oh! another quick thing is remember Keystroke Injection attacks could theoretically be done through other mechanisms (HID injection, Mousejacking) aside from rubberducky, so perhaps there are multiple angles that need to be covered aside from the Rubberducky/BadUSB attack.
wow….this interest me