Archive for February, 2012

 

Don’t Stick That in There – HID (Human Interface Device)

Feb 05, 2012 in Security

[SecurePlanet Wiki][SecurePlanet RSS Feed][SecurePlanet RSS Vulnerabilities]

You might have heard about teensy or HIDs from a bunch of the security conferences recently, but if you haven’t let me tell you how cool they are.  What is a HID device you might ask?  You can go to Wikipedia’s definition, but in this case, the purpose of the HID device is to emulate a physical keyboard.  I do know that Irongeek did a lot of work with Human Interface Devices (HIDs) www.irongeek.com in the past and demonstrated a number of different attacks in his last couple of talks.  Well at Shmoocon last weekend, I was finally able to pick up one of these devices and played around with it.

 

The Rubber Ducky:  The hardware is an Atmel 32bit AVR Microcontroller AT32UC3B1256 board, with a microsd slot and a usb connector.

When this USB device is plugged into the computer, the computer won’t recognize this as a storage device, but instead as a keyboard.  So what you could do is program this device to type out things that a user sitting at the machine would have done.  The benefit of this is that even with USB auto-run disabled, our exploit will still work as it emulates a keyboard.  No one ever blocks USB keyboards!

The scripting language that is used with this device is called “Duckyscript“.  It is pretty straight forward and easy to code in.  For example:

GUI r
DELAY 50
STRING notepad.exe
ENTER
DELAY 100
STRING Hello World
ALT f
STRING s

The following code presses the Windows Key and R (to get to Run), types in “notepad.exe”, hits enter, write “Hello World” and saves it.  Easy Huh?

Now we have everything we need to start building our HID device attack.  First we need to define exactly what our HID device is going to do when plugged in.  Do we want it to just mess with the person or is our goal to exploit the machine?  There are scripts out there to flip a users screen once plugged in or even start a key logger on that machine.

What I thought would be best, would be to have the device build a reverse shell back to an IP that I control.  The original concept for the code and explanation is from here: http://dabermania.blogspot.com/2011/04/copying-executable-from-teensy-using.html.  Here is my code in the format used for my device to attack a Windows 7 box:  Duckycode.  What the code will do, is the following

  1. Press the ctrl-esc (equivalent to the windows menu key)
  2. Type cmd
  3. Press the menu key (equivalent to right clicking on cmd prompt)
  4. Press “a” to run as administrator
  5. Click yes to run cmd
  6. Copy the Decoder
  7. Copy the Base64 encrypted reverse shell
  8. Create the executable
  9. Execute the new reverse.exe file and the associated port

What I did to setup this attack is configure one box with a listener on port 8080.  This will be the port that the reverse shell will connect back to.  On the Windows 7 box, I didn’t to anything special to it.  In fact the Windows 7 box is fully patched and antivirus is updated.  What happens next is I plug the USB device into my Windows 7 box and it begins to build the code and then execute the reverse shell.  The animated gif below, shows this whole process, with the last frame showing the connection back to my box.

 

 

Of course this attack is visible to anyone watching the screen.  So what might be the scenario to this?  What about a kiosk with no keyboard but USB ports?  Have you ever been to a store where the register had a computer with USB ports facing the customer?  Why not tell the employee to get the manager and while he is gone, plug in this device and bam… exploited box.  You’ll have to get creative with this attack.  Buy Your Own Here

Over and Out.