[Question] Defences Against the Ducky?

[bag-de-body]

Hmmm... so I'm thinking, how do I defend myself against this thing?

1. Our PCs are fairly locked down - so you wouldn't (for example) be able to use Start>Run as a normal user.
2. Physical security: Don't plug in unknown USB sticks when you're an administrator - common sense really - and naturally enough don't leave your machine physically accessible to third parties anyway.
3. You might be able to detect this on the basis of the speed of typing - even if we assume a really fast typist, there's probably some sort of clue with respect to regularity of the keystrokes.

I suppose you could pretend to be a memory stick as well as a HID? We're used to occasionally seeing the "Windows has detected new hardware" message, and most of us will plug in a memory stick without really thinking. (Usually because we think our virus checker will protect us.) Assuming that you did go the Start>Run route, then you could deliver your payload while their back is turned with a wireless click - so they wouldn't see the momentary flash of the dialog on screen. You could even disguise it when they're browsing the net - they'd probably think it was a pop-up.

The key thing is to know it's out there, so you're better prepared.

That said, if you've physical access, wouldn't it be better to sit as a keylogger in between - perhaps disguised as a USB hub? You'd be more likely to go unnoticed, as you're being passive, not active?

[Netshroud]

The Defense against this

[bag-de-body]

The Defense against this

Phew, luckily we do quite a lot of that with regard to physical security. They could get a cherry picker to get up to our office window - but I'm sure our CCTV operators would notice that overnight. During the day we have rabid children patrolling the site :-)

Edited April 15, 2010 by bag-de-body

[Darren Kitchen]

Hold down CTRL on the keyboard of the victim machine.

There might be a way to disable foreign HIDs using group policies. If not now, likely in the next version if this takes off.

[Burning Aces]

wouldnt you just leave your pc locked when ever you are no longer looking at it. complex password of say 21 characters that rubber ducky cant do much then

[Guest Deleted_Account]

Hold down CTRL on the keyboard of the victim machine.

There might be a way to disable foreign HIDs using group policies. If not now, likely in the next version if this takes off.

Not sure if it would work against the ducky but i am using group policies to stop foreign USB drives and USB CD/dvd drives as well. I dont think it will stop Human Interface Devices however also i noticed that before logon if i plug my USB drive in it will mount ( or at least make the sound) but as soon as i login the Policy kicks it.

wouldnt you just leave your pc locked when ever you are no longer looking at it. complex password of say 21 characters that rubber ducky cant do much then

True but what if the person doesnt logout or forgets to? or maybe They have a less secure account? how about booting into safe mode and the ducky access the default Admin account? I mean the first time i installed XP home SP2 it did not ask me to password it how many people dont even know its there? Just saying the norm. will not think about this being possible and wont protect against it.

Edit: What if the alternate ctrl-alt-del method is active? can the ducky simulate those key presses? I have never tried ( I think that this login method is just a false sense of security) but according to MS isnt this login method supposed to prevent these types of attacks?

Edited April 15, 2010 by x942

[shadowpwner]

Edit: What if the alternate ctrl-alt-del method is active? can the ducky simulate those key presses? I have never tried ( I think that this login method is just a false sense of security) but according to MS isnt this login method supposed to prevent these types of attacks?

Citation needed, but the Ducky will be able to, as it's just another keyboard.

Edit: here's a reference

"The Ctrl+Alt+Del key sequence is reserved by Windows and cannot be trapped by any application. Windows blocks the Ctrl+Alt+Del from being sent to applications which makes it extra complicated to have a fake pop up screen co-existing together with the Ctrl-Alt-Del sequence. This makes Ctrl+Alt+Delete an extra measure of security."

http://www.maxi-pedia.com/Enable+Ctrl+Alt+...r+Windows+Vista

Ducky should be able to bypass that quite easily.

Edited April 15, 2010 by shadowpwner

[switz]

Citation needed, but the Ducky will be able to, as it's just another keyboard.

Edit: here's a reference

"The Ctrl+Alt+Del key sequence is reserved by Windows and cannot be trapped by any application. Windows blocks the Ctrl+Alt+Del from being sent to applications which makes it extra complicated to have a fake pop up screen co-existing together with the Ctrl-Alt-Del sequence. This makes Ctrl+Alt+Delete an extra measure of security."

http://www.maxi-pedia.com/Enable+Ctrl+Alt+...r+Windows+Vista

Ducky should be able to bypass that quite easily.

Yeah ctr-alt-del is just a key combination the OS won't know that the user really isn't using a USB keyboard. Making the ctr-alt-del command unable to stop you. :)

[Guest Deleted_Account]

Citation needed, but the Ducky will be able to, as it's just another keyboard.

Edit: here's a reference

"The Ctrl+Alt+Del key sequence is reserved by Windows and cannot be trapped by any application. Windows blocks the Ctrl+Alt+Del from being sent to applications which makes it extra complicated to have a fake pop up screen co-existing together with the Ctrl-Alt-Del sequence. This makes Ctrl+Alt+Delete an extra measure of security."

http://www.maxi-pedia.com/Enable+Ctrl+Alt+...r+Windows+Vista

Ducky should be able to bypass that quite easily.

Ah i must have misunderstood that :P make sense then. Although i think it is still a false sense of security :P well i am glad it wont stop the ducky more evil stuff to be done now :)

[moonlit]

Let me count the ways:

* Group policies will cause the Run dialog to fail.

* User typing will cause any command to fail.

* Another window becoming active and stealing keyboard focus will cause the entire process to fail.

* HID or USB devices in general can be programmatically blocked, disabled, ejected, etc causing the process to fail.

* Linux can white/blacklist USB devices which will cause the process to fail.

* Any applications which repurpose key combinations will cause the process to fail.

* The device receives no feedback from the host machine and thus is unaware of timing, delays, active windows, etc which will cause the process to fail.

This project is flawed. F L A W E D.

[Sitwon]

I don't think the rate of typing would be a practical method for determining if it's hostile. There are some legitimate products that work on the same principal.

Eg.: http://www.yubico.com/products/yubikey/

[Trip]

im not discussing this i would prefer any loopholes left open for as long as possible lol

i have some pretty cool ideas on the subject tho .... one that would stop this working almost completely

but who wants that?

[Guest Deleted_Account]

Let me count the ways:

* Group policies will cause the Run dialog to fail.

* User typing will cause any command to fail.

* Another window becoming active and stealing keyboard focus will cause the entire process to fail.

* HID or USB devices in general can be programmatically blocked, disabled, ejected, etc causing the process to fail.

* Linux can white/blacklist USB devices which will cause the process to fail.

* Any applications which repurpose key combinations will cause the process to fail.

* The device receives no feedback from the host machine and thus is unaware of timing, delays, active windows, etc which will cause the process to fail.

This project is flawed. F L A W E D.

While i agree with what you said there are some problems with it:

1) Group Policies themselves are flawed it is not that hard to bypass them (unless some paranoid person went and spent hours (6 or more at least ) blocking programs and USB HIDS and essentially made a sandboxed user)

2) True typing user would screw this up but there are 2 solutions to this: First why is there a user on the comp anyways? i dont think it is ment to be used this way my understanding of it (correct me if i am wrong) is that you (attacker) walks up to PC (victim) and inserts usb ducky which runs its payload and finishes you unplug and walk away no user at the comp besides you. Second set the ducky to stop regular key board in put (override the user).

3) Why would another window open if there is no user? if there is a user there block mouse input too (disguise as an error)

4) This is true i do this all the time and these (especially commercial versions) are next to impossible to get around.

5) This is true again :)

6)Also true but couldn't you counter this with a script on the ducky to undo the "repuposing" of key combinations? and come on how many people would actually do that? lol

7) Wouldn't the user before hand figure that information out? also if this was being used to brute force a password at login then this would not be a problem :P (as no other windows could be open) and as a side note if the comp was logged in the Attacker could merely close the windows.

[Xqtftqx]

What about this, when you plug in a USB Keyboard is a computer, and press one of the lock keys, such as Num Lock the light on the other usb keyboard lights up.

That gives you a total of three switches, when it plugs in, turn off all locks, then wait for a certain combo. That gives you a total of 9 methods using the 3 locks.

Also, keep in mind that these are microcontrolers, im not sure if this is correct, but if we can run code before windows adds the keyboard. It could generate a fake ID every time. Also add a few "echo <random string>" randomly in the string thats getting put into the run window.

Edited April 16, 2010 by Xqtftqx

[shadowpwner]

Also, keep in mind that these are microcontrolers, im not sure if this is correct, but if we can run code before windows adds the keyboard. It could generate a fake ID every time. Also add a few "echo <random string>" randomly in the string thats getting put into the run window.

Hmm.. getting anti-virus to recognize suspicious signatures from a HID. I'd say we have a good 6 months to a year before they start catching on.

[Guest Deleted_Account]

Hmm.. getting anti-virus to recognize suspicious signatures from a HID. I'd say we have a good 6 months to a year before they start catching on.

ha! agreed and you will see Bill Gates going curse you Hak5!! the evil server was enough but now we are being attacked by evil duckys!!! :P followed by Steve Jobs asking how it is possible for a mac to be compromised :S

[shadowpwner]

ha! agreed and you will see Bill Gates going curse you Hak5!! the evil server was enough but now we are being attacked by evil duckys!!! :P followed by Steve Jobs asking how it is possible for a mac to be compromised :S

Which is ironic since Windows had developed an extremely basic version of the switchblade and offers it to government and investigators.

@Moonlit - though I agree with most of the things you say, the chances of those happening on a user's computer while running Mr. Ducky is minimal. What are the chances of say, an IM screen poppinp up while Mr. Ducky is doing his business? etc etc.

[Netshroud]

The chances of a popup are extremely small, especially since the Ducky is lightning-fast.

[jdogherman]

There should be a way to limit HID devices save for a approved devices.

That is really what we are exploiting the inherit trust provided to HID devices by the system.

If this takes off (like U3 options) Im sure there will be a fix for it.

[moonlit]

There should be a way to limit HID devices save for a approved devices.

That is really what we are exploiting the inherit trust provided to HID devices by the system.

If this takes off (like U3 options) Im sure there will be a fix for it.

If I was any better at coding, I'd have an answer to that by now. I know it's possible to write a HID blacklist/whitelist but since I don't know enough about it I'm finding it a little tricky.

[Paul Stoffregen]

I know it's possible to write a HID blacklist/whitelist but since I don't know enough about it I'm finding it a little tricky.

It may be possible (eg, udev rules on modern linux), but that won't be very effective.

Everything the host (PC, Mac, etc) can know about the USB device is under the device's control. In Teensy (and virtually all microcontrollers with USB), code produces all that data. For example, if you use Arduino/Teensyduino, this code is automatically built into the executable image:

#define VENDOR_ID               0x16C0
#define PRODUCT_ID              0x0482

static uint8_t PROGMEM device_descriptor[] = {
        18,                                     // bLength
        1,                                      // bDescriptorType
        0x00, 0x02,                             // bcdUSB
        0,                                      // bDeviceClass
        0,                                      // bDeviceSubClass
        0,                                      // bDeviceProtocol
        ENDPOINT0_SIZE,                         // bMaxPacketSize0
        LSB(VENDOR_ID), MSB(VENDOR_ID),         // idVendor
        LSB(PRODUCT_ID), MSB(PRODUCT_ID),       // idProduct
        0x00, 0x01,                             // bcdDevice

It's pretty trivial, even if you have no programming skill, to just find these files, named "usb.c" and "usb_private.h" and edit the USB descriptor data to anything you want.

Less trivial, but not very difficult if you know C, would be changing the code which transmits this data. Instead of reading it from a static array in memory, certain numbers like vendor id, product id, bcdDevice could be created at random, or tried from a list of known common keyboards, or any other algorithm you can craft.

Also possible, but definitely not trivial, would be making use of the detach capability. Most USB devices have a resistor soldered to one of the data lines, which is how the PC knows the device is present. There isn't a physical switch in the connector, it's that resistor which signals a device is plugged in. In the AVR USB chip on Teensy, that resistor is under software control. In fact, every time you reprogram Teensy, that resistor is disconnected and then reconnected, which is to your PC looks like the old device was physically unplugged, and then moments later a completely new device (implementing the ability to download your new code) gets connected. After your code cownload, the same thing happens again. That's how you can so easily try new USB devices with Teensy.... every time you reboot your code, your machine believes the device was physically unplugged and then a new device gets plugged in.

With the detach capability under your code's control, if you don't get the desired results, you could just detach and try again (maybe much later... the PC can't tell you're still physically present), perhaps with new randomly generated ID numbers or some other strategy.

A whitelist/blacklist defense just doesn't have any trustable data available.

Ultimately, blind trust in HID keyboards is the weakness. Perhaps a solution would might involve a one-time authorization process for a new keyboard? But who do you trust for user input to authorize a new keyboard? The USB HID mouse?!?

And if an attacker has physical access, what's to stop them from momentarily unplugging the trusted keyboard and using another machine to capture all its USB descriptors? For example, my "ID 05AC:0220 Apple, Inc. Aluminum Keyboard" returns an empty field for the optional USB serial number. Even if it did have a serial number, it's right there to read and copy.

USB HID doesn't have any challenge/response authentication, so all trusted data could be easily captured. Perhaps public key signature capability to prove a device's unique identity would give you something useful to trust the device hasn't been copied. It seems pretty unlikely keyboards will get that class of hardware anyday soon!

Security is difficult.... much harder than just designing working USB devices.

Edited April 16, 2010 by Paul Stoffregen

[1n5aN1aC]

Security is difficult.... much harder than just designing working USB devices.

Ain't that the truth!

And really, if you design a system where you have to allow each device manually, who cares? You just click "Allow" Besides, most users are still clueless.

[moonlit]

http://www.hak5.org/forums/index.php?showtopic=16255

[1n5aN1aC]

In my opinion, the question ultimately becomes: is there any identifying factor that the teensy shows/give off/whatever that we can see as the operating system? If there is no identifying factors, (under hardware details for example) then there is no real defense that is not very VERY inconvenient to the end user.)

[shadowpwner]

This would definately work! At college all the USB ports at college are disabled to prevent some crap about virii..

Don't know whether anyone here has a clue how they managed it?

BIOS.

http://www.geekinterview.com/talk/2428-how...-usb-ports.html