Hacking Computers Over USB

June 08, 2006

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 08, 2006 at 01:34 PM

Trackback Pings
TrackBack URL for this entry:
Listed below are links to weblogs that reference Hacking Computers Over USB:
» Interesting Finds: June 9, 2006 AM edition from Jason Haley
[Read More]
Tracked on June 9, 2006 09:29 AM

» USB 的社交工程 from 國生三年才開始
洞不要亂給人家插喔… XD 今天看到一篇文章,是講最近開始熱門的一種 “USB 社交工程法”。最簡單的,就是 USB 碟會有遺失的風險,在容量越來越大的現在,每次遺失都可能會造成… [Read More]
Tracked on June 9, 2006 11:55 AM

» USB támadás from Techies blog
Egyre többen foglalkoznak a kérdéssel, hogy egy megfelelően preparált USB meghajtóval meg lehet támadni a kiszemelt gépet. A trükk lényege, hogy az autorun (automatikus indítás)&… [Read More]
Tracked on June 11, 2006 09:21 AM

» Link della settimana from Alessandro “jekil” Tanasi blog
The Security of RFID CardsHacking Computers Over USBForesinc analysis of a compromised intranet serverA Comparison of SNMP v1, v2 and v3Forensic RAM dumpingSecurity without firewalls: Sensible or silly?Affect on traffic from the TPB bustPassword Cracking [Read More]
Tracked on June 11, 2006 05:58 PM

» CaffiNation 042: Haunted Edition, cursed or whatever from Tech Podcasts Today
Welcome to the CaffiNation 04 2: Secure the Lines: Happy Solstice The High Octane world of Tunes and Tech, Coffee and all things Caffeine. Tech Tid-Bits :—– Download Is your computer Safe? Utilities to run, things to do. World Around… [Read More]
Tracked on June 22, 2006 12:28 AM

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.
Posted by: jayh at June 8, 2006 01:56 PM

Does autorun actually run on USB sticks?
Posted by: Michael at June 8, 2006 02:11 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.
Posted by: David Maynor at June 8, 2006 02:21 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.
Posted by: William Warren at June 8, 2006 02:49 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:
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.
Posted by: David Maynor at June 8, 2006 03:00 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.
Posted by: -ac- at June 8, 2006 03:08 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.
Posted by: Daedala at June 8, 2006 03:17 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.
Posted by: Matthew Skala at June 8, 2006 03:41 PM

There are several USB memory sticks that pretend to be a CD-ROM drive. These can be used to circumvent the Windows restriction of autorun on USB sticks. For example, the Hagiwara UD-RW supports this feature:
Posted by: Ralf at June 8, 2006 03:44 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.
Posted by: Davi Ottenheimer at June 8, 2006 04:02 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.
Posted by: Gopi Flaherty at June 8, 2006 04:07 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.
… 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.
Posted by: Chris S at June 8, 2006 04:16 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.
Posted by: Hardwarily at June 8, 2006 06:51 PM

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.
Posted by: Longwalker at June 9, 2006 12:43 AM

See too – http://www.darkreading.com/document.asp?doc_id=95556&WT.svl=column1_1
(Social Engineering, the USB Way)
Posted by: Pinkava at June 9, 2006 12:48 AM

This problem has been arround for a while the only way to do it is to diesable hot pluging because regardless of what the user is ( administrator or heavy restricted user ) he will allways be able to do this!
Posted by: watches at June 9, 2006 02:45 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.
Posted by: drm at June 9, 2006 02:52 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.
Posted by: Chris Lightfoot at June 9, 2006 04:24 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.
Posted by: Andy at June 9, 2006 05:03 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.
Posted by: John C. Kirk at June 9, 2006 05:07 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.
Posted by: Jungsonn at June 9, 2006 05:32 AM

I’m not sure if USB can actually use DMA. AFAIK, Firewire can use DMA, but USB cannot. Can anybody confirm this?
Posted by: Lotharster at June 9, 2006 05:34 AM

An attack very much like this made the news a while back. http://software.silicon.com/security/0,39024655,39156503,00.htm decribes how someone gave away “promotional” CD-ROMs which bank and insurance company employees stuck into their work computers.
Posted by: Beryllium Sphere LLC at June 9, 2006 12:55 PM

This seems like a reasonable approach to stopping such attacks:
I’ve not built a production system with it yet (we put laptops in semi-hostile areas) but the initial testing looked like it was enough of a roadblock that it would require a hefty investment of time, and difficult (probably not impossible) to cover all the tracks.
Posted by: TimTheFoolMan at June 9, 2006 01:17 PM

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!
Posted by: ndg at June 9, 2006 02:27 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
Posted by: Longwalker at June 9, 2006 03:08 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.
Posted by: Rich at June 9, 2006 03:24 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.
Posted by: Jungsonn at June 9, 2006 05:21 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.
Posted by: Dragonhunter at June 9, 2006 07:53 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.
Posted by: toppk at June 9, 2006 09:03 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/
Posted by: elegie at June 10, 2006 08:43 PM

As much as it nices to attack a user via AutoRun feature and Social Engineering.
The real risk is attacking the device drivers of the USB within Windows.
Posted by: Itzik at June 11, 2006 04:01 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.
Posted by: Brain at June 12, 2006 06:15 AM

Floppy Disks Can Be Used As Well In Dos Just Drop A batch in C:\windows\administrator\start menu\programs\startup\
make It say
NET LOCALGROUP Administartors SAM /add
as shown at http://m33hack.741.com/
Posted by: m33hack at June 13, 2006 12:56 PM

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.
Posted by: Sahail at June 15, 2006 10:16 AM

With U3 drives, there is a way to hack them so that they autorun:
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.
Posted by: Ken Westin at June 16, 2006 01:20 PM


About this entry