Ugly duck. Turning a regular flash drive into a USB Rubber Ducky

Preface

Last year's Black Hat brought many interesting reports. Among the most discussed was a report on an incorrigible vulnerability in USB devices that allows ordinary flash drives to be turned into a tool for spreading malware. The attack was called BadUSB, but later jokes about “USBola” appeared on the Internet, comparing this attack with a well-known virus.

Similar ideas of using HID devices for personal gain have been around for a long time. It would be a sin not to take advantage of the fact that the OS system trusts devices connected to the USB interface. If you delve into your memory, the magazine already had an article on a similar topic, which talked about how, using a special Teensy device, you can take control of a machine with Windows 7 (in principle, with any OS on board). The device in appearance resembled an ordinary flash drive, which it was actually disguised as. All this made me think that this trick could also be done with flash drives.

Fragment of the file \kali_linux_nethunter_nexus7_2012.zip\system\xbin\start-badusb

The emergence of detailed instructions and ready-made software tools for implementing Bad USB using various commercially available devices indicates widespread interest in this type of attack. You don’t have to be an analyst to predict a sharp increase in the frequency of its use in the near future.

In Windows, you can manually restrict USB connections, allowing them only for certain devices. To do this, you need to change https://www.sql.ru/forum/847468/podkluchenie-konkretnogo-usb-ustroystva access rights to the corresponding registry keys in the [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR] section.

It is likely that developers of antivirus solutions will soon add separate modules for more flexible additional control over USB-connected devices. ESET Endpoint Antivirus, Kaspersky Endpoint Security, the Parental Control component of Dr.Web AV-Desk and other modern comprehensive protection tools can already limit access to removable media and allow activation according to the “white list”. Another thing is that in the case of Bad USB, such measures may not be enough. Most likely, the user himself will allow the connection of a dangerous device, recklessly considering it incapable of causing harm.

Flash storage device

In fact, the OS knows nothing about the connected device. She has to wait until the device itself tells what class of devices it belongs to. If we take the simplest example, when we plug a flash drive into a USB connector, the flash drive tells the operating system not only that it is a drive, but also its capacity. Here I immediately remember the cunning Chinese comrades, who in this way learned to produce flash drives with increased capacity (there were almost a couple of terabytes). To figure out how this is possible, let's remember (or find out) how the system recognizes USB devices.

Flash drive without a beautiful wrapper

Other articles in the issue:

Xakep #200. The Secret Life of Windows 10

• Contents of the issue
• Subscription to "Hacker"

Checking BadUSB WiFi Ducky

It's time to check if any of the boards broke during soldering. We connect the Arduino Micro Pro to the computer and wait until the universal driver for the HID device is installed. Arduino should signal with two red and one green LEDs.

From your phone, tablet or laptop, look at the list of WiFi access points. There should be a new AP called WiFi Duck. If we see it, then everything is working.

WiFi Duck Hotspot

Let's connect to it. The password is quackquack (this is the default password, you can change it in the settings). Now open the browser, go to 192.168.4.1 (this is the default address of the ESP-8266EX in AP mode) and see the control panel of our device.

USB device initialization algorithm

The purpose of USB devices is determined by class codes that are communicated to the USB host to load the necessary drivers. Class codes allow you to unify work with similar devices from different manufacturers. A device can support one or more classes, the number of which is determined by the number of endpoints (USB endpoints). At the time of connection, the host requests a number of standardized information (descriptors) from the device, on the basis of which it makes a decision on how to work with this device. Descriptors contain information about the manufacturer and type of device, based on which the host selects a software driver.

A regular flash drive will have a class code of 08h (Mass Storage Device - MSD), while a webcam equipped with a microphone will have two: 01h (Audio) and 0Eh (Video Device Class).

Device classes

When a USB device is connected, it registers, receives an address, and sends its handle/handles so that the OS will load the necessary drivers and send back the necessary configuration. After this, direct interaction with the device begins. Upon completion of the work, the device is deregistered. An important point to note here: devices can have multiple descriptors, and can also deregister and register as another device.

If you open the case of the flash drive, then in addition to the mass storage device visible to the user, there will also be a controller on the board that is responsible for the actions described above.

The only part of the device visible to the user

We remove the five-second delay at start

One of the annoying things about Digispark is the five-second delay when loading. It is this delay that allows new sketches to be loaded when connected. If you remove it, then to load the program you will need to short-circuit two ATtiny pins. To combat the delay, you will need a new bootloader. You can load it using the programmer, but it's much more fun to use the NOP slide vulnerability to load it from memory, which is usually used for sketches. However, to write the firmware you will still need to remove some fuses inside the chip. And this, unfortunately, still requires the use of a high-voltage (12 V) programmer. They say that in some versions of Digispark the fuse bits are not set, but in mine they were.

Bad USB or a little history

So, at the Black Hat conference last year, two researchers (Karsten Nohl and Jakob Lell) shared with the public their experience of how to reflash a flash drive controller with their own firmware. After some time, such a flash drive was registered as a keyboard and typed the given commands. Due to the seriousness of the problem, the guys did not publish the exploit code. However, some time later, two other researchers (Adam Caudill and Brandon Wilson) at the Derbycon conference presented the world with a workable PoC tailored for the Phison 2251-03 microcontroller. The code is available on github.

Transformation

As you understand, today we will try to turn an ordinary flash drive into a pentester’s secret weapon!

First of all, we need a suitable device. Since the code is posted only for a specific microcontroller, we have two options - either find a flash drive controlled by this controller, or carry out the very difficult work of researching and flashing any other microcontroller. This time we will choose the easier path and try to find a suitable flash drive (and here is a list of vulnerable equipment). The controller is quite common, so even by some miracle I found a suitable one among a dozen flash drives at home.

Let's start doing magic

Having found a suitable device (which you don’t mind losing in case of failure), you can begin to transform it. First of all, we need to download the sources that the guys posted. In principle, the content is listed on their official wiki, but just in case, let me remind you once again what they posted on GitHub:

• DriveCom is an application for interacting with flash drives based on the Phison controller;
• EmbedPayload is an application designed for embedding RubberDucky inject.bin scripts into custom firmware for their subsequent execution when a flash drive is connected;
• Injector is an application that extracts addresses from the firmware and embeds the patch code into the firmware;
• firmware - custom 8051 firmware written in C;
• patch is a collection of 8051 patches written in C.

Functionality of BadUSB WiFi Ducky

Everything on the web interface is spartan, nothing superfluous. Four pages, or tabs, two working and two informational:

Scripts . This tab is designed to work with ready-made scripts. Initially, it is empty, but using the UPLOAD NEW SCRIPT button you can load the written sketch in .ino and .txt formats from the memory of the device (from which you logged in), and then execute it at any convenient time. You can write scripts yourself or find ready-made solutions on the Internet, for example here. Not all of them are working; you will need to test them in advance (the shell allows you to edit them). There is plenty of memory for all this - almost 3 MB.

Scripts page

Live Execute. On this page there is a field in which we write the sketch. It can be executed immediately or saved. When saved, it will appear on the Scripts page. The language for writing a sketch differs from the usual one in Arduino, so below the input field there are instructions with commands and a description of each of them.

Live Execute Page

Settings . This is the access point settings page. Here you can change the name of the access point, password, and make it hidden. You can also specify a script that will be executed immediately when the device is connected to the computer.

Settings page

Info . This page is more for informational purposes only. Here is a link to the author of the project, SDK, web server, scripts and their interpreter. You can also update the ESP8266 firmware version over the air

Info page

Preparing the system

After downloading the archive with sources from GitHub, you will find that most of them are written in C# and need compilation, so you can’t do without a studio. Another tool you'll need is Small Device C Compiler, or SDCC. It will need to be installed in C:\Program Files\SDCC, it will be needed to compile the firmware and patches.

Having compiled all the tools included in the archive, you can once again check whether this flash drive is suitable for flashing:

DriveCom.exe /drive=F /action=GetInfo

where F is, respectively, the letter of the drive.

TIPS

If the experiments went wrong and something incomprehensible is happening with the flash drive, then you can try to bring it back to life by manually switching it to boot mode and using a utility to restore the original firmware. To do this, before connecting it, you need to close 1 and 2 (sometimes 2 and 3) contacts of the controller located diagonally from the point (to make it clearer, see the corresponding figure). After this, you can try to restore the device using the official MPAL utility

We put the flash drive into boot mode by closing the indicated contacts

How to make a program for Windows

To create a program for Windows, download the free Microsoft Visual C++ 2010 Express Windows development tool. On the specified page, find the Microsoft Visual C++ 2010 Express product somewhere in the middle and install it. But before that, make sure that you do not have the .NET Framework version higher than 4 installed. If it is installed on your system, uninstall it before installing it. The kit will include the required version 4 framework automatically. Otherwise, your projects will not work, and an error will occur - Microsoft Resource File To COFF Object Conversion does not work
when you try to compile the project. Windows update will automatically try to install the latest version of the .NET Framework, you need to cancel this installation - do not restart the computer with new updates, but go to Windows Update and uncheck the box next to the framework.

1) Go to the site, select the Russian language, click INSTALL NOW. 2) After installation, launch it and click Create Project. First, let's create a simple program with 1 button - press this button, the text in it changes. 3) Select the Windows Forms Application template, enter the name of the program below, and click OK. 4) Drag the Button element from the right onto the central window with the form and leave it inside the form. 5) Click on the form and the button, there is a Properties window at the bottom right, its contents change. In this window we set the necessary properties of the elements - the text of the button and window. Edit the Text property and write any text there, for example, My Button. The text on the button changes, this can be seen on the form in the central window. 6) Now we’ll make sure that when you click on this button, its property, which determines the text on it, changes to another. You can also change any other properties. 7) Double-click on the My Button button, which is located in the form in the central window, and get into the code file Form.h (you can select it at any time on the left in the menu). In this file, after double-clicking, the button1_Click function was created (the rest of the code was automatically created according to the template when creating the project), the cursor is inside it, press Enter to create an empty line where we will write the code. As you can see in the same file, a little higher up there are sections - button1 and form1, where the initial settings for the elements - buttons and forms are specified. Let's use them, copy inside our button click function (this place is marked with a red arrow) the line where the name of the button is set, namely this->button1->Text = L"My button";

Only the text My button will be changed to Working!
9) Click on the button with a green triangle, after a while our program will start (if you haven’t made any mistakes) and when you click on the button, the text inside changes from My Button to Working! 10) You can pick up the finished program (.exe file) in the current user’s directory ...Documents\Visual Studio 2010\Projects\Robot Control\Debug
The whole process is shown in the pictures.

Transferring a USB program to Windows Forms.
I moved the control program from the console application to the application with Windows windows and improved it a little - I made stepper motor control in addition to LED control, added hot keys for starting the motor in a certain direction with a given number of steps, the control signals of the stepper motor driver are connected to the PB7 ports ( step), PB6 (direction), PB5 (power), the LED is connected to the PB0 port. You can just my project for Microsoft Visual C++ 2010 Express Edition (Russian version) and see how I did it.

We get burner image

The next important step is to select a suitable burner image (8051 binary responsible for dumping and uploading firmware to the device). Typically their names look something like this:

BNxxVyyyz.BIN

Where xx is the version number of the controller (for example, in the case of PS2251-03 it will be 03), yyy is the version number (not important), and z reflects the size of the memory page and can be as follows:

• 2KM - for 2K NAND chips;
• 4KM - for 4K NAND chips;
• M - for 8K NAND chips.

Where to look for a suitable burner image for your flash drive, you can see this link.

High voltage programmer

If you choose the route with a high-voltage programmer, then there is a large selection of devices - for example, $60. However, you can get by with an Arduino Nano v3 for $4 and a development board. Someone made an Arduino sketch that automatically clears the safety bits, which is very convenient for us. Steps 1-3 from the tutorial for this operation led me to the desired result.

Instead of connecting the ATtiny directly to the breadboard, I used the SOIC-8 clamp to program the chip directly. I also replaced the twelve volt battery with a five volt booster for 5 bucks. I used all this so much that I moved it from the breadboard to the more permanent ProtoBoard.

Dump the original firmware

Before you start your dirty experiments that can kill the flash drive, it is strongly recommended that you dump the original firmware, so that if something goes wrong, you can try to restore the device’s functionality. First, put the device into boot mode:

tools\DriveCom.exe /drive=F /action=SetBootMode

After this, you again need to use the DriveCom utility, to which you will need to transfer the letter of our flash drive, the path to the burner image and the path to the file in which the original dumped firmware will be saved. It will look like this:

tools\DriveCom.exe /drive=F /action=DumpFirmware /burner=BN03V104M.BIN /firmware=fw.bin

If you did everything correctly, the original firmware will be saved in the fw.bin file.

Preparing payload

Now it's time to think about what functionality we want to get from our flash drive. If you remember Teensy, there is a separate toolkit for it, Kautilya, which allows you to automate the creation of payloads. There is a whole website for USB Rubber Ducky that allows you to create scripts for the device to your liking directly online using a convenient web interface. And this is in addition to the list of ready-made scripts that are on the project’s Github. Luckily for us, Ducky scripts can be converted into binary form and then integrated into the firmware. For this we will need the Duck Encoder utility.

As for the scripts themselves, there are several options:

• you can sketch out the required script yourself, since the syntax used is not difficult to master (see the official website of the project);
• use ready-made options posted on GitHub, fortunately there is a reverse shell and other goodies there - all that remains is to correct and convert to binary form;
• or use the above-mentioned site, which will guide you step-by-step through all the settings and allow you to download the finished script in the form of a Ducky script (or already in converted binary form).

Better than Rubber Ducky

You've probably already heard about Rubber Ducky. This is a BadUSB device for HID attack. Devices of this kind can emulate a keyboard and allow you to send any commands as if they were typed by the current user.

These devices have a simple microcontroller and memory into which the sketch (code for Arduino and similar development boards) is written. It contains the function of emulating the desired device and a set of actions it performs. As practice shows, this is usually the keyboard and the sequence of keys “pressed” on it.

Of course, these devices also have their drawbacks. First, you need to carefully reconnoiter the complete configuration of the victim computer. Secondly, before a real attack, you need to check how it will be performed on a test system that is as similar as possible, and make the necessary adjustments - in particular, select the optimal delays. In real conditions, it will most likely be problematic to approach the attacked computer a second time, and if even one key scan code is sent at the wrong time, then everything will be in vain. Thirdly, you can only use one sketch. You cannot add a function on the fly or interrupt and restart a set of actions. In this article I will show how to create a device that is free of these disadvantages.

Uploading the firmware

As soon as we have a ready-made payload in our hands, the time will come to implement it in the firmware. This is done with the following two commands:

copy CFW.bin hid.bin tools\EmbedPayload.exe inject.bin hid.bin

Please note that the firmware is first copied to hid.bin, and only then flashed. This is done this way because the payload can only be implemented into the firmware once, so the original CFW.bin must be kept intact.

After such manipulation, we will have a custom firmware file hid.bin with a payload embedded in it. All that remains is to upload the resulting firmware to the flash drive:

tools\DriveCom.exe /drive=F /action=SendFirmware /burner=BN03V104M.BIN /firmware=hid.bin

where F is, again, the letter of the drive.

Changing a computer program

1) Open the file C:\OpenRobo\set-led.c
2) You need to learn how to send more complex messages to the microcontroller, upon receiving which it will perform the necessary functions. Now only 2 messages are sent in the isOn variable - 0 = turn off the LED, 1 = turn on the LED. Let's also learn how to send code 2 = set the LEDs through one on port B (in the previous example, we prepared a microcontroller to process this code, now we’ll just send it with a program from a computer).

3) Edit the file set-led.c

insert from the top of the line

the following code which adds a new call code 2 for the microcontroller function

The code sends command 2 to the microcontroller, which causes the disco to start there. We rebuild the program for the computer and a new command becomes available to us - discoteka
.
This way you can insert any other codes and functions for them. In C++ there is a function Sleep(1000);
it sets the execution delay in milliseconds, for example 1000 is 1 second. It's useful and you can also use it to make the LEDs blink. This feature will come in handy in the future.

Pay attention to the usb_control_msg

, in it you can pass 2 changeable parameters (in the first we pass 2 or the isOn variable, which is equal to 1 or 0), the next number (there is 0) can pass 1 more value, for example, 1 variable can still be the original command on or off, and the second variable can be passed, for example, the port number that should be enabled. These parameters can be accessed in the microcontroller program by the names p1 and p2, for this example p1=2, p2=0.

Alternative options

In addition to using the HID nature of the flash drive and turning it into a keyboard that types our payloads, we can do a few more tricks. For example, you can create a hidden partition on your device, reducing the amount of space that the OS can see. To do this, you first need to get the device size in logical blocks:

tools\DriveCom.exe /drive=E /action=GetNumLBAs

Then in the patch folder you need to find the base.c file, uncomment the line #define FEATURE_EXPOSE_HIDDEN_PARTITION and add another define directive specifying a new LBA number: #define NUM_LBAS 0xE6C980UL (this number must be even, so if in the previous step you got, say, 0xE6C981, then you can reduce the number to 0xE6C940, for example).

After editing the sources, you need to place the firmware that you want to patch into the patch folder under the name fw.bin and run build.bat, which will create a modified firmware file fw.bin in patch\bin\. All that remains is to upload it to the flash drive.

Password Path and No Boot Mode Patch are done in the same way, about which you can look in more detail on the project’s Github. My main goal was to teach the flash drive to perform given actions, which is what you and I achieved.

We refine and improve

It turned out to be a pretty good hacker device, but there is no limit to perfection. I will give a few examples of how this brainchild can be improved.

To prevent the device from glowing like a garland in someone else’s computer, you can replace the LEDs with jumpers or paint them with nail polish (in several layers). Two debugging boards with protruding wires will clearly arouse suspicion, so it would be a good idea to select or make a housing for them.

If it is possible not only to get close to the system unit, but to open it, then it would be nice to get a cable that connects directly to the motherboard. This will greatly reduce the chances that the device will be discovered soon.

If the device is inside the system unit, then you can use D1 mini Pro V1.1.0, since it has a connector for an external antenna - it will increase the range.

Bottom line

We achieved our goal. Moreover: I think you now understand that flash drives (and other USB devices) can no longer be considered as just an abstract drive that stores your information. In fact, it is practically a computer that can be taught to perform certain actions. Although at the moment PoC has only been released for one specific controller, rest assured that at the moment of reading the article, someone is probably tinkering with others.

So be careful when connecting USB devices and keep your eyes open.

Conductor colors

There are relatively few flowers. Also in the diagram there may be a group of wires that will be marked with the same color.

Let's start with something simple - there are only four colors in the USB 2.0 pinout:

1. This conductor is red - it is to it that DC voltage is supplied.
2. The second white conductor is needed to transmit information via USB.
3. The green conductor is also needed for data transfer.
4. The black conductor is supplied with zero supply voltage. It is also called the common (or main) wire, and is designated by the “Ʇ” icon.

In other cases, there may be significantly more colors and wires. For example, in circuit 3.0 there will already be 9 conductors.

Also, do not forget that some developers like to make their own changes to standard schemes.