X
Business

Is there no end to the AutoRun madness?

* Ryan Naraine is traveling. Guest editorial by Roel SchouwenbergLet's skip any introduction and get straight to the point: We're currently facing a problem of epidemic proportions in malware that is spreading via removable devices.
Written by Ryan Naraine, Contributor

* Ryan Naraine is traveling.

Guest editorial by Roel Schouwenberg

Is there no end to the AutoRun madness?
Let's skip any introduction and get straight to the point: We're currently facing a problem of epidemic proportions in malware that is spreading via removable devices.

The U.S. army's recent ban on removable storage probably says it all, though one may wonder what took them this long. The vast majority of these malware samples is originating from China. Their functionality varies. It started out with online games password-stealers targeting World of Warcraft, LineAge and others. But over the last months, we're seeing malware being upgraded to also spread via removable devices. They all make use of Windows' AutoRun functionality.

It's boot viruses all over again. Some ten, fifteen years ago we faced a huge problem with viruses spreading via floppies. Already infected machines would infect floppies upon insertion and infected floppies could infect clean machines by being booted from. Microsoft reacted to this threat and with the introduction of Windows95/NT boot viruses started to die out.

Unfortunately the current situation is worse than the one caused by boot viruses.

The main reason for that is instead of (accidentally) having to boot from an infected floppy, pretty much plugging in the USB stick or other USB device will get you infected.

I performed some tests with a USB stick containing instructions to autorun an executable on XP, Vista and a beta of Windows 7. Note that for instance an external hard drive connected via USB may be treated slightly different by Windows than a regular USB stick.

Is there no end to the AutoRun madness?

By default, Windows XP will pop up a window asking you if you want to browse the stick or want to take no action. That doesn't seem bad, now does it? However, when using Explorer to navigate to the USB stick, things get a lot worse. By right-clicking on the USB stick we get to see the default action that Windows takes -- to automatically run the executable!

Bad, bad idea, but that may be a bit of a cheap shot. Back when XP was introduced we didn't see malware spreading to USB drives and exploiting the AutoRun function. Windows XP's initial behavior with USB devices was pretty much a copy from that with CD-ROMs. AutoRun instructions coming from CD-ROMs are by default automatically executed without any interaction from the user required.

By the release of XP/SP2 Microsoft had realized that this wasn't a good idea for USB devices and took that bit out. Unfortunately they kept the other behavior in XP intact.

Is there no end to the AutoRun madness?

Luckily Microsoft changed the behavior with Vista. Unfortunately the situation hasn't improved entirely.

No more getting infected just by trying to access the drive. However now the user gets the question if he wants to run the application. And s/he's even presented with a nice check box to always take this action. This is what I call one step forward, one step back.

Possibly the change in the actions in the pop up was a useability decison. With the functionality of executing autorun instructions by accessing the stick removed, Microsoft felt they had to present the users with an equally user friendly alternative.

I was hoping that the beta of Windows 7 would change that behavior. But unfortunately the behavior between Vista and Windows 7 seems identical.

While this approach prevents users from getting infected by pure accident this still allows for a social engineering vector. Somehow I don't think the effectiveness of this type of malware is being limited in any significant way by that decision.

Sad to say users are very likely to run the program. And I'm not sure they can be blamed for that. Tons of USB devices are leaving the manufacturing plant infected -- Seagate, TomTom, Apple to name but a few of a very long list. Again, this is very reminiscent of the boot virus era where new pre-formatted floppies had quite a good chance of being infected with something.

So what are the mitigation strategies? Well, using policies you can disable the AutoRun functionality. That will obviously take care of the biggest part of the risk. But the risk remains of users being curious about that one file on the device - either because it's new from the factory or because they can't recall putting it on there and want to check what the file is.

Another strategy is formatting the device before use, but that may not even be possible in most cases. I think the real solution is with Microsoft, just like with the boot viruses.

Having such a huge epidemic shows that this strategy is working for malware authors. Therefore the best course of action is to get rid off AutoRun for writeable media and simply eradicate the problem. I can fully understand that getting rid of AutoRun for non-writeable media such CDs/DVDs is not an option from a usability point of view and it's also not what I'm suggesting.

U3 capable devices have a non-writeable part, so they would also keep using AutoRun. However MP4 players, TomToms, iPods, SD cards, external hard drives and USB sticks don't actually require AutoRun to function.

Only in some cases vendors use AutoRun for usability purposes and those could become unhappy if Microsoft were to disable AutoRun. So getting rid off AutoRun on writable media entirely is probably not a realistic option for Microsoft. The compromise is simple - only allow for (partial) AutoRun if the file to be automatically executed is digitally signed.

Please Microsoft, take a stance against this type of malware! Just like you did with boot and macro viruses.

* Roel Schouwenberg is a senior anti-virus researcher for Kaspersky Lab.  He is a member of the company's Incident Response & Research Team and focuses on attacks targeting banks and other financial institutions. 

Editorial standards