Plug Into USB, Get A Reverse Shell

Computers blindly trust USB devices connected to them. There’s no pop-up to confirm a device was plugged in, and no validation of whether the device should be trusted. This lets you do some nefarious things with a simple USB microcontroller.

We’ve recently seen two examples of this: the USBdriveby and the Teensyterpreter. Both devices are based on the Teensy development board. When connected to a computer, they act as a Human Interface Device to emulate a keyboard and mouse.

The USBdriveby targets OS X. When connected, it changes the DNS server settings to a custom IP, to allow for DNS spoofing of the victim’s machine. This is possible without a password through the OS X System Preferences, but it requires emulating both keystrokes and clicks. AppleScript is used to position the window in a known location, then the buttons can be reliably clicked by code running on the Teensy. After modifying DNS, a reverse shell is opened using netcat. This allows for remote code execution on the machine.

The Teensyterpreter gives a reverse shell on Windows machines. It runs command prompt as administrator, then enters a one-liner to fire up the reverse shell using Powershell. The process happens in under a minute, and works on all Windows versions newer than XP.

With a $20 microcontroller board you can quickly fire up remote shells for… “support purposes”. We’d like to see the two projects merge into a single codebase that supports both operating systems. Bonus points if you can do it on our Trinket Pro. Video demos of both projects after the break.

46 thoughts on “Plug Into USB, Get A Reverse Shell

  1. So it’s still just input simulation right? So it only works on unlocked, un-password protected machines you have physical acess to right? I get it allows you to do it quick, but it’s hardly a security flaw of USB. You could also type the commands manually through the already connected keyboard.

    1. you don’t need physical access… just hide this with a hub inside a few USB mouses/other gadgets (USB cup warmer anyone?) and drop them near a big company you target and someone is bound to plug it on his work computer…

      1. Maybe if they have bad security(always possible), as a programmer I don’t even have the ability to open a command prompt in admin on my work machine. Although if it’s a targeted attack you could come up with something else. I do like the idea of the dropped malicious device, though we do warn about using unknown devices in our security training.
        My idea would be to shove on of those ESP wifi modules in a USB stick, and have it serve any files that get put on it.

        However, I still don’t think it’s a security flaw. No mater what pops or confirmation you get, if the USER ultimately trusts the device, the computer must trust it (I own you, do what I say!). Alternatively, imagine the hell of helping your grandmother figure out why the security cert for her keyboard expired or some crap like that. Is that what we want instead?

        1. At the risk of sounding like a jerk, if you read the overview, it does explain that it’s basically bad security by Apple. It trusts that ‘someone’ using the mouse to go through the dialogs makes the system not ask for a password to change system settings.

          Quote:
          We even evade OS X’s security – while they attempt to prevent network changes being done by just a “keyboard”, and even prevent most applications from changing position (special authorized accessibility features must be enabled which we don’t have permission to), we evade both of these with some unprotected applescript and carefully planned mouse movements.

          1. It’s not “bad security by apple” it’s bad security by any OS that trusts a USB device. This same thing will work on BSD, Windows (like they mention) OSX, Linux, etc…. This same device set up right would be more effective to take over Samsung or HP thin clients to redirect the login server to a fake one that the users would input their Username and password into.

            And honestly you HAVE to trust a usb device, just like how all windows devices trusted all PS2 keyboard and mouse devices and we already had these kinds of things that existed back with PIC’s 10 years ago. It just underlines the fact that if you have physical access to the device even with a planted USB device, then you own it.

            The solution for security is that the PC is inside a locked box.

          2. Im pretty sure that on most Linux distros you can’t change system settings without entering the root password. Sure if you have physical access to the machine you probably could manage to get the password or circumvent its need…. But still it’s “better security by linux ppl”.

          1. Depends. If you are just doing desktop development you don’t really need admin rights ever. I’m now working on embedded and I have a rootshell, but the system is in a different VLAN.

        2. CodeRed said it exactly right.
          I don’t have the ability to open an elevated command prompt on my [Windows] machine. I follow this rule and must enter a separate password to get elevated privileges on my machine. Additionally, I have no access to remote shares from my user account. It is strictly that, a ‘user’ level account.

          This exploits your IT’s failure to separate users from administrators. This is possible across all platforms:OS X, Windows, and Linux.

  2. “Fucking drivers. Windows Update will make us wait a bit longer”. I laughed.
    Cool and creepy stuff, but nothing too spectacular. I think I’ve already seen something like this done with the USB rubber ducky.

  3. Badusb is something that everyone is hoping won’t be a big deal but it is. If you can’t trust any USB device then you may as well throw the towel in.

    So your admin only allows USB devices from a certain vendor or device id. Easy enough to programming a device to rotate around all known devices until it finds one that works whilst also providing access as a USB flash key. A failed device installation isn’t normally logged as a security error AFAIK.

    Get access to a manufacturer and taint them on the way out the door and you have a pandemic level issue.

    Yeah the user has to log on but at some point everyone types their username and password in clear text on a keyboard, it’s the ultimate backdoor. A USB keyboard which harvests passwords and can then email them to a dump email account or maybe you can even build in a wireless access point/bluetooth/NFC.

    I think it’s a pretty horrible scenario with a massive number of attack vectors and it’s not easily defendable as you have to trust anything with physical access to the machine.

    1. How long have you been around?

      All but one of the scenarios you describe has already been around and been exposed. The exception is trusting vendors or device ID’s.

      I worked for a company where the head engineer himself gave us an infected test disc he wrote himself at the assembly plant. Tainted thousands upon thousands of servers headed out the door. Made the news and everything back then. Took the company months to recover from while having to send people into the field to reload the BIOS, swap out the test disk and I have no idea how much $$ settling the lawsuits. That all happened when USB was still in its infancy and being included in server level machines “just because”.

      One of my earliest team projects in college was creating a keyboard logger using PS/2. Given our tools at the time, it was clunky and hard to hide, but it was an excellent proof of concept. It would fill its buffer and someone could snag it later (such as the cleaning crew) at night and dump the buffer to find the passwords. I think we spent more time figuring out the PS/2 timings than we did actually writing the logging and dumping firmware, it was that stupidly easy. Look at the hardware keyboard loggers that are available now, both for USB and PS/2, they already have ones with WiFi or Bluetooth connectivity. Those Chinese made ones are deadly scary when you realize you might not be the only one listening.

      With exception to your first point, none of what you brought up is anything specific or exclusive to USB. The danger was always there.

      1. My main issue is one of perceived legitimacy. If you swap out a keyboard (which you never go back for) at a bank due to ‘sticky keys’ or some such you’re likely to get away with it versus please can I mess around with your desktop and blatently place a dongle between your keyboard and USB port.

        If you can’t trust a USB key (or indeed anything) that you plug in to your machine then your attack vector goes up dramatically.

        No one touches my PC except me but, in the past I’ve plugged dozens of other peoples memory sticks in to it. Now I have the social issue of denying access due to lack of confidence in their USB key whilst having to explain that mine, of course, is completely legit ;-)

  4. Why use the start menu and not WIN+R?

    It also wouldn’t work with UAC if the user is only a standard user I’m guessing, which is how every business should be and how more and more people set their home computers up now. On that note, if it can simulate keystrokes then in theory you could actually have it type up an actual executable right? Wordpad/Notepad can’t do it, but supposedly you can do it with a batch script: http://techref.massmind.org/techref/dos/binbat.htm

    If you could have it type a program up you could in theory create a fake UAC prompt to get them to put in the credentials and then use that to elevate to get what you need. Most IT people don’t pay a whole lot of attention because they enter their credentials many times a day, and home users pay even less attention.

    Of course it would probably be a lot simpler to just upload it online and use a simple VBScript to download the file, capture their admin password (or a IT person’s), and use those to elevate. If it would actually let you open the file after it’s downloaded without saying it’s not trusted.

    Disclaimer: I don’t condone doing this, just trying to think of ways this could actually be a security risk for Windows as well.

    1. Look at it this way. If you can do it with a keyboard and mouse then this can do it. Type up a vbs or powershrll script, no problem. Sit in the background harvesting key strokes, no problem. Identify yourself as a network adapter which is the same as one already installed in the machine and then add a startup item which prompts for UAC . Most people would click okay just to get rid of it so they could do their work, check their email or get their fap off.

      That is one of the worst things about the default UAC level. If the whole screen greys out then your investigations are hobbled as you can’t easily track it down without responding and effectively ending (possibly destroying) the attack vector.

      1. Not to mention it’s incredibly annoying when you have a movie playing on your other monitor and it grey’s them all out lol. Then again, it’s technically impossible to secure a computer if someone has physical access to it. Physical security has always been a part of keeping everything secure.

    2. After testing a while with the Run dialog, it turns out that not only can Windows XP totally support this, but that UAC isn’t required at all for this script’s Powershell use. This means that it can be used in the context of a Standard user account or an Administrator user account. I haven’t tried the Guest account yet, but after testing with the Standard user account, I have verified that the computer indeed sent a SYN packet over to the specified IP and port without invoking the UAC prompt.

      Also, keep in mind that this is just through my own personal testing and experiences. I’ve only tested this script on Windows 7 and Windows 8, but not Vista or XP.

        1. I understand that, but the script doesn’t change any IP settings on the victim computer. You must change the necessary IP and port parameters in the Teensyterpreter script, but those are just for the victim to know which IP and port to connect to.

  5. “A new USB device has been detected” (mouse/keyboard) “Connect the USB device to:” “Mac OS or Virtual Machine”
    This is happening on my computer with Parallels on OSX, so why didn’t anyone write a small app just asking the same?

    1. It wouldn’t take a lot of work to prevent USB devices from being automatically installed. If you want to see UAC all the time then great….. As an aside if you don’t trust the keyboard or mouse then how can you click or press the accept butting ?

      Of course even if you trusted the device there is no way to know if it has been compromised as it may not require visible modification.

      1. The keyboard and trackpad are built inside my laptop, so sure, if you get access to these, you can do anything.

        By the way, I tested some of the code from USBdriveBy, it fails because I’m running MtLion, even mouse positions have to be adapted.
        But no worry dear Intruder, the teensy loader and IDE is installed so you can modify it while on my machine. (btw, don’t use the wrong usb port also … and don’t worry about all these llvm compilers, disassemblers, neural networks and other strange tools… just don’t worry.) ;-))

  6. >no validation of whether the device should be trusted.

    Linux has the ability to stop devices enumerating. A trick for soft-resetting some devices is to boot it off of the system via sysfs and then let it enumerate again..

  7. While it’s not a new concept it’s certainly a step forward in the field of fire-and-forget physical attacks. “Hypothetically”, “this guy I know” used to take USB drives with a simple autorun/.bat file pair and have fun at the expense of kiosk shops in the mall running old unpatched and unprotected copies of windows.

    Their mistakes were:
    1) leaving the USB ports live.
    2) leaving the computer physically accessible.
    3) leaving the place under the watchful eye of some slacker 18 year old.

    None of these are the fault of the USB protocol or the operating system. It all comes down to educating your employees and sufficiently protecting your equipment.

    1. You can take all the security precauntions you like but when the device and protocol is compromised it’ll make no difference. An attack vector is just that regardless of your security. Disabling USB will work but at the cost of 90% of the devices on the market today. Good luck even finding a motherboard which has PS/2 ports nowadays.

  8. Would you live in a house where all kitchen knives, screwdrivers, scissors, hammers & nails are kept in locked drawers, the stairs are protected by a lock that opens only if you wear a stunt suit, and windows would let you lean out only when pillows are detected on the floor outside and you wear a parachute? …. Me neither!
    It’s called usability, baby, which is something you kiss goodbye when looking for too much safety/security. Simply put, you can’t have them both, period. That one is not a vulnerability, it’s a trade off to make a computer useable.

  9. The easiest first step to detection and protection is for the host OS to monitor and limit keystroke speed. I know I can’t type at over 200 words per minute, yet most of these attacks happen quicker than that. If the OS simply puts a speed governer on the recieved speed of keystrokes from a keyboard or mouse, keystrokes will get dropped and the attack will fail. On the other side of the fence, detection would be to monitor the speed of keystrokes. If there appears to be equal timing between keystrokes, even if the attacker slows the attack down, the OS should be popping up a UAC warning window letting the user know something suspicious is going on, and asking the user to check plugged in devices for foul play. At this point, the computer halts everything, giving the user time to unplug devices and plug them back in. Pressing continue would restart the process over, and the attack would trigger detection again.

    1. I’m sure someone also would retort, that the device simply only needs the attack keystrokes slowed down, and a random pause inserted between keystrokes. This would be correct, and it would also be correct that if someone is physically monitoring the computer, they would visibly detect the attack happening. A command shell popping up with ghost characters appearing would definitely tip off even the 18 year old kid.

      That means this attack would only be successful against a computer which is unmonitored, and in this case the person attacking knows what is happening as it is intentional. Given this, the computer would be of low value (it wouldn’t be holding anything of importance), or it is known of who accesses the computer and so an attack would be connected to this person (after all they watched it happen and didn’t mention it to anyone.)

  10. People keep talking about USB protocol security, but nobody has mentioned PCI Express. Xilinx makes Spartan6 FPGAs with PCI Ezpress capability forr pretty cheap. Sure there is a bit of design work, but PCIe devices get direct memory and cpu access, eegardlesa of operating system. Not aure how it would work with a TPM installed.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.