Josh Stone, Blog

Josh’s projects and security nerdery

HIDs and USB Blockers

Introduction

Occasionally, I will work with a client who uses a USB blocker to prevent users from uploading unauthorized software or exfiltrating data. This can be interesting from an attacker’s perspective – especially the rogue internal user – because one may wish to install hacking tools on an end-user workstation. There are lots of handy tools that help when you’re exploring a network, and these are rarely installed in a corporate environment.

This post is about the most fun way I have found to circumvent USB blockers and successfully install malicious software on a corporate system. This is not the only way, and it’s not necessarily the most efficient. But it certainly was fun.

Scope of the Problem

I prepared this attack for a place where we assume several key limitations:

  1. USB blocker in place to stop mass storage devices (USB keys)
  2. Public Internet access is blocked or heavily controlled
  3. Network authentication prevents unauthorized devices

One interesting factoid about lots of USB blockers is that they are often configured not to block HIDs, or Human Interface Devices. This is because it’s annoying to have to authorize every keyboard and mouse, and the organization incurs somewhat of a support burden. So usually, they only block certain types of devices – such as mass storage devices, which eliminates USB keys, external hard drives, phones, etc.

Solution

If we type in all of the data we need on a keyboard (a HID), then we can get around the mass storage controls. Obviously, typing in executables is no fun (and not particularly easy with a stock Windows install). This post is about a hardware device I made to do this for me. So here are the essential features:

  1. Attach to the system as a keyboard (HID)
  2. Read files from a storage volume (SD card)
  3. Type file contents out through USB

There are a couple wrinkles, which are pretty easy to work around. For example, Windows doesn’t like it when you type out binary data to the keyboard (you end up with odd scan codes that make the UI do crazy things). I found that this process actually works pretty well:

  1. Encode all binaries as Base64
  2. Upload a Base64-decoding VB-script first
  3. Upload encoded files
  4. Decode files on-system

It also helps to ZIP files, because the throughput with the keyboard, though much better than most of us type (especially in Base64), leaves much to be desired. Nevertheless, this works very well for getting smaller tools uploaded. I have a number of small executables I can use for basic tasks like extracting password hashes, getting a SYSTEM shell, token impersonation, etc. If they’re within the 300kb and below category, this works very well.

The Device

My prototype, which I have now actually used on an assessment, is a pretty straight-forward Arduino stack. I use a couple shields and some assorted hardware to make it barely usable, and it works. If I were to improve on this, I’d add a much better user interface – but I had the numeric display and rotary encoder around anyway, so it was pretty easy to put this together. Bill of materials (not counting little things like hookup wire) is approximately (just a hair over $50):

  • Arduino Leonardo ($20)
  • Seeed Studio SD-card shield ($7 on sale at Radio Shack)
  • Arduino ProtoShield ($10)
  • Adafruit I2C 7-segment display ($10)
  • Adafruit rotary encoder ($5)

File Writing Device

You can also look over my (very prototype) source code here.