[Info] Potential Solution To The "read Only" Usb Keyboard

[boingo]

So, there are many good reasons to emulate a keyboard device. 99.995% of security programs do not restrict them is probably chief among them.

One issue with emulating the keyboard device, is that you can't write to it. To write, you need to be a remote storage device, which IS protected (in some cases.)

However, you CAN write to a keyboard device. That's how you turn on the keyboard caps lock light!

(old article that should still be valid, http://www.beyondlogic.org/keyboard/keybrd.htm)

God only knows how difficult it would be to make an program that transferred data this way, and I bet it wouldn't be too speedy, but there is no reason it couldn't be done, and the transfer would be at USB speeds, even if it was serial. It could be used to copy smaller files, or copy data over time (plug it in to the back and leave it overnight.)

Any thoughts on this being possible, or likely to be done in my lifetime?

-boingo

[Mr-Protocol]

Mocking up the teensy or the new ducky does not get seen by the OS as a storage device as far as i know. It is just used for local storage of payloads to/for the teensy/ducky.

[boingo]

Right, and that's good, but all the posts I've seen talking about writing back to the ducky state that the ducky would have to emulate a USB storage device for that to work.

That is fine and dandy unless the target system prevents writing data to removable devices (ala Digital Guardian, or whatever they call the Vontu product now that its owned by Symantec.)

What I am proposing is a way to write back to the device while it is still only emulating a keyboard. No security product in the world cares if the computer keeps flashing the caps lock key on and off really fast.

-boingo

[ascorbic]

I think in a later firmware release, or sometime after the source code is posted, there will be the ability to have the ducky act as a com port which can send and receive data. THe ducky would then write to storage.

[Darren Kitchen]

Brilliant! I could see adding to the firmware a function that captures capslock and numlock states. That way you could, albeit slowly, send data back to the duck without using conventional means. For example, if capslock represented 1 and numlock 0, with the right payload you could extract hash data from a target machine and send their binary equivelents back to the ducky.

/mind blown

[dazd]

Some academic work has already been done on this, I have listed two papers below that discuss this. In the first paper they developed the system via sending data over the LED status messages they acheived a maximum acheivable throughput of 2.283 bytes/sec. In the paper they describe how their coding scheme works.

Hardware Trojan Horse Device Based on Unintended USB Channels

by Clark, J.; Leblanc, S.; Knight, S.;

Electr. & Comput. Eng. Dept., R. Mil. Coll. of Canada, Kingston, ON, Canada

This paper appears in: Network and System Security, 2009. NSS '09. Third International Conference on

Abstract

This paper discusses research activities that investigated the risk associated with USB devices. The research focused on identifying, characterizing and modelling unintended USB channels in contemporary computer systems. Such unintended channels can be used by a USB hardware Trojan horse device to create two way communications with a targeted network endpoint, thus violating the integrity and confidentiality of the data residing on the endpoint. The work was validated through the design and implementation of a proof of concept hardware Trojan horse device that uses two such unintended USB channels to successfully interact with a target network endpoint to compromise and exfiltrate data from it.

the follow paper is also interesting using jitterbugs

Keyboards and covert channels by Gaurav Shah,Andres Molina & Matt Blaze at the Department of Computer and Information Science, University of Pennsylvania

Published in USENIX-SS'06 Proceedings of the 15th conference on USENIX Security Symposium - Volume 15

USENIX Association Berkeley, CA, USA ©2006

abstract

This paper introduces JitterBugs, a class of inline interception mechanisms that covertly transmit data by perturbing the timing of input events likely to affect externally observable network traffic. JitterBugs positioned at input devices deep within the trusted environment (e.g., hidden in cables or connectors) can leak sensitive data without compromising the host or its software. In particular, we show a practical Keyboard JitterBug that solves the data exfiltration problem for keystroke loggers by leaking captured passwords through small variations in the precise times at which keyboard events are delivered to the host. Whenever an interactive communication application (such as SSH, Telnet, instant messaging, etc) is running, a receiver monitoring the host's network traffic can recover the leaked data, even when the session or link is encrypted. Our experiments suggest that simple Keyboard JitterBugs can be a practical technique for capturing and exfiltrating typed secrets under conventional OSes and interactive network applications, even when the receiver is many hops away on the Internet.

[barry99705]

Brilliant! I could see adding to the firmware a function that captures capslock and numlock states. That way you could, albeit slowly, send data back to the duck without using conventional means. For example, if capslock represented 1 and numlock 0, with the right payload you could extract hash data from a target machine and send their binary equivelents back to the ducky.

/mind blown

Binary is for wimps, have it talk back in Morse code. :D