Bad USB, Very Bad USB

I am responsible for the onsite social engineering engagements at LMG Security, and today I am going to make my job a little bit harder by introducing you to one of my favorite gadgets in my arsenal: the simple USB thumb drive. The remainder of this post will show how a USB can become deadly to even the most secure networks by using highly publicized and easily obtainable exploits like Rubber Ducky and BadUSB.

Introduction to USB

One of the things that makes USB so dangerous is the universality of the device. Keyboards, printers, scanners, mice, modems, web cameras, etc. seem to just work when they are connected via USB. Users are able to plug whatever device they wish to use into the USB socket on their local machine and the OS automatically loads the required drivers and determines the type of device that has been plugged in.

This process occurs in the blink of the eye, and operates so smoothly that the typical person neither has time nor reason to think about the process, but it is important to understand what is happening behind the scenes in order to understand how the process is exploited. When a USB device is first plugged into the computer, the OS knows nothing about the connected device. It simply waits for the device to tell it what it is. For example, when a USB mass storage device is first plugged in, the device will inform the operating system of its file system type and volume.

The communication between the OS and USB is facilitated through the use of class codes. These codes tell the OS what type of device they are dealing with and allow the OS to grab a universal driver that works for that class of device. Each device can provide one or several class codes to the operating system. For example, a typical USB mass storage device would have a class code of 08h whereas a video camera equipped with a microphone will likely have two codes: 01 (audio) and 0Eh (video). Furthermore, these devices can change their classes on the fly. This is what allows certain devices to mount as a CD-ROM until you download the necessary drivers and then mount as a USB drive after authentication as seen in the example below.

Figure 1: Ironkey USB Mounted as CD-ROM and USB

Each time the USB is plugged in, the OS registers the device, assigns it an address, and the USB device sends back its class codes. The OS then grabs the necessary drivers and immediately starts working with the device. This whole process is managed by a small controller installed on nearly every USB device.

In a perfect world with well-behaved users, this system would work fine. Keyboards would send the descriptor of 03h (human interface device), flash drives would identify themselves as 08h (mass storage devices), and the biggest threat from USB drives would be preloaded malware; however, we know that not all users are well behaved, and unfortunately, the controllers that facilitate communication between the OS and the USB can be reprogrammed to identify themselves as anything you like. This opens up a whole range of attack vectors, a few of which I have addressed below.

The Rubber Ducky

The Rubber Ducky is a tool created by HAK5 that has become a must have tool in every hackers arsenal. It looks like a simple USB flash drive, but it tells the OS that it is a 03h (human interface) device. This code tells the OS to respond as if it is a simple human interface device (HID). The computer inherently trusts input generated by humans, so almost every OS will trust any HID by default and automatically acquire the drivers necessary to mount the device.

Figure 2: USB Rubber Ducky Device Guarded by Sacred Protector

Once the Rubber Ducky is mounted, it begins executing preprogrammed keystrokes at 1,000 words per minute, and is capable of executing any combination of keystrokes the attacker wants. This makes it a viable cross platform attack vector that is limited only by the attackers imagination. For example, I personally started playing with a Rubber Ducky after looking for a way to quickly change the background picture of personal workstations left unlocked by my coworkers. I picked up a Rubber Ducky we had lying around the office and within the hour I had a device that would change the background image of any MacBook to a picture of David Hasselfhoff before locking the screen, all within 5 seconds of plugging in the device.

Figure 3: Wallpaper Used on Unsuspecting Coworkers

On engagements, the Rubber Ducky has become a critical tool. With 10 seconds of access to an unlocked computer, I can plug it in to an open usb port and walk away while it automatically opens powershell, downloads an exploit from a remote server, and executes it. On the off chance that the workstation is unable to reach the remote server, or the antivirus catches my payload, I can simply have the Rubber Ducky write a reverse shell within powershell and execute it.

Figure 4: Rubber Ducky Writing Shell Code for a TCP Reverse Shell

These types of attacks will likely evade whatever antivirus is in place because the commands were executed by what the machine believes to be a human user via a keyboard, and computers trust humans. Furthermore, most organizations protect against USB devices by simply shutting down access to USB mass storage devices (08h), but they still allow USB keyboards (03h), and thus the Rubber Ducky, to mount automatically.

BadUSB

Now that I have addressed how dangerous an automated USB keyboard can be, I wanted to build upon the distrust by introducing an exploit first demonstrated by Karsten Nohl & Jacob Lell at Blackhat 2014. This hack, dubbed BadUSB, involves reprogramming the firmware of USB devices to perform a number of alarming attacks. In one such attack, Nohl and Lell plugged a USB device, which had been reprogrammed to change itself from a mass storage device to an HID keyboard, into a windows machine. After converting to a keyboard, the device executed a quick command that infected the target machine and instructed the machine to re-flash any USB devices that were later connected to it. In order to continue this proof of concept, the researchers removed the original USB drive from the windows machine, and plugged in a fresh USB drive. They then waited for this new drive to mount to the windows machine (silently reprogramming the firmware on the USB device) before ejecting it.

The researchers then took this newly infected USB drive and plugged it into a Linux machine where it registered as a keyboard device, fingerprinted the OS, and executed a series of keystrokes necessary to spread the infection to the Linux machine, all within a split second.

Once a machine is infected, it is possible that it could spread to any connected USB devices with a programmable controller. This includes the majority of USB flash drives, USB keyboards, USB mice, and even many factory installed devices such as the built in MacBook webcam. This means that once your computer is infected, there is a chance that every single device that was plugged into it is also infected. This is particularly dangerous because if the built in webcam for your MacBook is infected, the malware will persist in the firmware of the camera even after you reimage your hard drive.

Furthermore, this self-replicating virus is almost undetectable by current defenses. By hiding in the firmware of controllers contained in nearly every USB device, it avoids the scanners of most antivirus systems. Even if the antivirus attempted to scan the controller, the malicious firmware could simply play back a benign version of the firmware whenever the antivirus attempts to read it. In fact, this attack vector was deemed so difficult to patch by Nohl and Lell that they chose not to release the code necessary to pull of the attack; however, two separate researchers, Adam Caudill and Brandon Wilson, later reengineered the firmware of a popular controller brand, Phison, and released the code for their attacks on Github.

Over the last year two years, this research has been highly publicized, and this publicity has led to it being built into tools such as Offsec’s Nethunter smartphone operating system. Nethunter uses the ability to reflash descriptors on the fly to allow what looks like a typical Android phone to launch HID style attacks or to mount as a network interface and force all traffic to pass through it before being rerouted to the internet.

Defenses

The best defense for this type of attack is to only use devices that do not have reprogrammable firmware. Outside of this, it is important to only use USB drives that you trust completely, because after plugging in an untrusted device, you will never know if there is an invisible threat running on your computer.

Sources

“Bad USB | Tresys Technology.” Accessed May 2, 2016. http://www.tresys.com/products/badusb.php.

Greenberg, Andy. “Why the Security of USB Is Fundamentally Broken.” WIRED, July 31, 2014. https://www.wired.com/2014/07/usb-security/.

Lex, SR. “Keystroke Injection Tool – Rubber Ducky.” WonderHowTo. Accessed May 2, 2016. http://null-byte.wonderhowto.com/forum/keystroke-injection-tool-rubber-ducky-0159084/.

Nohl, Karsten, and Jakob Lell. “BadUSB – On Accessories That Turn Evil.” presented at the Black Hat 2014, Las Vegas, Nevada, 2014. https://www.youtube.com/watch?v=nuruzFqMgIw.

“Turning USB Peripherals into BadUSB | Security Research Labs.” Accessed May 2, 2016. https://srlabs.de/badusb/.

Zhukov, Anton. “Turning a Regular USB Flash Drive into a USB Rubber Ducky | HackMag.” HackMag. Accessed April 29, 2016. https://hackmag.com/security/rubber-ducky/.