After an anonymous user posted a summary of a serious flaw in Internet Information Server (IIS) 4.0 and 5.0 to the Slashdot Web site, Microsoft was soon alerted to the problem by a reader using the alias "Rain Forrest Puppy." The vulnerability could allow a remote user to gain elevated privileges on a remote IIS system, including the ability to start services and transfer files.
The problem stems from the improper filtering of UNICODE characters in URLs submitted to the server. By using specifically craft URLs that contain these characters (the values %c0%af and %c1%9c), remote users could perform a variety of actions, which would transpire under the context of the system's IUSR_machinename account generally associated with the Web service. However, even though the IUSR_machinename account is somewhat limited in its capabilities, significant risks still exists. Microsoft quickly released a bulletin, patches, FAQ, and TechNet article Q276489 to help remedy the problem. Users are urged to load the patch, however take note that in their FAQ, Microsoft points out that systems with the "File Permission Canonicalization" patch issued on August 10, 2000 (in relation to bulletin MS00-057) are already protected against this vulnerability.
Users with foreign versions of Windows operating systems have recently complained loudly that Microsoft takes too long to issue patches for foreign language versions of the OS. German Windows NT user Frank Heyne recently pointed out in a message posted to the NTBugTraq mailing list that out of some nineteen Microsoft security bulletins, which he researched back to March 30, 2000, only four had patches available for the German language versions of Windows NT. However, the seriousness of this new IIS problem poses such a large risk across so many systems worldwide that Microsoft has made the patch immediately available in 10 langauges.
Senior Technologist for Microsoft Corporate Security and Windows 2000 Magazine columnist David LeBlanc posted several tips in relation to IIS security that among other things, help to prevent Web site defacements from attackers using this vulnerability (or future vulnerabilities of a similar nature). For example, administrators should ensure that the IUSR_machinename and IWAM_machinename accounts do not have write access to the server's Web content files and directories. David also pointed out the need to ensure registry permissions are set properly. In particular, ensure that the IUSR_ account does not have write access to the "HKEY_LOCALMACHINE\Software" tree or its subtrees.
In addition, David pointed out the need to identify command-line tools that might be useful to an attacker. Utilities such as cmd.exe, net.exe, ftp.exe, cacls.exe, etc., all pose a serious risk to the system when left exposed to non-administrative accounts. David suggests that administrators adjust Access Control Lists (ACLs) on all administrative tools so that only the Administrator account has full control, with no other groups or users defined in the ACLs for those tools. A second option is to create a new group (for example, ConsoleAdmins) and then define that group as having full control over the tools.
David also reminds readers not to set the administrative tool's ACLs to include the Administrators group because the powerful LocalSystem account is a member of that group, and the IIS service uses the LocalSystem account to perform actions in certain instances. Under a worse case scenario you can assume an attacker will find a way to exploit the LocalSystem account, so if the account does not have access to administrative tools then any potential damage would be limited.