1.0 DESCRIPTION

1.1 Overview

Due to a canonicalization error in IIS 4.0 and 5.0, a particular type of malformed URL could be used to access files and folders that lie anywhere on the logical drive that contains the web folders. This would potentially enable a malicious user who visited the web site to gain additional privileges on the machine � specifically; it could be used to gain privileges commensurate with those of a locally logged-on user. Gaining these permissions would enable the malicious user to add, change or delete data, run code already on the server, or upload new code to the server and run it.

The request would be processed under the security context of the IUSR_machinename account, which is the anonymous user account for IIS. Within the web folders, this account has only privileges that are appropriate for untrusted users. However, it is a member of the Everyone and Users groups and, as a result, the ability of the malicious user to access files outside the web folders becomes particularly significant. By default, these groups have execute permissions to most operating system commands, and this would give the malicious user the ability to cause widespread damage. Customers who have proactively removed the Everyone and Users groups from permissions on the server, or who are hosting the web folders on a different drive from the operating system, would be at significantly less risk from the vulnerability.

1.2 Affected

Microsoft IIS 4.0 (Windows NT4)
Microsoft IIS 5.0 (Windows 2000)

1.3 Cause

The vulnerability results because it is possible to construct an URL that would cause IIS to navigate to any desired folder on the logical drive that contains the web folder structure, and access files in it.

1.4 Scope

This vulnerability would enable a malicious user to cause code of his choice to execute on an affected web server. The specific code he could run would be limited by the specific server configuration, but in most cases, it would be possible for the malicious user to execute any code that a user logged into the server interactively could run. This would give him the ability to install and run code, add, change or delete files or web pages, or take other actions. This is a serious vulnerability, and Microsoft recommends that all customers using IIS 4.0 or 5.0 take action immediately to protect their systems.

A patch that was released in August 2000 for a different vulnerability provides complete protection against this vulnerability as well, and customers who have installed it do not need to take any additional action. Also, it is important to understand that the privileges gained via this vulnerability would be those of a locally logged-on user, and not those of the administrator. This means that if an administrator had previously restricted the privileges of non-administrative users on a system, this vulnerability would pose significantly less risk to it.

2.0 TECHNICAL MATTERS

2.1 What malicious user could do?

It would depend on the permissions associated with the particular file the malicious user requested. If the permissions enabled him to read the file, he could read it. If he had write access to it, he could change it. If it was an executable file and he had permission to run it, he could do so, and it would execute on the server. However, the vulnerability provides no way to circumvent the file permissions.

2.2 Vulnerability Limitation

The vulnerability only allows files to be accessed if they reside on the same logical drive as the web folders. So, for instance, if a web administrator had configured his server so that the operating system files were installed on the C: drive and the web folders were installed on the D: drive, the malicious user would be unable to use the vulnerability to access the operating system files.

Servers that are configured to host the web folders on their own logical drives would be at least risk from this vulnerability. Even in this case, though, it would be important to ensure that there were no files on the web folders that could be misused, such as sample web applications.

2.3. The Audit Log is enabled, would it be traced?

This vulnerability has no effect on normal auditing, so the administrator would be able to tell exactly what the malicious user had done.

2.4. Does the attacker have complete control of the server?

No. By itself, the vulnerability only would allow the malicious user to take actions in the context of the IUSR_machinename account, but this account doesn�t have access to some important files. For instance, backup copies of the system files in the winnt\repair folder, including the Security Account Manager file (sam._) are only accessible to administrators, and could not be obtained via this vulnerability. Similarly, the default permissions in Windows� 2000 are significantly more restrictive than those in Windows NT 4.0, and the exposure would therefore be less.

However, it is important not to underestimate the damage that a malicious user could cause. Even these privileges would give a malicious user an opportunity to cause significant damage. Worse, the vulnerability could potentially give him a beachhead from which to conduct additional attacks and try to obtain additional privileges. For instance, he could upload malicious code that exploits other known vulnerabilities, and try to exploit them.

3.0 PREVENTION

3.1 Patches

Both versions of IIS patches are available as stated below.

*Note: The IIS 4.0 patch can be installed on system running Windows NT 4.0 SP 5 and SP6a. It will be included in Windows NT 4 SP7. The IIS 5.0 patch can be installed on system running either Windows 2000 Gold or SP1. It will be included in Windows 2000 SP2.

IIS 4.0 patch
http://www.microsoft.com/ntserver/nts/downloads/critical/q269862

IIS 5.0 patch
http://www.microsoft.com/windows2000/downloads/critical/q269862

3.2 What does the patch do?

The patch eliminates the vulnerability by treating the malformed URL as invalid. This is correct behavior.

3.3 Best Practice(s)

Because of the risk of so-called "directory traversal" vulnerabilities, it�s worth taking defensive measures when setting up a web server. These are discussed in the Security Checklists for IIS 4.0 and 5.0, and include:

1. Install your web folders on a drive other than the system drive.
2. Eliminate all sample files and unneeded features from your site.
3. Move, rename or delete any command-line utilities that could assist an attacker, and set restrictive permissions on them.
4. Be sure that the IUSR_machinename account does not have write access to any files on your system.

4.0 MORE INFORMATION

To obtain more information on this virus, please refer to the following site :

4.1 Microsoft Security Bulletin
http://www.microsoft.com/technet/security/bulletin/ms00-079.asp

4.2 Securiteam.com
http://www.securiteam.com/windowsntfocus/

4.3 SecurityPortal.com
http://www.securityportal.com/topnews/weekly/microsoft20001023.html