An other reason is that I don’t like black boxes and it is my opinion that all knowledge should be disseminated in the open :-).

So how does the “vaccination” work? (as a sidenote: in the “olden days” – meaning DOS – the idea of “vaccination” was quite common and was based on the idea of emulating the checks which different viruses used to detect if they already infected the system. This quickly became unmanageable, since not all viruses checked for previous infections and some used the same vector but wanted different results. This program however has nothing to do with this method of vaccination.)

There are actually two components to it:

• The “immunization” of the computer: this is done by the IniFileMapping feature I also discussed.

• The “vaccination” of the USB drives: this is done by creating a folder named “autorun.inf” on the drive. Since folders and files are the same on most file systems, you can’t create a file and a directory with the same name. There is also some additional magic involved: the tool creates a file named lpt1 in the folder named autorun.inf (so you have the structure U:autorun.inflpt1) in which it writes “caacaacaacaacaa” (don’t ask my why, I have no idea – it seems to be gene sequence).

  This makes the folder undeletable by conventional tools. The reason is the interaction with compatibility (in DOS LPT1 referred to the printer port, so for compatibility reasons Windows tries to open the printer port whenever you ask for LPT1). For a more detailed description and workarounds which can be used see the section “Cause 5: The file name includes a reserved name in the Win32 name space” in KB320081 from Microsoft. A couple of errors in the announcement:

  • The announcement claims "USB drives that have been vaccinated cannot be reversed except with a format". This is not actually true, in fact the "vaccination" can be undone as described in the Microsoft KB.
  • "Panda USB Vaccine currently only works on FAT & FAT32 USB drives" – while this is true, the reason for it is that the program explicitly checks for the given filesystems (possibly because the authors thought that the method works because of quirks in the FAT filesystem, but in fact it works because the compatibility layer in the Win32 API, independent of the underlying FS). Also, on the NTFS filesystem other tricks can be played to create “undeletable” files / folders (like removing all the permissions for the given item, playing with the fact that NTFS is case sensitive – even though case insensivity is emulated by the Win32 API, etc), but none of them is irreversible as the blogpost claims. A possibly irreversible (or more accurately: very hard to reverse) change would be to open the disk directly and much around in the allocation tables / MFT and selectively corrupting it, but this would be very risky.

So there you have it. Nothing too magical and some errors/misunderstanding in the original post. Also, it is quite possible that future malware will look for the “immunization” on USB drives and reverse it.

Picture taken from Clearly Ambiguous’ photostream with permission.

But how tolerant is the autorun.inf parser (which I suppose in fact is the INI file parser) really? The example showed by F-Secure is quite mild, in the sense that each line is preceeded by “;” to clearly mark it as a comment. We can up the ante by just putting arbitrary garbage, without the “;” marker:

for (1..255) { print chr(rand(256)); }
print "n[autorun]n";
for (1..255) { print chr(rand(256)); }
print "nopen=C:\WINDOWS\NOTEPAD.EXEn";
for (1..255) { print chr(rand(256)); }

This works! I didn’t how large the binary blocks can be, but I imagine that you can go 32k-64k easily. Now to put an extra twist in there:

print "xFFxFE";
for (1..255) { print chr(rand(256)); }
print "n[autorun]n";
for (1..255) { print chr(rand(256)); }
print "nopen=C:\WINDOWS\NOTEPAD.EXEn";
for (1..255) { print chr(rand(256)); }

That FF FE is the Byte order mark(er) and tells text editors which recognize it that the file is UTF-16 little endian encoded, which of course it isn’t. The end result? You will see only garbage in Notepad (as it tries to “decode” the file) and also in my favorite file management app. And yet, it still works!

Have fun, stay safe and make sure that to disable your autorun.

Update: the commenter had a good idea. In response: strings extracts the strings correctly (I tried it under Linux, but I assume that the Windows version would behave the same). However, for example gedit can’t open it.

What is autorun malware?

Autorun malware is malware which uses the autorun feature present in Microsoft Windows as a way to spread itself. This might or might not be the only spreading method it employs.

What is the autorun feature? Why is it present?

This is a feature whereby you can ask Windows to run an executable when a new disk is inserted / clicked on. Although I have no official sources, I assume that this was implemented to make the installation/use of software from removable media (mainly CDs at the time) easier. Without this feature you would have to insert the CD (DVD), open a file manager (Windows Explorer for example), navigate to the CD drive, select the appropriate file and run it. With this feature however, Windows would sense that a new CD has been inserted, see that it has instructions on which executable to run, and start it automatically. The default executable usually checks if the software is already installed, and if so, launches it from the hard-drive, or, if not, offers to install it.

While until now I’ve been talking about CD/DVD drives, this feature can be used on any type of drive. Drive types can be divided into two categories from the point of view of this feature:

• Those which notify the OS (Windows) about the fact that the media in them has changed. These include CD/DVD drives and USB drives of all kind. They do not include floppy drives.
• Those which don’t. These include hard disks and floppy drives for example.

The autorun facility can be used with both types of drives, what differs is the time when the activation occurs. With drives where Windows is notified in the event of a media change, the new media is automatically scanned for instructions on which file to execute, and if such instructions are found, they are carried out. In the case of disks which don’t notify Windows when they change, the presence of the instructions is checked (and if present, carried out), when the root of the drive is accessed (for example by going to My Computer -> C:).

To summarize, the typical flow of events is the following: a disk contains a malware file and instructions for this file to be executed automatically. When the disk is inserted / accessed (depending on the type of disk), windows executes the malware.

A small historical note: this feature was first introduced in Windows 95 / 2000, however problems only appeared recently when flash based storage (sticks) became widely used, because they provide an easily writable solution for malware (as opposed to CDs/DVDs).

Can you give me more technical details?

Of course :-). The instructions are kept in a file named autorun.inf in the root of the drive. Windows checks for the presence of this file whenever it needs to (when a new media is inserted, when the root of a disk is accessed, etc). You can read more details about the different options available on this site for example or from MSDN (Microsoft Developers Network).

The file has a text-based format, so you can inspect the files using a program like Notepad. The best way to inspect a file is to run Notepad (from the Start menu for example), go to File -> Open and type in “F:autorun.inf” (with the quotes). Of course you have to replace the disk letter from this example (F) with the actual disk letter you are interested in. This method has at least two advantages over navigating with Windows Explorer to the root folder, finding the file and rightclick – editing it:

• Navigating with Windows Explorer might trigger the execution of the program indicated in the autorun file (see the previous point). This can be bad if we are talking about possible malware
• The file might have the hidden attribute set, so that it’s not visible by default in Windows Explorer (and the folder settings tab, where you can change the options for displaying hidden files, might be deactivated – see further down)

This file acts as a pointer to the actual executable which is run in case the feature is active. The path of the executable is relative to the root of the drive where the autorun.inf is located. Thus, if you see something like foobar.exe in the file F:autorun.inf, the actual executable file is F:foobar.exe.

What is the difference between Autorun and AutoPlay?

Autoplay is the name of a different technology which aims to achieve the same thing: open up a relevant application when a new media (CD / DVD / USB) is inserted. This is done by searching the media upon insertion to determine the majority content type (music, pictures, video, etc) and presenting a menu based on it.

The presented menu contains programs which are installed on the local computer. This means that no new software is run automatically, making this feature a whole lot less risky than the autorun feature. Autoplay is only activated if autorun is not present or has been disabled (or to put it an other way: autoplay is related to the media change notification – described below – while autorun is one level up).

Can I turn off autorun? What is the disadvantage of turning it off?

The good news is: yes, it is possible. There are several methods actually:

The first (temporary) solution is holding down the shift key while inserting the new device (CD / DVD / USB stick). This will prevent autorun from kicking in, however it has several disadvantages:

• It is only a temporary, one-time solution. You must remember to always do this whenever you insert new media.
• It is prone to error. You might press it to late or release it too early.
• There is no visual or audible feedback that you proceeded correctly (pressed down in time and didn’t release it too early)

A second solution is to disable the media change notifications. This isn’t recommended and has several disadvantages (the most severe being that it doesn’t affect USB devices, the main problem source). If you still want to do this, here is the command you have to execute (adapted from this MS KB article):

REG ADD HKLMSystemCurrentControlSetServicesCDRom /v Autorun /t REG_DWORD /d 0 /f

This disables MCN for all the CD/DVD drives. There are two other registry keys which can selectively disable MCN for a particular CD/DVD device (if multiple devices are present in the computer). There are documented on Technet, but again, this approach is not recommended.

The third, and recommended, approach would be to use the NoDriveTypeAutoRun registry key (the referred Microsft documentation describes Windows 2000, but the information is relevant to newer versions of Windows too). When this key is set, Media Change Notifications are delivered, but the autorun files are not parsed / acted upon. This key is actually a combination of values, which describe what type of drives (not) to use the autorun.inf feature for. For example, to disable autorun for all types of drives, you would use the 0xFF value:

REG ADD HKCUSoftwareMicrosoftWindowsCurrentVersionPoliciesExplorer /v NoDriveTypeAutoRun /t REG_DWORD /d 0xFF /f
REG ADD HKLMSoftwareMicrosoftWindowsCurrentVersionPoliciesExplorer /v NoDriveTypeAutoRun /t REG_DWORD /d 0xFF /f

As you can see above, there are actually two registry locations: one for system wide (HKLM) and one specific for the local user (HKCU). From the technet documentation:

Autoplay is also disabled on any drive if it is disabled by the value of NoDriveAutoRun (in HKLM or HKCU) or NoDriveTypeAutoRun (in HKLM or HKCU). But if NoDriveAutoRun or NoDriveTypeAutoRun appear in HKEY_LOCAL_MACHINE, the corresponding entries in HKEY_CURRENT_USER are ignored.

This means that it is best to set the flags in both locations. If you would like to disable autorun for all types of drives except CD/DVD drives (a more relaxed, but still mostly secure choice), you should use the value 0xDF.

As for the disadvantages: the impact for turning off autorun for non CD/DVD drives is minimal. Autoplay is still active, meaning that if the user is accustomed to selecting actions from the menu (for example when inserting a memory card with photos s/he can select directly a photo management application), s/he can still use this method. When turning off autoplay for CD/DVD drives, applications from there will not run automatically, which can be a usability hurdle (for example the user might be accustomed to launching an application by inserting its CD) and users need to be retrained. Finally, disabling media change notifications is the most problematic solution (and actually, somewhat misguided, because it only affects CD/DVD drives, not the source of most problems, USB drives) and can result in phantom files appearing (the contents of the old disk being shown, even after a new disk has been inserted into the drive). This method is not recommended at all.

Update: this blog posting from the McAfee blogs seems to indicate that under some circumstances the settings can reset themselves, and you can use the following registry hack as a more permanent solution:

REGEDIT4
[HKEY_Local_MachineSoftwareMicrosoftWindows NTCurrentVersionIniFileMappingAutorun.inf]
@="@SYS:DoesNotExist"

Update: It seems that Windows caches the autorun.inf files executed during the current logon session under the HKEY_CURRENT_USER Software Microsoft Windows CurrentVersion Explorer MountPoints2 key. This means that even if you disabled autorun, you may get reinfected if the given autorun.inf file has already been seen during the current logon session. To counter this, be sure to logout/login (or better yet, restart your computer) after making the changes and test them using a bening autorun.inf.

Update: Given the recent problems US-CERT published a document titled “Microsoft Windows Does Not Disable AutoRun Properly“, in which they say that Windows might not disabled autorun, even if the proper registry keys are present and they recommend the “@SYS:DoesNotExist” method. Microsoft quickly reacted and it seems that you need to install a hotfix (which doesn’t get pushed automatically via Windows Update for XP, 2k and 2k3). The CERT document has also been updated.

I have a small / medium / large network of computers. Can I make these changes automatically on each one?

You have the computers in a Domain, you can use Group Policy to do the changes. If they are not, you can create a batch file with the appropriate commands for example and run it on each computer. You can even use the autorun.inf file to disable the autorun feature: grab an USB stick, create a batch file which executes the commands and an autorun.inf file which points to the batch file. Now go around a put the USB stick in each computer. Ironic, isn’t it?

Why do you use the REG command instead of importing .reg files or the registry editor?

Many malware families set a registry key which prevents regedit from functioning. Reg.exe however doesn’t verify this registry key and works regardless of its value. It is also easier to use from batch files.

I can’t run task manager / registry editor / change folder settings / use “Run” from the start menu. Is this related?

Probably. It is common for this type of malware to disable these tools to make their detection / removal harder. What can you do?

To enable the task manager:

REG ADD HKCUSoftwareMicrosoftWindowsCurrentVersionPoliciesSystem /v DisableTaskMgr /t REG_DWORD /d 0 /f
REG ADD HKLMSoftwareMicrosoftWindowsCurrentVersionPoliciesSystem /v DisableTaskMgr /t REG_DWORD /d 0 /f

To enable the registry editor:

REG ADD HKCUSoftwareMicrosoftWindowsCurrentVersionPoliciesSystem /v DisableRegistryTools /t REG_DWORD /d 0 /f
REG ADD HKLMSoftwareMicrosoftWindowsCurrentVersionPoliciesSystem /v DisableRegistryTools /t REG_DWORD /d 0 /f

To enable the folder settings page in explorer (to be able to see hidden files):

REG ADD HKCUSoftwareMicrosoftWindowsCurrentVersionPoliciesExplorer /v NoFolderOptions /t REG_DWORD /d 0 /f
REG ADD HKLMSoftwareMicrosoftWindowsCurrentVersionPoliciesExplorer /v NoFolderOptions /t REG_DWORD /d 0 /f

To enable the run menu:

REG ADD HKCUSoftwareMicrosoftWindowsCurrentVersionPoliciesExplorer /v NoRun /t REG_DWORD /d 0 /f
REG ADD HKLMSoftwareMicrosoftWindowsCurrentVersionPoliciesExplorer /v NoRun /t REG_DWORD /d 0 /f

To enable the command prompt:

REG ADD HKCUSoftwareMicrosoftWindowsCurrentVersionPoliciesSystem /v DisableCMD /t REG_DWORD /d 0 /f
REG ADD HKLMSoftwareMicrosoftWindowsCurrentVersionPoliciesSystem /v DisableCMD /t REG_DWORD /d 0 /f

It is not uncommon for malware to set these registry keys in a loop (for example once every second), so you should try to remove any infection from the machine before trying to reset the registry settings.

My Anti Virus product stopped working. Is this related?

Possibly. It is common for malware to contain a list of processes/services (related to security products) and try to kill these processes / stop the services (usually they don’t succeed if they aren’t running with administrative rights, which is an other good reason to be running as a non-privileged user). This can partially or entirely disable security products.

To re-enable your security product(s), after cleaning the machine, it might be enough to restart it. If this isn’t effective, try running the original install kit for it. Many of the install kits have a repair option, which you should try. Finally, if this didn’t fix the problem either, you should uninstall and then reinstall the product.

I have a server which shares out directories to clients. autorun.inf files keep turning up in the shared directories. Is my server infected?

Probably not. Remember that the autorun.inf file has to be located in the root of the drive to function. The most likely cause is that a client, which mapped the share to a drive letter, is infected (because to it the shared directory is the root of the drive – the network drive that is).

What can you do? When possible, share directories only as read-only. To find out which client is infected, I successfully employed the following method: start capturing the network traffic with Wireshark. Delete the autorun.inf file and wait until it re-appears. Now stop the capture and search in it for the string autorun.inf (without the quotes). This should provide you with the IP address of at least one infected client.

How does this relate to the U3 technology?

U3 compatible devices are a class of USB storage devices with some special hardware in them. A part of the flash storage is reserved and stores a image of a CD. When inserted in a computer, the hardware presents two devices: a CD drive which contains the data from the reserved area and a standard USB storage device, consisting out of the remainder of the storage. This means that we have to think about a U3 device as two separate devices: a CD drive and a USB stick. There isn’t anything magical or mysterious about these devices which allows them to auto-execute, the same settings apply to them as to normal CD drives or USB sticks. If you for example disable autorun for all devices, the U3 Launchpad won’t execute.

Some advice for USB stick owners

If you have an USB stick which you carry around and put in other people’s computers, make sure that you have disabled autorun on your computer and check the stick periodically for an autorun.inf file. Some models have a write-protect switch, which (when activated), makes the stick read-only at a hardware level, protecting it from infection. If possible, get one with this switch and use it whenever you only want to share data.

And finally: remember that USB stick are very tiny and can easily get lost / stolen. Use something like TrueCrypt with a strong password to keep the information safe on it from prying eyes, even after you loose control of the physical device.

Update: Panda released a tool to immunize computers / flash drives. While it is far from perfect, and is effective in 99.99% of the cases (at least until the bad guys catch up and start to put code in the malware to remove the “unremovable” autorun.inf folder).

Update: Via the Microsoft MMPC blog: Autorun will be disabled for USB sticks in Windows 7. This is a very good move, which removes the source of the problems, but there is a long way until Windows 7 becomes the main version of Windows out there (given how it’s not even out yet).