theduckwhisperer

Suggestion: Two-way RD Communications

3 posts in this topic

tl;dr- Add logic to the RD to monitor key lock values.  Use this for functions like file transfer.

Because I wanted to see if I could, I wrote a VBScript to transmit a file using the Scroll lock, Caps lock, and Num lock keys.  As it turns out, if you record the data with a fast enough camera you can decode the bits and reproduce the transmitted file. Unfortunately, to make it feasible for a camera to pickup the LED fluctuations and and then for a human to interpret the blinks, the transfer rate is very slow.  In fact, if you have the time and ability to use a camera to record the computer, you should really just take a picture of the screen.  

If only there was a technical means of monitoring these LED statuses that could increase the rate at which this could operate...   

(Note: In the above video, you have to view at 60fps and set the playback speed to 25% to even have a chance of decoding it manually)

Fast forward a couple days and I saw another demonstration of the Rubber Ducky on Hak5.  As I understand it, the RD interprets a compiled script and primarily acts as an output only HID. Because of this, payloads from the RD have only two ways of currently gathering information. One is to exfiltrate the data over a network connection (bad because it may be logged by a firewall or proxy), and the other is to switch to USB storage mode (bad because systems may monitor or block USB Mass Storage Devices). However, by utilizing Caps/Num/Scroll lock, payloads could potentially communicate any type of data back to the Rubber Ducky (without tripping any host system security/monitoring). I'm suggesting that some logic be added to the RD to monitor the Key Locks and use them as a way of receiving data.  

In the video demonstration demonstration, I used sendkeys to flip the status on the three LEDs.  Every-other-bit is sent to Num Lock and Caps Lock with Num Lock being bit one, Caps Lock being bit two, and Scroll Lock always being the timing. For efficiency's sake, every transmission of two bits is indicate by alternating Scroll Lock.  This means that with SL turns on, two bits were sent and when SL turns off, 2 more bits were sent. This timing is necessary to indicate to the interpreter (be it human or RD) that the other two bits are current (even if they haven't changed in value).  The script currently lacks any intelligence- it just blindly sends the contents of a file.  But, if the script were to know it was talking to the RD, it could wait for acknowledgements from the RD before sending a file. Furthermore, since this technique would allow two-way communications with the RD, we could incorporate useful file transfer features like CRCs and the inclusion of the file name.

As I mentioned in the beginning, using this technique to visually send information via the LEDs is too slow to really be of any value. But, this same technique may have value when the thing observing the LED value changes is a Rubber Ducky. I estimate that this technique would allow binary data to be sent to the RD at around 1.5 kB/s. Granted, this is a far cry from USB Mass Storage Device speeds and network transfer speeds, but this method doesn't require a system to be on-line and wouldn't leave any trail on the host system*. 

Of course, in addition to file transfers, two-way communications with the RD can open up more possibilities. For instance, the RD could run a script on the host system to see what version of the OS is running and then send the OS version back to the RD.  From there, the RD could send a different script based on the version.  Granted, you could just put this logic in one payload file that is executed on the host, but there may be cases where you want to keep some secret sauce on the RD and never written to a host machine.

The Duck Whisper

*- Okay, some key-loggers might record the key presses. But if the system has a key-logger, it would have recorded the entire RD session anyway.

1

Share this post


Link to post
Share on other sites

This is exactly what I am hoping can be done. Don't have time or skills to achieve it sadly. 

0

Share this post


Link to post
Share on other sites

Sorry for the self-promotion, but this is exactly what I've been working with. :) (Even though my protocol for blinking with the leds is slightly different)

https://github.com/yownas/firefly
 

The windows/powershell-payload doesn't work, yet, but I'll try to find some time to work on it.

It shouldn't be too hard to implement in a rubber ducky firmware.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.