The best way to disable Autorun for protection from infected USB flash drives

My first posting on the topic of Autorun/Autoplay, Test your defenses against malicious USB flash drives, described three ways that bad guys trick people into running  malicious software that resides on an infected USB flash drive.

Although, at times, flash drive resident software can run by itself (think U3 flash drives) without any action on the part of the computer user (other than inserting the USB flash drive) the more normal case is that a person has to be tricked. My first posting on this topic has a sample autorun.inf file that safely illustrates three of these tricks, and you can download this file to test how well your PC is defended from inadvertently running software off the flash drive. Odds are that any Windows computer will be susceptible to at least one of the tricks.

Have no fear though, after making the simple change described below the only way to get infected by an infected USB flash drive is to manually seek out and run the malware (run.me.to.see.naked.pix.of.some.celebrity.exe). You won't be tricked into running it.

DEFINING AUTORUN AND AUTOPLAY

In my previous posting I griped about the terms Autorun and Autoplay. Microsoft uses these terms to mean different things at different times.  
 
The classic/legacy definiton of Autorun is described by Dan McCloy as:     

AutoRun is the functionality that enables a CD-ROM drive or a fixed drive to specify a program or document to be started immediately upon the connection of the drive. Autorun has been designed not to work on removable drives such as USB flash drives, as these drives are much more readily infected and passed around to other computers.

Autorun was introduced back in Windows 95 and the living embodiment of it, is a configuration file in the root directory of removable media (CDs, USB flash drives, external hard drives, etc.) called autorun.inf. If you've ever inserted a CD into a Windows computer and had a program run automatically, autorun was behind it. My first posting on this subject offered a sample autorun.inf file.

Autoplay was introduced with Windows XP. Whereas autorun literally ran a program automatically, Autoplay puts the computer user in charge. A sample Autoplay window is shown below, no doubt you've seen it many times. 

 When Autoplay is enabled, Windows examines a newly inserted thingy (removable media) and offers a choice of programs to process the various types of files it finds. Autoplay looks for an autorun.inf file too. As we saw in my initial posting, the first Autoplay option can be controlled by directives in the autorun.inf file (this explains the first option in the screen shot above). However, Autoplay does not need or depend on the autorun.inf file (Autorun does).

Autoplay was a misnomer from the get-go, the only thing that happens automatically is the presentation of the Autoplay window. A better name would have been AutoDetect as the automatic processing is limited to detecting file types. No playing happens automatically.

TWO APPROACHES

There are two approaches to defending your computer from the Autorun and Autoplay tricks that I described in my first posting on the subject.

One approach, offered by Microsoft (which invented the problem in the first place) is to disable stuff.* This approach is, in my opinion, a complicated mess involving multiple registry keys, different behavior in different versions of Windows, different treatment for different types of devices, bugs in Windows,  poor documentation, missing patches, yada yada yada. Life is too short.

Fortunately, two lone techies, Nick Brown and Emin Atac came up with a better solution that directly targets the source of the problem, the autorun.inf file. It deals with the disease rather than the symptoms. In fact, if you employ this solution, you can leave Autoplay (as defined above) enabled and let it, perhaps, serve a useful function. 

What the Brown/Atac solution does is tell Windows to ignore any and all autorun.inf files. Period.

I tested Microsoft's approach with Windows XP SP2 and SP3 and will go into the details of where it works and where it falls down in the next posting. It can work, but, only if you twist like a pretzel when the moon is shining on a Tuesday. And, it is not a comprehensive fix, loopholes, such as U3 devices remain open. Nick Brown's approach, on the other hand, is ironclad, it always works, no IFs, ANDs or BUTs.
 
Just a few days ago, Dan Goodin in The Register wrote Disabling Windows Autorun - there's a right way and a wrong way. He was referring to two variations of the Microsoft approach. What Mr. Goodin considers the right way, I consider the wrong way.

To illustrate my point, the Microsoft Knowledge Base article that Goodin cites as the right way (How to correct "disable Autorun registry key" enforcement in Windows), offers no solution for Windows XP Home Edition users. Way to go Microsoft. In contrast, Nick Brown's solution does protect users of the Home Edition of Windows XP.

Goodin's article also illustrates the language problem that Microsoft has dumped on the world, forcing us to use two words to describe five different things. He wrote that Autorun is turned on by default, which is, strictly speaking, not true. For example, neither Windows XP SP2 nor SP3 automatically run a program on a USB flash drive.

IMPLEMENTING NICK BROWN'S SOLUTION

Nick Brown's solution requires updating the registry. Although the update can be removed, it can't hurt to make a full backup of the registry first. Windows XP and Vista users can do this using System Restore.

In XP: Start -> Programs -> Accessories -> System Tools -> System Restore. Click on the radio button to "Create a restore point" -> enter any description (a good example might be "before zapping the registry to disable autrun") then click on the Create button. It should take less than 10 seconds.

In Vista: Start -> enter "system restore" in the search box -> click the link to "Open system protection" -> this opens a new System Properties window -> click the Create button at the bottom -> enter any description (a good example might be "before zapping the registry to disable autrun") then click the Create button (not the same Create button as before, the new one).

Zapping the registry is simple, all you need is the three lines shown below in a .reg file. Then double click on the file.

You can either copy the three lines below from this web page or download the file using the link at the bottom of this posting. The file name is not important, other than it should end with ".reg". Computerworld does not allow attaching files ending with ".reg" to a blog posting, so the file type is ".txt" and you'll have to rename it to end with ".reg".

Note that there are three lines in the file, the middle line may wrap when displayed by a web browser, but it needs to be a single line in the .reg file.

Nick Brown explains what this does:

This hack tells Windows to treat AUTORUN.INF as if it were a configuration file from a pre-Windows 95 application ... it says "whenever you have to handle a file called AUTORUN.INF, don't use the values from the file. You'll find alternative values at HKEY_LOCAL_MACHINE\SOFTWARE\DoesNotExist." And since that key, er, does not exist, it's as if AUTORUN.INF is completely empty, and so nothing autoruns, and nothing is added to the Explorer double-click action. Result: worms cannot get in - unless you start double-clicking executables to see what they do ...

The text "DoesNotExist" in the third line is meant to be a place in the registry that does not exist. If this zap gets very popular, malware may look for it, so it can't hurt to change it just a bit. For example, I might use something like
   @="@SYS:DoesNotExistMichael"
on my computers. To be clear, this is not at all required. The zap as shown above works fine.

Once you have a dot reg file on your computer, just double click on it.  

On a Windows XP computer, you'll see the following warning before the registry zap is actually made ...

On a Vista machine, you'll first have to deal with UAC as shown below.

Then you'll see the following warning before the zap is actually made ...

and the following confirmation afterwards.

I've read that you may have to restart Windows for this registry zap to fully take effect. A reboot wasn't needed in my testing on XP SP2, XP SP3 and Vista machines.

A USB flash drive inserted in an XP machine when the zap was made, lives by the old rules until it is ejected, at which point the new sheriff takes control.

NEW SHERIFF IN TOWN

As Nick Brown explained, his zap tells Windows never to process an autorun.inf file. It has no effect on the Autoplay feature of Windows. If Autoplay was being invoked before the registry zap, it will still be invoked afterwards. If Autoplay was not in effect before the zap, it will remain off afterwards.

The zap will, however, disable the ability of an autorun.inf file to create an entry in the Autoplay window (for more on this, including examples, see my first posting on this subject, Test your defenses against malicious USB flash drives).

After the zap, double-clicking on any drive icon will always list the files/folders in Windows Explorer. This is true for USB flash drives, CDs, external hard drives, network shares, etc. The zap also insures that autorun.inf files can't modify the context menu any more. Again, you can see and test these changes using the sample autorun.inf file from my first posting.

Perhaps the most obvious change the zap makes is to the drive icon and name. My test autorun.inf file changes the drive name to "Testing AutoRun Stuff". After applying Nick Brown's registry zap, a test USB flash drive appears as "Removable Disk (x)", where x is the drive letter. My test file also makes the icon for Paint, the drive icon. After this zap, the drive icon appears as a normal Windows drive icon.

These simple changes serve as a great "tester". You can use them, in conjunction with my test autorun.inf file, to verify that Nick Brown's zap has been applied.

The only other way to know whether it has been applied is to look into the registry. If you do, you should see something like the below.

On the other hand, it does no damage to make this registry change on a computer where it has already been made.

This registry zap does not interfere with booting the computer from a CD or from a bootable USB flash drive. The zap only comes into play after Windows is up and running.  

RESTORING THE OLD SHERIFF

Should you ever want to undo this registry zap, Nick Brown suggests:

open REGEDIT and navigate down to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping. There will be a subkey ("folder") called Autorun.inf. Delete it.

Regedit is the Windows registry editor. To run it in XP, click Start -> Run -> type "regedit" without the quotes -> then click the OK button. To run it in Vista, click Start and type "regedit" into the search box. 

The look and feel of browsing the registry with regedit is very much like browsing files and folders with Windows Explorer. You delete a subkey in the registry by right clicking on it and selecting Delete from the popup menu.

After deleting the autorun.inf subkey from the registry, you have to reboot (at least in Windows XP) for the change to take effect.

As with making the zap initially, it's a good idea to backup the registry by creating a Restore Point beforehand.

FURTHER READING

For more on this see Microsoft Windows Does Not Disable AutoRun Properly (a.k.a. Technical Cyber Security Alert TA09-020A) from the U.S. Computer Emergency Readiness Team (US-CERT). It discusses the Nick Brown zap and some flaws in the Microsoft approach.  

Another proponent of Nick Browns approach was Scott Dunn who wrote One quick trick prevents AutoRun attacks  in November 2007, shortly after Nick Brown made his discovery public.

I can't help but note that two lone techies (Nick Brown and Emin Atac) came up with a great solution while Microsoft keeps twisting the problem like spaghetti, as if the whole thing was designed for job security.

I'll list all my gripes with the Microsoft approach in an upcoming posting.

Just for the record, I don't know Nick Brown. I have never spoken to him, emailed him or even seen his picture. But, I do know a good idea when I see it.

Update February 3, 2009: In the next posting on this subject, I test Nick Brown's registry zap on Vista SP1.