W32.Nimda.A@mm attempts to infect unpatched Microsoft IIS Web servers. On Microsoft IIS 4.0 and 5.0, it is possible to construct a URL that would cause IIS to navigate to any desired folder on the logical drive that contains the Web folder structure, and then access files in it. A patch and information regarding this exploit can be found at http://www.microsoft.com/technet/security/bulletin/ms00-078.asp.

Successful exploitation of the Directory Traversal Vulnerability gives the attacker the ability to install and run code, as well as add, change, or delete files or Web pages on the compromised server. The limitations of the original vulnerability include:

The server configuration. The vulnerability only allows files to be accessed if they reside on the same logical drive as the Web folders.

For example, if a Web administrator had configured the server so that the operating system files were installed on the C drive and the Web folders were installed on the D drive, the attacker would be unable to use the vulnerability to access the operating system files.

The attacker must be logged onto the server interactively.

The gained privileges would be only those of a locally logged-on user. The vulnerability would only allow the malicious user to take actions in the context of the IUSR_machinename account.

However, by using the W32.Nimda.A@mm worm as a delivery mechanism, the attacker can remotely compromise a vulnerable IIS server, and once compromised, create a local account on the targeted server with administrator privileges, regardless of the drive on which the IIS server is installed.The worm uses directory traversal techniques to access cmd.exe on unpatched IIS servers. The worm also attempts to use the IIS servers that CodeRed IIhad previously compromised to propagate and to access root.exe from the inetpub/scripts directory.

NOTE: If Norton AntiVirus RealTime protection detects files such as "TFTP34%4.txt" as being infected with W32.Nimda.A@mm in your inetpub/scripts folder, you may have been previously exposed to CodeRed II. We recommend that you download and execute the CodeRed removal tool to make sure that your system has been cleaned of the CodeRed II threat.

The worm searches for Web servers using randomly generated IP addresses. Using the Unicode Web Traversal exploit, the worm copies itself to the Web server as admin.dll via TFTP. Infected machines create a listening TFTP server (port 69/UDP) to transfer the copy of the worm.

Then, this file is executed on the Web server and copied to multiple locations. In addition to this exploit, the worm attempts to exploit already compromised Web servers using the files root.exe or cmd.exe, which are located in remotely executable Web directories.

Then, the worm attempts to modify the files named default, index, main or readme, or files with the extensions .htm, .html, or .asp, by adding JavaScript. The JavaScript causes visitors who open infected pages to be presented with Readme.eml, which the worm created.

Readme.eml is an Outlook Express email file, with the worm as an attachment. The email messages use the MIME exploit. Thus, a computer may be infected by browsing the infected Web page.

System Modifications

When executed, the worm determines where it is being executed from. The worm overwrites Mmc.exe in the \Windows folder, or creates a copy of itself in the Windows Temporary folder.

Then, the worm infects executables, creates itself as .eml and .nws files, and copies itself as Riched20.dll in folders that contain .doc files on the local drive. The worm searches for files in the paths listed in the registry keys:

The worm hooks the system by modifying the System.ini file as follows:

Shell = explorer.exe load.exe -dontrunold

The worm also replaces the file, Riched20.dll, which is a legitimate Windows .dll file that programs, such as Microsoft Word, use. By replacing this file, the worm is executed each time programs (such as Microsoft Word) are executed.

The worm also registers itself as a service process or adds itself as a remote thread to the Explorer process. This allows the worm to continue to execute even when a user is not actively logged on.

The worm copies itself as the file, %Windows\System%\load.exe

NOTE: %Windows\System% is a variable. The worm locates the \Windows\System folder (by default this is C:\Windows\System) and copies itself to that location.

Next, the worm creates open network shares for all the drives on the computer by modifying the registry key:

A reboot of the computer is required for these settings to take effect.

The worm searches for all the open shares on the network by iterating through Network Neighborhood and by using randomly generated IP addresses. All the files on any open network shares are examined for possible infection. The worm infects all the .exe files except Winzip32.exe.

Next, the .eml and .nws files are copied to the open network shares, and the worm copies itself over as Riched20.dll to any folder that contains .doc files.

The worm changes the Explorer settings to not show Hidden files and known file extensions.

The worm adds the user, Guest, under the groups Guests and Administrators. This gives the guest account Administrative privileges. In addition, the worm actively shares C$ = C:\ No reboot is required.

Mass-Mailer

Nimda contains a mass-mailing routine that is executed every 10 days. The worm begins this routine by first searching for email addresses. The worm searches for email addresses in the .htm and .html files on the local system. The worm also uses MAPI to iterate through all the messages contained in any MAPI-compliant email clients. Any MAPI-supporting email clients may be affected, including Microsoft Outlook and Outlook Express. The worm uses these email address for the To: and the From: addresses. Thus, mail sent from the infected computer will appear to have been sent by the people whose addresses that Nimda found, not by the person whose computer is infected.

The worm uses its own SMTP server to send email messages using the configured DNS entry to obtain a mail server record (MX record).

When the worm is received by email, the worm uses an old known MIME exploit to auto-execute itself. The worm will be unable to execute using Microsoft Outlook or Outlook Express if the system has been patched against this exploit.
Information regarding this exploit can be found at http://www.microsoft.com/technet/security/bulletin/MS01-020.asp.

Infecting Executables

The worm also attempts to infect .EXE files. First, the worm checks to see whether the file is already infected. If the file is not infected, the worm makes a copy of itself in the Temporary directory. The victim file is embedded inside the copy. This new file is then copied over the victim file, replacing the originally clean file with an infected version. Infected executables will be approximately 57344 bytes larger. When an infected file is executed, the worm will extract the original clean file to a temporary file and execute it along with itself. Thus, one may not notice that their executable has become infected.

During execution, the worm may attempt to delete copies of itself. If the file is in use or locked, the worm will create the file, Wininit.ini, with an entry to delete itself upon reboot.

When infecting files, the worm may create two temporary files in the Windows Temporary folder as:

mep[nr][nr][letter][nr].TMP.exe

mep[nr][nr][letter][nr].TMP

Both files will be Hidden and have the system attribute set.

Ports that the worm uses are listed below. NOTE: These are all standard ports.

TCP 25 (SMTP): Used to send email to targets with addresses taken from the compromised client.

TCP 69 (TFTP): Opens port 69/udp for the TFTP transfer of admin.dll for the IIS infection. As part of this protocol, it makes outgoing connections to transfer the files.

TCP 80 (HTTP): Uses this port to target vulnerable IIS servers.

TCP 137-139, 445 (NETBIOS): Used in the transmission of the worm.

The worm contains bugs and can be resource-intensive. Thus, all the actions may not occur and you may notice system instability.

Recommendations

Symantec Security Response encourages all users and administrators to adhere to the following basic security "best practices":

Use a firewall to block all incoming connections from the Internet to services that should not be publicly available. By default, you should deny all incoming connections and only allow services you explicitly want to offer to the outside world.

Enforce a password policy. Complex passwords make it difficult to crack password files on compromised computers. This helps to prevent or limit damage when a computer is compromised.

Ensure that programs and users of the computer use the lowest level of privileges necessary to complete a task. When prompted for a root or UAC password, ensure that the program asking for administration-level access is a legitimate application.

Disable AutoPlay to prevent the automatic launching of executable files on network and removable drives, and disconnect the drives when not required. If write access is not required, enable read-only mode if the option is available.

Turn off file sharing if not needed. If file sharing is required, use ACLs and password protection to limit access. Disable anonymous access to shared folders. Grant access only to user accounts with strong passwords to folders that must be shared.

Turn off and remove unnecessary services. By default, many operating systems install auxiliary services that are not critical. These services are avenues of attack. If they are removed, threats have less avenues of attack.

If a threat exploits one or more network services, disable, or block access to, those services until a patch is applied.

Always keep your patch levels up-to-date, especially on computers that host public services and are accessible through the firewall, such as HTTP, FTP, mail, and DNS services.

Configure your email server to block or remove email that contains file attachments that are commonly used to spread threats, such as .vbs, .bat, .exe, .pif and .scr files.

Train employees not to open attachments unless they are expecting them. Also, do not execute software that is downloaded from the Internet unless it has been scanned for viruses. Simply visiting a compromised Web site can cause infection if certain browser vulnerabilities are not patched.

If Bluetooth is not required for mobile devices, it should be turned off. If you require its use, ensure that the device's visibility is set to "Hidden" so that it cannot be scanned by other Bluetooth devices. If device pairing must be used, ensure that all devices are set to "Unauthorized", requiring authorization for each connection request. Do not accept applications that are unsigned or sent from unknown sources.