Hacking Computers Over USB

I’ve previously written about the risks of small portable computing devices; how more and more data can be stored on them, and then lost or stolen. But there’s another risk: if an attacker can convince you to plug his USB device into your computer, he can take it over.

Plug an iPod or USB stick into a PC running Windows and the device can literally take over the machine and search for confidential documents, copy them back to the iPod or USB’s internal storage, and hide them as “deleted” files. Alternatively, the device can simply plant spyware, or even compromise the operating system. Two features that make this possible are the Windows AutoRun facility and the ability of peripherals to use something called direct memory access (DMA). The first attack vector you can and should plug; the second vector is the result of a design flaw that’s likely to be with us for many years to come.

The article has the details, but basically you can configure a file on your USB device to automatically run when it’s plugged into a computer. That file can, of course, do anything you want it to.

Recently I’ve been seeing more and more written about this attack. The Spring 2006 issue of 2600 Magazine, for example, contains a short article called “iPod Sneakiness” (unfortunately, not on line). The author suggests that you can innocently ask someone at an Internet cafe if you can plug your iPod into his computer to power it up—and then steal his passwords and critical files.

And here’s an article about someone who used this trick in a penetration test:

We figured we would try something different by baiting the same employees that were on high alert. We gathered all the worthless vendor giveaway thumb drives collected over the years and imprinted them with our own special piece of software. I had one of my guys write a Trojan that, when run, would collect passwords, logins and machine-specific information from the user’s computer, and then email the findings back to us.

The next hurdle we had was getting the USB drives in the hands of the credit union’s internal users. I made my way to the credit union at about 6 a.m. to make sure no employees saw us. I then proceeded to scatter the drives in the parking lot, smoking areas, and other areas employees frequented.

Once I seeded the USB drives, I decided to grab some coffee and watch the employees show up for work. Surveillance of the facility was worth the time involved. It was really amusing to watch the reaction of the employees who found a USB drive. You know they plugged them into their computers the minute they got to their desks.

I immediately called my guy that wrote the Trojan and asked if anything was received at his end. Slowly but surely info was being mailed back to him. I would have loved to be on the inside of the building watching as people started plugging the USB drives in, scouring through the planted image files, then unknowingly running our piece of software.

There is a defense. From the first article:

AutoRun is just a bad idea. People putting CD-ROMs or USB drives into their computers usually want to see what’s on the media, not have programs automatically run. Fortunately you can turn AutoRun off. A simple manual approach is to hold down the “Shift” key when a disk or USB storage device is inserted into the computer. A better way is to disable the feature entirely by editing the Windows Registry. There are many instructions for doing this online (just search for “disable autorun”) or you can download and use Microsoft’s TweakUI program, which is part of the Windows XP PowerToys download. With Windows XP you can also disable AutoRun for CDs by right-clicking on the CD drive icon in the Windows explorer, choosing the AutoPlay tab, and then selecting “Take no action” for each kind of disk that’s listed. Unfortunately, disabling AutoPlay for CDs won’t always disable AutoPlay for USB devices, so the registry hack is the safest course of action.

In the 1990s, the Macintosh operating system had this feature, which was removed after a virus made use of it in 1998. Microsoft needs to remove this feature as well.

EDITED TO ADD (6/12): In the penetration test, they didn’t use AutoRun.

Posted on June 8, 2006 at 1:34 PM55 Comments

Comments

jayh June 8, 2006 1:56 PM

Auto play is one of the worst things MS has come up with, and they make it more and more difficult for the average user to figure out how to turn it off.

David Maynor June 8, 2006 2:21 PM

Autorun by default does not run on USB devices or most removable storage devices. It does however always seem to work for CDs or other such devices. Since USB offers no authentication that a device is actually what it presents its self to be it is easy to build a USB removable storage device that will represent itself as a CD-ROM, thus enabling autoplay. You can buy devices that do this now.

William Warren June 8, 2006 2:49 PM

oh yes it does. Both on 2k and xp. plug in a usb hard disk or usb thumbdrive that is data formatted and it wil auto-open the drive everytime. If you have autorun.inf on there it will autorun whatever executable you have on there.

David Maynor June 8, 2006 3:00 PM

On both I get asked what type of application I want to open the drive with, although it never executes anything.

Then there is the actual MS Faq:
http://www.microsoft.com/whdc/device/storage/usbfaq.mspx

Q: What must I do to trigger Autorun on my USB storage device?
The Autorun capabilities are restricted to CD-ROM drives and fixed disk drives. If you need to make a USB storage device perform Autorun, the device must not be marked as a removable media device and the device must contain an Autorun.inf file and a startup application.

The removable media device setting is a flag contained within the SCSI Inquiry Data response to the SCSI Inquiry command. Bit 7 of byte 1 (indexed from 0) is the Removable Media Bit (RMB). A RMB set to zero indicates that the device is not a removable media device. A RMB of one indicates that the device is a removable media device. Drivers obtain this information by using the StorageDeviceProperty request.

-ac- June 8, 2006 3:08 PM

Let’s not miss the point that what you put on the device (in this case pictures) can increase the user’s curiosity and get them to poke aound further. The subject, social engineering that works even on users with heightened security awareness, demonstrates that auto-run is not required for this to work.

Daedala June 8, 2006 3:17 PM

Before anyone says that Macs have autorun again — they don’t. What they have is a facility that sees what just got put into the drive, and then opens a [presumably] trusted application on your own computer. That’s a big difference from executing whatever someone [Sony] decided to put on the CD or other device.

Matthew Skala June 8, 2006 3:41 PM

Daedala: if the trusted application shouldn’t be – basically if it’s an interpreter that runs input files without further authentication – then that amounts to autorun. An example of an application that can behave like an interpreter even though that’s not its main function, would be a word processor that runs macros in documents.

Davi Ottenheimer June 8, 2006 4:02 PM

In an enterprise environment you can also disable USB ports by group and/or monitor them, although this gets tricky if you also deploy USB devices.

Gopi Flaherty June 8, 2006 4:07 PM

I remember a few years ago when a friend on the FreeBSD dev team explained to me how you could do kernel debugging over Firewire.

He explained that you could poke around the system’s memory even if the kernel had completely fallen over.

I asked him, who decides whether to allow this access or not, since the kernel’s dead? It turns out that a significant number of OSs leave all the Firewire features turned on.

Remote devices on the FW bus can do arbitrary DMA to the host system. Somebody wrote a paper, “owned by an ipod” which featured an automated exploit running on an iPod with Linux.

Chris S June 8, 2006 4:16 PM

Given that USB devices can also be hubs and keyboards … couldn’t ANY usb device “take over” by being all of a hub, a drive, and a “keyboard” that plays back keystrokes to copy stuff to the drive?

I’m sure that some careful design of key sequences could get let you even create and run a batch file, and cause no end of havoc. For example

[ctrl-esc]Rc:\x[ret][esc][esc] will get you a Run prompt and try to run c:\x.exe. Simply repeat for different drive letters.

[ctrl-esc]Rd:\x[ret][esc][esc]
[ctrl-esc]Re:\x[ret][esc][esc]
[ctrl-esc]Rf:\x[ret][esc][esc]
[ctrl-esc]Rg:\x[ret][esc][esc]
[ctrl-esc]Rh:\x[ret][esc][esc]
[ctrl-esc]Ri:\x[ret][esc][esc]
[ctrl-esc]Rj:\x[ret][esc][esc]
[ctrl-esc]Rk:\x[ret][esc][esc]
[ctrl-esc]Rl:\x[ret][esc][esc]

… will investigate most of the likely drives. Once the app is running, away it can go.

And … turning Autorun off would not prevent this, right? The ‘fake keyboard’ seems the most difficult to build, but everything else is exceptionally easy.

Hardwarily June 8, 2006 6:51 PM

@Chris S

You’re right, a USB ‘fake keyboard’ could not be disabled by disabling autorun. If the USB device declares itself as a HHID (Human Interface Device), that’s what Windows (or Mac OS X) will treat it as.

Sometimes the OS will offer even MORE assistance. I once copied an entire CF card from a camera to a USB thumb-drive. This mirrored the idiosyncratic dir/file structure. When I later plugged in that USB drive, the OS helpfully launched the camera-picture software. I didn’t want that, nor did I expect it, but it was an interesting result that made me wonder about other exploits using USB “impostor devices”.

Some USB thumb drives incorporate an embedded hub (a Corsair Flash Voyager drive I have does this), so clearly, the electronics in a device with a thumb-drive form-factor can declare itself to be anything. All it has to do is talk the right protocol, which is pretty easy.

Remember, the mfgrs that make these USB-conversant chips WANT engineers to use them, so they come with many libraries and other things ready to use, and the technnical barriers are getting lower all the time, even WITHOUT exploiting autorun.inf.

Longwalker June 9, 2006 12:43 AM

There are plenty of ways to use a keypusher to plant a batch file, or even a binary, on a system. Several ancient DOS utilities that are still shipped with XP can be co-opted for this purpose. Edlin will do batch files and both debug.exe and qbasic.exe can plant either binaries or batch files. Enough intelligence could be put into a qbasic or debug script to find somewhere to plant an executable in a security hole where it’s not going to run into permissions or execute-deny problems.

In terms of more modern tools, notepad can be used to place batch files. For target systems with Internet access, it would be easy to use IE to download custom malware.

Simple key pushers that try to launch an existing executable from every likely drive letter can be defeated by mounting USB devices as NTFS folders.

drm June 9, 2006 2:52 AM

Unfortunately I suspect that software/content companies’ desire for strong DRM/anti-piracy measures will keep this an issue for years to come. Auto-run features make it very easy for companies to try and control how people use media, like DVDs etc transparently to the average user. The Sony root-kit was a particularly disastrous example of an attempt to do this. What’s really bad is that Sony (or whoever’s distributing content w/ a DRM scheme that needs an auto-run) isn’t directly responsible when other people use the auto-run capability of the computer to nefarious ends. Sony’s software isn’t at fault. But they will surly pressure Microsoft to keep the auto-run feature.

Chris Lightfoot June 9, 2006 4:24 AM

Do you even need autorun? Surely you can stick the trojan .exe on the USB drive, giving it the icon of a Microsoft Word file and a suitable name (“New compensation package (CONFIDENTIAL).exe”). To the typical user (whose Explorer won’t show file extensions) it’ll appear to be a Word document, or if not, similar enough that most won’t spot it.

Andy June 9, 2006 5:03 AM

FWIW, Vista fixes the autorun problem. It always prompts you to ask you if you want to run the contents of the autorun.inf file before it actually does it. It would be nice to see this added on to xp as a patch.

John C. Kirk June 9, 2006 5:07 AM

I think that the concept of USB drives as an attack vector is interesting, but we shouldn’t blow this out of proportion. Presumably if the user is logged into Windows without admin privileges then that will limit the amount of damage that the application on the USB drive can do, e.g. no rootkits? In a corporate environment, I would hope that this is fairly standard practice nowadays.

Jungsonn June 9, 2006 5:32 AM

Autorun with .inf files on CD-ROMS are really different things then “auto start” or recognizing a USB stick. In both cases windows checks the existence of new found media, but only executes the .inf autorun file if it is present. I do not know if you can do this on a USB stick. But this lies really in the architecture of windows, which is flawed in any case due to it’s win32shell. I can imagine a hack where one emulates a CD-Rom, and let windows initialize the present .inf file to execute shell commands. But this would not be different on a linux based O.S., it’s the same thing, if priviledged access is granted, and probably by the user itself.

Lotharster June 9, 2006 5:34 AM

I’m not sure if USB can actually use DMA. AFAIK, Firewire can use DMA, but USB cannot. Can anybody confirm this?

ndg June 9, 2006 2:27 PM

Bruce

I trust you realize that by publishing:
“Fortunately you can turn AutoRun off. A simple manual approach is to hold down the “Shift” key when a disk or USB storage device is inserted into the computer.”
you can be considered to have contravened the DMCA, because that would bypass any content protection software that is supposed to autorun 🙂
Can anyone remember the company that came up with this ridiculous threat a few years ago? I always wondered whether they were also going to demand that Microsoft destroy all the Windows help files and manuals published since 1995 or whenever it was that they implemented autorun!

Longwalker June 9, 2006 3:08 PM

The risks of using Firewire DMA to own a computer appear to be overstated. The people who developed this exploit using a modified Linux install on an Ipod were only able to access system memory on OSX hosts. Attempts to read system RAM on Win2K resulted in a crash (possibly exploitable?) while attempts on Linux and WinXP failed outright.

See http://md.hudora.de/presentations/#firewire-cansecwest

Rich June 9, 2006 3:24 PM

Some files (ParisHiltonXXX.exe VirusInstaller.exe e.g.) have the autorun feature hard-coded to ‘on’. The feature can be turned off in specific cases, but is gauranteed to be enabled in a sufficiently large population.

In fact, it can be proven that one is born every minute.

Jungsonn June 9, 2006 5:21 PM

@Beryllium Sphere LLC

Interesting link.

About the USB stick plot, i did see it once in a very, very, B type bad movie.
I’m still not convinced it will auto execute programs/code, if one just “stick” it in. The CD plot i totally agree.

Dragonhunter June 9, 2006 7:53 PM

Great. One more reason for my employer to try to cut my producitivity by banning handhelds and USB sticks. I understand the security risk, what I am afraid of is my IT department will take the usual “I don’t really get it, so we’ll just ban it” approach…alas.

toppk June 9, 2006 9:03 PM

Just as corporate perimeter security is moving towards securing the interiors, the security in uwb (wireless usb) will eventually come in for wired devices too. Besides, with DRM you won’t be able to read/write to storage devices since that’s only for holywood owned content anyway 🙂

but don’t worry, you’ll still be able to use a bic pen cap to open any laptop/bike lock and hack any automatic garage door opener since those markets are dominated by uninformed consumers, and not corporate security techies.

elegie June 10, 2006 8:43 PM

On the Mac OSX platform, there may be security concerns with DMA on Firewire interfaces. It has been said that setting an Open Firmware password and security mode will disable DMA for Firewire connections.

See http://matt.ucc.asn.au/apple/

Brain June 12, 2006 6:15 AM

Certainly a Firewire RAM-raper is a serious concern since that can lead to access of private keys, but so long as DMA access is allowed, there will always be a risk.

USB autorun under windows will not go away. Most of the big flash memory USB drive manufacturers are now behind the U3 standard, which heavily relies on this through presentation of a virtual CD-ROM device, ostensibly to provide maximum compatibility. Assuming Microsoft doesn’t succeed in their end run around U3 through their current wining and dining of the USB-IF for an application drive standard, there are other companies whose existence is based around autorun.

What would be nice is the USB-IF getting their act together on dealing with the self identification weaknesses inherent in USB, but that treads very close to PKI managed by the USB-IF, and linking that with enterprise CA structures to tag and certify allowed devices as they enter company inventory, and rejecting unsigned devices outright on the desktop. Though that probably will not stop device driver exploits.

This may fundamentally be too much to ask, but then again, this represents a market opportunity for any USB microcontroller manufacturer to provide “device signing” capabilities as a new feature, to add another security check mark in product comparisons. Cypress would do well to tie up with some of the larger PKI platform providers.

Sahail June 15, 2006 10:16 AM

We struggled with this issue for quite a while – realising that the port control approach had some merit but realising that it simply wont cut it for many organistaions – it’s too clumsy and too labour intensive.

We began to think that monitoring or even controlling the ports is the wrong approach but that what we needed was control at device level and of content – particularly executables and MP3 etc.

We’ve got it now too. We’ve adopted Gatekeeper
(www.takewaregatekeeper.co.uk) because it gives us far better control of both devices and content and doesn’t get in the way. We decide which devices can be used – the rest are just blocked. When a device is used we know which one and by whom, and we can control as well as audit which content can be brought in and taken away.

It’s much better than the ‘port blocking’ stuff.

Ken Westin June 16, 2006 1:20 PM

With U3 drives, there is a way to hack them so that they autorun:

http://cse.msstate.edu/~rwm8/hackingU3/

Kind of scary really.

There are software solutions available that will allow administrators more control over devices. I work for Centennial Software and we have a product called DeviceWall ( http://www.devicewall.com )which provides granular access controls to USB as well as other ports. Instead of just blocking all devices, it allows the administrator to decided what users can connect what devices to a system and if they have read/write access to that device.

Paul September 13, 2006 7:00 PM

This is a huge security risk for businesses and thankfully is starting to be recognized by Microsoft and others.

Microsoft Vista is able to lock out all USB drives and/or allow the computer to only use a drive if its serial number has been authenticated into the system.

Kamal November 15, 2006 4:53 AM

I need to have a solution for following problem:

As soon as a USB drive is interested into a USB slot, would like to either run autorun.inf or and a bat/exe file, stored on the USB, which copy a txt file stored on USB to a pre specified location on a machine running windows xp/2000, where the USB is inserted.

This works fine with CD’s but is not trivial for USB.

I really need a detailed solution because I’ am not aware of USB device programming.

SecurityDude November 16, 2006 1:59 PM

Has anyone seen a CD with an autorun executable that will unlock a desktop? I remember seeing one a couple of years back but can’t seem to find it now.

SecurityDude

Nils January 12, 2007 12:13 PM

ok, I realize that this a security problem etc. but I want to auto-run a program from my usb! me and my friend will use this between us two. does anyone know how to do this? I use a twinmos usb stick (128mb) if that is for any help…

thank you for all help!

(and yes, I know this tread is out dated, but I found this searching on Google and rely need advises)

Nils January 12, 2007 1:14 PM

ok, I realize that this a security problem etc. but I want to auto-run a program from my usb! me and my friend will use this between us two. does anyone know how to do this? I use a twinmos usb stick (128mb) if that is for any help…

thank you for all help!

(and yes, I know this tread is out dated, but I found this searching on Google and rely need advises)

Joe January 17, 2007 7:27 AM

I have a USB Harddrive that “auto-runs” everytime I plug it in. How would I disable that in the Registry? Thanks.

Joe January 17, 2007 7:29 AM

I have a USB Harddrive that “auto-runs” everytime I plug it in. How would I disable that in the Registry? Thanks.

Note: RMB/Properties/AutoPlay option does NOT work on USB hard drives for some reason – am running XP pro.

erik February 1, 2007 9:14 PM

how can i get all these passwords you speak of because i hav an ipod shuffel which s like a memory stick as well. how can i upload passwords to it?

AKC February 19, 2007 2:02 AM

I have seen many products/tools that allow administrators to selectively set read or write access on a workstation for devices like USB, Firewire Ports, Internal/external CD/DVD drives etc..

Is anyone is aware of the technology used in providing such access rights?

Suggestions are highly appreciated.

shifty eyes March 15, 2007 10:52 PM

heheh, this thread has really devolved. starts as a serious discussion of a security issue and ends as a bunch of poorly translated (from what language, who knows “easy”=”trivial”? thanks, bablefish) pleas for these nifty virus thingies and instructions for how to use them.
To the serious thinkers on here, I was always curious about the HID keypusher idea (after all, the HID is supposed to represent direct user instructions and get top priority with low security). It was interesting to hear a couple of ways that this can actually be accomplished.
regarding device permissions: Since a static device ID could always be replicated, maybe secure USB devices should go the dynamic time-key route and release a new, harware-coded time-influenced passkey to the host computer upon insertion (host would have to run a driver running an algorithm to match the key and setup would still expose computer to some risk). A good stop-gap measure might be to have the host watch for extremely fast typing and rapid key combos. DMA access and autorun problems should probably be fixed on the OS side. but everyone knows that, right.

some 14 year old kid :O April 3, 2007 11:35 PM

personally, i love autorun. i hacked my u3 flash drive and loaded my own iso on it so that i could autorun things from it, made a program that automatically installs several antivirus/antispyware programs, put it on the u3s virtual drive along with an autorun file, and installed it on 10 of my schools computers in less then a minute (alot easier then opening my computer, clicking on drive H or whatever it may be, and running the program yourself :P) i dont think it should be removed from windows, i do however think that there should be an EASY way to disable it

confused.brit May 27, 2007 1:09 PM

It is possible to get a ‘vanilla’ USB stick to add an entry into the autoplay menu via an Autorun script.

I use this to open a batch menu of all the portable apps i have on my cheap and cheerful 512 stick (branded by the company supplied it, so no idea who, definately not a U3)

http://www.dailycupoftech.com/?page_id=149 Details on how it was done here (and they linked to you recently which is how I found this discussion)

Farads May 30, 2007 2:24 PM

Please help me: Whenever double-click on my removable drive (on usb), it asks me to choose the program with which i want to open the drive. When I right-click on the drive, I see among the options “Auto” (in bold), “Autoplay”, “Open” e.t.c. It opens quite alright when I select “Open” but I’m not satisfied.
I expect that its normal for a drive to open on double-click, but now, it’s otherwise and this situation really scares me. I use Windows XP SP2. (However, the Local Harddrive, C:\ responds normally). Thanks. Farads.

Neo Anderson November 20, 2007 7:24 AM

Is there any way to run a program as soon as the usb drive is plugged into socket?

How can DMA be used for this purpose?

Kid December 7, 2007 10:20 PM

I used my C:drives autorun with my ipod software and it gave me encryption codes that even amaised my computer wis sister. It how ever took a lot of encryption codes and deleted them. It is stupid to do because a lot of ipods will take filesand erase valuble info

Tom June 24, 2008 9:05 AM

I recently read that 77% use personal USB Drives to remove information and that IT Managers felt that 35% did this. USB Lock ST & RP provides a simple cost effective method to provide individual or network control of what USB device can be used. So simply controlling the port allows you to work as you want and keep others from causing troubles. http://www.laptopsecuritysolutions.com/advanced_systems.htm

Jack July 4, 2008 9:00 PM

U2 technology removable drives can’t autorun content on a Windows OS just by being plugged. But auntorun.inf files can be used to trick the user into executing malicious code.
Looked for a solution to block or allow with ease both U3 and U2 storage technology devices. that would work from 2K to the newest Vista 64 bit. And that would allow my usb storage device usage but will block all others
Have to agree with Tom, USB Lock Standard demonstrated efficient protecting from both types U2 and U3. really liked the software a lot. We were ammazed of how straightforward the application was, and the way it could be tested no questions asked or long literature to read.
That was quite different from other options. Best part it did not interfere at all with my usb mouse or printer.
Cheers.

Tharadas July 19, 2008 6:13 AM

I used to get free internet cafe time like this . A memory stick had a file that auto-ran a manager that i could kill the proccess which prompts for a timecode. Free for all.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.