Years ago, there was a competition, where contestants had to extract date out of a system that was protected by a state-of-the-art anti-leaking solution. Such challenges are based on the fact that private information should be available for use on a protected computer, but it must stay within the physical boundaries of the system. Obvious methods like networking and removable storage devices are usually covered by these mechanisms, but as with DRM, it's difficult – if not impossible – to think of every possibility. For example, in the aforementioned challenge, some guys used the audio output to get a file off the box – and when I heard about the Little Wire project, I started thinking about a new vector.
The requirements for my solution was to be able to extract data out of a
- Windows 7 box
- with no additional software installed
- logged in as non-administrative account
- that only allows a display, a keyboard and a mouse to be connected.
My idea was to use a USB HID device, since these can be connected to such system without additional drivers or special privileges. I've already built such a device for interfacing JTAG using an Arduino clone and V-USB, so I could reuse both hardware and experience, but avoid using an external programmer. The V-USB library made it possible for me to create an USB device without buying purpose-built hardware, by bit-banging the USB protocol with the general-purpose input and output pins of an AVR ATmega328 microcontroller. When used correctly, the AVR device shows up as a regular keyboard in the Windows 7 devices dialog.
Keyboard was a logical choice for data extraction, since it was the only part
of the HID specification that has a three bit wide output channel that's
controllable without drivers and/or administrative privileges: the NUM, CAPS
and SCROLL lock status LEDs. I've crafted a simple protocol that used NUM and
CAPS as two data bits and SCROLL as a clock signal. When the SCROLL LED was
on, the other two LEDs could be sampled for data. The newline (that could be
achieved by “pressing” the Enter/Return key, since we're already “keyboards”)
was the acknowledgement signal, making the protocol fully synchronous.
For example, the bits 1101 could be sent in the following way:
__________________________________
NUM ____/
_______________
CAPS _______________________/
______ ______
SCROLL ________/ \__________/ \_____
01 11
On the Windows host, an extractor agent was needed, that performed the transfer using the following code snippet:
set_lock(NUM, (frame & 0x01) == 0x01);
set_lock(CAPS, (frame & 0x02) == 0x02);
set_lock(SCROLL, 1);
getchar();
toggle_key(SCROLL);
Bits were sent from LSB to MSB, n bytes were sent from 0 to n-1, stored at the nth position in the EEPROM. I tried using an SD card to store the data received, but it conflicted with the V-USB library, so I had to use the built-in EEPROM – the MCU I used was the ATmega328, which had 1 kbyte of it, which limited the size of the largest file that could be extracted.
Of course, the aforementoned agent had to be placed on the Windows box before
transmitting file contents. The problem was similar to using dumb bindshell
shellcodes to upload binary content, and most people solved it by using
debug.com. Although it's there on most versions of Windows, it has its
limitations: the output file can be 64 kilobytes at maximum, and it requires
data to be typed using hexadecimal characters, which requires at least two
characters per byte.
In contrast, base64 requires only 4 characters per 3 bytes (33% overhead instead of 100%), and there's a way to do it on recent Windows systems using a good old friend of ours: Visual Basic. I created a simple VBS skeleton that decodes base64 strings and saves the binary output to a file, and another simple Python script that fills the skeleton base64-encoded content, and also compresses it (like JS and CSS minifiers on the web). The output of the minified version is something like the one below.
Dim a,b
Set a=CreateObject("Msxml2.DOMDocument.3.0").CreateElement("base64")
a.dataType="bin.base64"
a.text="TVpQAAIAAAAEAA8A//8AALgAAAAAAAAAQAAaAAAAAAAAAAAAAAAAAA..."
Set b=CreateObject("ADODB.Stream")
b.Type=1
b.Open
b.Write a.nodeTypedValue
b.SaveToFile "foo.exe",2
The result is such a solution that makes it possible to carry a Windows agent
(a simple exe program) that can be typed in from the Flash memory of the AVR,
which, when executed, can leak any file using the LEDs. I successfully
demonstrated these abilities at Hacktivity 2012, my slideshow is available
for download on the Silent Signal homepage, videos should be posted soon.
The hardware itself can be seen below, the self-made USB interface shield is
the same as the one in the V-USB wiki hardware page.
The hardware itself is bulky, and I won't try to make it smaller and faster any time soon, since I've already heard enough people considering it weaponized. Anyway, the proof-of-concept hardware and software solution
- can type in 13 characters per seconds from the flash memory of the AVR,
- which results in 10 bytes per seconds (considering base64 encoding),
- and after deploying the agent, it can read LEDs with 1.24 effective bytes per second.
All the code is available in my GitHub repositories:
- the code running on the device, written in C, released under OBDEV license,
- the Windows agent, also written in C, but released under MIT license, and
- the base64 VBS encoder, written in Python, also released under MIT license.