Securing Windows Autorun/AutoPlay: Good Method vs. Bad Method

Wednesday Nov 18th 2009 by Michael Horowitz

Many Windows users don't know that there are two different approaches to disabling autorun/autoplay -- a dangerous lack of knowledge.

Way back when, Microsoft opted for convenience over security and Windows users have been sitting ducks ever since. I'm speaking of autorun/autoplay, a feature in Windows that lets programs run automatically when a CD or USB flash drive is inserted into a PC. For years now bad guys have been exploiting this to automatically infect PCs with malicious software.

Everyone knows this. What many Windows users don't know is that there are two different approaches to disabling autorun/autoplay.

There is a simple way and a complex way. There is a consistent way and one that varies depending on the version of Windows. There is an all-encompassing way and one whose design has holes in it. There is a foolproof way and one that has needed multiple patches. There is a consistent way and one whose design has changed over time. There is an easily understood way and one that no one fully grasps. There is a frequently written about way and one that is often overlooked.

There is, in a nutshell, a good way and a bad way.

The bad way is from Microsoft. The good way is from two people no one knows (myself included) - Nick Brown and Emin Atac.

What brings this up? Three things.

A recent article about autorun security problems in the Washington Post is chock full of statistics on how bad the problem remains. In particular, the Taterf worm, which spreads by exploiting autorun, was detected by Microsoft on 4.91 million Windows computers.

And, despite the plethora of articles on how Microsoft is making this all better, my latest PC, a netbook running Windows XP SP3, was vulnerable to autorun hacking even with all the latest patches installed.

Finally, Windows 7 introduces sufficient changes that everything written on the subject prior to October 2009 needs to be revised.

The Many Faces of Autorun and Autoplay

Part of the problem in understanding autorun/autoplay is that there are five aspects to it, yet we have only two words: autorun and autoplay. The language used insures mis-understandings about autorun/autoplay.

There are four ways that malicious software on a USB flash drive (thumb drive, pen drive, memory stick, etc.) can execute and infect a Windows computer:

  1. Run immediately and automatically. This is typically allowed only on CDs and DVDs, however, other external USB devices can appear to Windows as CDs and thus cause software to, literally, run automatically.
  2. Run via the Autoplay pop-up window by adding an entry to the list of options and making this malicious entry appear to be something that it is not.
  3. Run when the user double-clicks on the drive letter in My Computer (or Computer).
  4. Run via a modification to the context menu (the pop-up menu displayed when you right click on a drive letter). Malware can either add a new entry to the context menu or redefine the meaning of one the normal entries.

On top of this, bad guys can also modify the displayed volume label and icon for an external USB device, to try and entice a user into falling for one of the above tricks.

All the maliciousness is centered in a single file called autorun.inf. Nick Brown's registry update simply tells Windows not to process any autorun.inf files. The concept is elegant in its simplicity.

And, this is separate and distinct from the Autoplay feature of Windows. The autorun.inf file is an optional part of Autoplay.

Kicking the Autorun Tires

If a picture is worth a thousand words, then a live demo is worth many pictures. You can see and test the five aspects of autorun/autoplay using an autorun.inf file that I created back in January. For more, see my blog post about testing your defenses against malicious USB flash drives.

My sample autorun.inf file safely attempts to exploit all five aspects of autorun/autoplay. Simply adding it, and a copy of mspaint.exe, to a USB flash drive, turns the device into an autorun tester. With it, you can see which of the five aspects of autorun/autoplay a Windows computer is vulnerable to. It also gives you a baseline to test any attempts at disabling autorun.

If you are concerned about downloading files from strangers (good for you), autorun.inf files are plain text. You can open them in Notepad to see what programs they are attempting to run.

Protecting Your PC

I documented implementing the Brown/Atac approach back in January in The best way to disable Autorun for protection from infected USB flash drives. It requires updating the registry to instruct Windows to ignore all autorun.inf files. Specifically, you need to run the three-line registry update below.

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionIniFileMappingAutorun.inf]

Save these three lines of text in a file. The file name can be anything, but the type needs to be ".reg". Once this is done, simply double-clicking on the file updates the registry. In the unlikely event this causes a problem, it's easily backed out (see below). Still, it is always a good idea to make a Restore Point before updating the registry.

Vista users can read about the behavior differences introduced by the Brown/Atac approach in Disabling Autorun and Autoplay on Windows Vista SP1 with Nick Brown's method.

Others Touting Brown/Atac Approach

I am not a lone wolf in advocating for the Brown/Atac approach to disabling autorun.

Back in November of 2007, Scott Dunn wrote One quick trick prevents AutoRun attacks in the Windows Secrets newsletter shortly after Nick Brown first documented the scheme.

In January 2009, US-CERT issued a Technical Cyber Security Alert called Microsoft Windows Does Not Disable AutoRun Properly that warned "The Autorun and NoDriveTypeAutorun registry values are both ineffective for fully disabling AutoRun capabilities on Microsoft Windows systems" and then suggested using the Brown/Atac registry zap.

This was old news for US-CERT. Back in March 2008 they issued Vulnerability Note VU#889747 Microsoft Windows fails to properly handle the NoDriveTypeAutoRun registry value which also suggested using the Brown/Atac scheme.

Then, ask-leo.comLeo Notenboom broached the subject in February 2009 with Is autorun really that evil, and if so, how do I turn autorun off? He didn't even mention a Microsoft solution to disabling autorun, rather he focused solely on the Brown/Atac approach. Leo also does a good job pointing out the downside to totally disabling autorun. You can have convenience or security. Pick one.

Autorun in Windows 7

My previous blogs, the articles above, and perhaps 99% of what's available online about autorun/autoplay, pre-dates Windows 7.

My testing showed that Windows 7 blocks running software on a USB flash drive. Specifically, it ignores instructions in the autorun.inf file to add an entry to the AutoPlay window (shown below) and the context menu. Double-clicking on the drive letter in Computer lists files on the drive, regardless of instructions in the autorun.inf file.

The new operating system does, however, allow the autorun.inf file on a USB flash drive to modify the displayed volser and icon for the drive. You see this in the example below, where the icon comes from a copy of Paint on the USB flash drive and the displayed volser comes from the autorun.inf file.

Windows 7 AutoPlay

This, however, does not mean that Windows 7 is immune to infection from malware on external media. It's safer, but not safe.

For one thing, Windows 7 still supports autorun/autoplay for CDs and DVDs. And then there are USB devices that pretend to be CDs. Pretend? What pretends to be a CD? U3 flash drives for one. My LG Chocolate 3 cellphone for another.

The Chocolate 3 phone, released in mid 2008, is big on playing music. To make it easy for users to sync music between the phone and a computer, LG makes the phone appear to Windows as a CD drive. Thus, when the phone is plugged into a USB port, the LG software runs automatically, there is no Windows AutoPlay window offering any confusing choices.

To be fully protected, the Brown/Atac registry modification is still needed on Windows 7. It disables autorun everywhere, offering protection from CDs, DVDs and devices that pretend to be CDs. My testing turned up no ill effects.

The Brown/Atac registry zap can be un-done, if need be, even under Windows 7. Backing out the change was first tested over two years ago, but I verified that it still works under Windows 7. As with earlier versions of Windows, you run regedit.exe, delete a key in the registry and re-boot. Instructions are at the end of Brown’s original blog posting.

Touting the Microsoft Line

Despite all of its advantages (recall the third paragraph of this article), the Brown/Atac approach gets no respect.

In the Windows Secrets newsletter, where Scott Dunn recommended it back in 2007, Susan Bradley suggested removing it in March 2009.

She argued that since Microsoft had finally gotten the bugs out of their implementation, Windows users should convert from the Brown/Atac scheme to the Microsoft way. Bradley offers advice on backing out the Brown/Atac changes, installing a patch from Microsoft and three different ways to disable autorun, depending on the version of Windows (unlike the Microsoft approach, the Brown/Atac modification works exactly the same in all versions of Windows).

Bradley says nothing about USB devices that appear as CD drives and does not go into the specifics regarding the five different aspects of autorun/autoplay. As for being bug-free, Microsoft issued yet another autorun related patch a few months after Bradley's article was published.

I'm a big fan of Steve Gibson and his Security Now podcast. But, his March 2009 podcast on autorun was devoid of any mention of the Brown/Atac approach. Somehow his research missed the original article by Nick Brown, Scott Dunn's article, the US-CERT warnings, Leo Notenbooms's article and my previous blogs. Instead, he chose to focus exclusively on the NoDriveTypeAutoRun registry key.

In an indictment of the Microsoft approach, Gibson pointed out that you could follow their published documentation to the letter and still be vulnerable to autorun worms. He found that it was controlled in two different places in the registry and Microsoft only documented one registry location. The location they ignored turns out to over-ride the one they describe. Oops.

He also complains about how Microsoft had just changed the way autorun works, but only for Windows Vista and Server 2008.

"... because of the nature of the way this was done, it ends up being extremely complicated because then they said, well, the problem is, if we push this out, and the behavior changes so that it's now correct, that may break things in a way that people don't want. So we're going to add another registry key to the already convoluted registry key that we'll talk about in a second, and which is still not documented correctly, called Honor Autorun Setting. Which they will default to a 1, meaning true, meaning yes, honor the Autorun setting which we have now fixed so that it really works. But in doing so it may have broken some things. So you now have the option of turning that off, if you want the pre-fixed behavior which sort of worked, but not really."

Brian Krebs, who writes the Security Fix column in the Washington Post also fails to mention the Brown/Atac option. Back in December 2008 he offered advice for disabling autorun that was incomplete, to say the least.

Discussing the Microsoft approach just recently he wrote that "... previous fixes were found to be half-baked, or in some cases the fix wouldn't take." Yet, does not offer an alternative.

Spread the Word

When even well-meaning techies are unaware of, or ignore, the Brown/Atac approach, we need to spread the word. Hopefully this article contributes to that.

In the mean time, you can do yourself a favor and update the registry using the Brown/Atac method. If it doesn't work out, then simply un-do the change. If we can just get more techies on board, Windows users would be safer.

Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved