Win2K SP2 fixes many IIS 5.0 security problems

In "Security Considerations for Migrating from NT to Win2K, Part 4," August 2001, I covered IP Security (IPSec), its implementation within Windows 2000, and how it can help improve the security of connections on your network. In Part 5, I look briefly at the new Win2K Service Pack 2 (SP2) and its major security fixes and describe a few simple steps for securing Microsoft Internet Information Services (IIS) 5.0, the IIS version included with Win2K.

You might be wondering what an article about Win2K SP2 and IIS 5.0 is doing in a series about migration from Windows NT 4.0 to Win2K. Many people have been waiting to upgrade to Win2K until it had been knocked around a bit and Microsoft had patched it up. With SP2, Win2K has arrived at that point. SP2 fixes enough problems—including some glaring IIS 5.0 problems—that you can now safely start your migration from NT 4.0.

A Pretty Good Fix
Win2K SP1 included a variety of fixes, patches, and security-vulnerability fixes. Win2K SP2 contains SP1's fixes plus a long list of security-vulnerability fixes that Microsoft has released since SP1. Microsoft released some patches and vulnerability fixes too late to include them in SP2. In addition, many Microsoft Internet Explorer (IE) 5.5 patches and security fixes are included in the IE service pack and not in SP2. Despite these omissions, SP2 fixes many security vulnerabilities. For a fairly comprehensive list of the security vulnerabilities that SP2 fixes (not including the ones SP1 fixes), go to http://www.microsoft.com/technet/treeview/default.asp?url=/technet/itsolutions/security/news/w2ksp2.asp. For a list of SP1's security fixes (which SP2 includes), go to http://www.microsoft.com/technet/treeview/default.asp?url=/technet/itsolutions/security/news/w2ksp1.asp.

You can install SP2 from the Windows Update Web site at http://windowsupdate.microsoft.com. If you prefer to download SP2 to your hard disk or network so that you can install it on several systems, go to http://www.microsoft.com/windows2000/downloads/servicepacks/sp2/sp2lang.asp. Be forewarned that Win2K with SP2 is a hefty download (more than 100MB).

As with any major software patch, before you install SP2 on a system, you should fully back up the system. You should also make sure that SP2 is compatible with any third-party software running on the system. If you can't find information about your software on Microsoft's TechNet Web site (http://www.microsoft.com/technet) or the Microsoft Knowledge Base Web site (http://search.support.microsoft.com/kb/c.asp), contact Microsoft or the third-party software vendor to confirm the product's compatibility with SP2.

SP2 includes a variety of fixes related to IIS 5.0 security. For example, SP2 remedies two IIS 5.0 Denial of Service (DoS)—related problems that Microsoft's MS01-014 and MS01-016 security bulletins describe. The MS01-023 security bulletin provides a particularly important fix for an IIS 5.0 buffer overrun exploit that, when executed, can give the intruder complete control over the Web server, including the ability to change Web pages, add users with administrative rights, or even format the hard disks.

After you install SP2, you should visit the TechNet Security site's Security Bulletin Search page at http://microsoft.com/technet/treeview/default.asp?url=/technet/itsolutions/security/current.asp and download any IIS-related patches that Microsoft has made available since SP2. For example, you should apply the major patch that the MS01-033 security bulletin provides. The MS01-033 patch covers another dangerous IIS buffer overrun exploit. For more information about this vulnerability, go to http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/ms01-033.asp.

IIS Vulnerabilities
Given the rate at which intruders find new vulnerabilities in IIS, you might think that IIS is impossible to secure. New vulnerabilities can be rather alarming, but taking some basic security precautions can prevent intruders from exploiting many of these vulnerabilities on your systems. Administrators who perform a few basic steps to secure IIS services on their servers will likely have no problem with the MS01-023 or MS01-033 vulnerabilities (however, keeping up with the latest security patches is still a good idea). I'll show you what these steps are in a minute.

MS01-023 pertains to an Internet Server API (ISAPI) extension that lets users print directly to a URL from a remote site and check the status of their print jobs. The extension has an unchecked buffer in a section of code that handles input parameters. MS01-033 pertains to a component of Indexing Service that provides support for administrative scripts (.ida files) and Internet Data Queries (.idq files). This component has an unchecked buffer in code that handles input URLs. Most organizations don't need or use these ISAPI extensions. However, IIS 5.0 installs the extensions by default, so they're there to exploit unless an administrator removes support for them, applies the MS01-023 and MS01-033 patches, or disables the IIS services.

To exploit the extensions' vulnerability, an intruder mounts a buffer overrun attack (i.e., sends more data than the program's memory buffer can handle), thus causing the program to fail. Not all programs are vulnerable to buffer overrun attacks; vulnerability entirely depends on how developers wrote the software.

If the extra data in a buffer overrun attack is random code (i.e., a jumble of characters or data that doesn't really mean anything), the program leaves behind a shell of itself when it fails. This shell usually has the same privileges as the program had when running—in the case of ISAPI, full system privileges. If the intruder data contains functioning program code, the ISAPI shell executes the code with the same system-level permissions as the ISAPI service would.

You can see that an intruder could take control of a system by performing a buffer overrun attack or two and having the ISAPI service launch with full system privileges whatever software he or she desires. Let's look at some IIS 5.0 settings that can help secure your Web server against such attacks. Remember that the settings and steps I describe are just a starting point in securing your IIS 5.0 server. You must also be vigilant about keeping up with the TechNet security bulletins and applying service packs and security patches.

Basic IIS Security
You can perform a few basic steps to improve the security of your IIS 5.0 services under Win2K (IIS 5.0 can also run on NT 4.0). For this discussion, I assume that IIS 5.0 is installed, the default (or another) HTTP site is up and running, and Win2K is properly secured (because software is only as secure as the OS it runs on).

The first basic step is to limit access rights to IIS folders. Microsoft recommends creating under your IIS root directory separate folders for files that require different types of user access. For example, you might put text files in a folder with read access and programs in a folder with execute access. Table 1 shows file types, some folders you might create to contain those files, and the security access rights that you should apply to the folders.

To set the rights for a folder, right-click the folder in Windows Explorer and select Properties. On the Security tab of the Properties window, select the desired Allow or Deny check boxes in the Permissions window for each user or group in the Name window. Click Apply, then click OK to set the new access rights. Figure 1 shows the \wwwroot folder with permissions for the Administrators group. (Many of the recommendations in this table come from "Secure Internet Information Services 5 Checklist" at http://www.microsoft.com/technet/treeview/default.asp?url=/technet/itsolutions/security/tools/iis5chk.asp.)

Alternatively, you might want to use the IIS 5.0 Permissions Wizard to set access rights. Start Internet Services Manager (ISM) from the Administrative Tools menu. Select the Web site that you want to secure, then click Action, All Tasks, Permissions Wizard. The wizard lets you inherit the security settings of a parent site (if one exists) or select a packaged set of permissions. After you make your selections, the wizard shows you a summary of the changes it will make; click Next, and the wizard applies your security settings in a matter of seconds.

If you plan to enable an FTP server or SMTP services (i.e., Microsoft Outlook Web Access—OWA), you must be especially careful because both have vulnerabilities that subject them to attack. Ideally, you should disable write access to their folders (usually \ftproot and \smtproot, respectively).

However, if you want to give users write access to the FTP and SMTP folders, move them out of the IIS root into a separate folder, preferably on another partition or hard disk. This action minimizes the chance of an intruder breaking one of these services and remotely executing a program by using a service or file in IIS and an exploit such as the ones described in the MS01-023 and MS01-033 bulletins I discussed earlier.

Finally, you should limit access rights to the system log files (usually in the C:\winnt\system32\logfiles folder). Remove any unnecessary access rights, and deny the Everyone group the ability to delete the log files. Limiting access to the log files prevents intruders from easily covering their tracks.

After you set the appropriate rights, the next step is to remove the default sites that come with IIS—because they aren't secure. We're using the default HTTP site in this article, so we'll leave it alone; but in your production environment, you should remove any default FTP and HTTP sites that you aren't using. In ISM, right-click Default Web Site, which Figure 2 shows, then select Action, Delete.

You should also remove any sample code that Win2K installed along with the IIS 5.0 services. Most people don't realize that a broad range of scripts and programs, including sample IIS code, IIS Help files, and sample remote-data-access code, is hiding on their servers and can be exploited by an intruder. The remote-data-access code is particularly dangerous because several known exploits use this code to attack IIS servers. The default location of the IIS sample files is C:\inetput\iissamples, the Help files are in C:\winnt\help\iishelp, and the remote-data-access code is in C:\program files\common files\system\msadc. You can remove all this sample code with no effect on IIS or any other service on the system. (You can choose not to install the sample files during the Win2K installation process. However, if someone else installed Win2K or configured the server, make sure that these files aren't on the system.)

Finally, you should remove the mappings for any application types that your Web site doesn't use. In ISM, right-click the Web site and select Properties. Ensure that WWW Services appears in the Master Properties drop-down list, then click Edit to the right of this box. In the next window, click the Home Directory tab, then click Configuration. In the resulting Application Configuration window, go to the App Mappings tab, which Figure 3 shows. If you don't plan to use remote Internet printing, you can select the .printer entry and click Remove. This action should take care of the MS01-023 vulnerability. Similarly, if you don't use Indexing Service, you can remove the .htw, .ida, and .idq entries to take care of MS01-033. If you don't use Web-based password resets, remove the .htr entry. You might be able to remove other extensions too, depending on the applications you use. Determine which extensions you aren't using and remove all of them.

Performing these steps can greatly increase your IIS 5.0 security, but you can take many more strides toward a secure IIS 5.0 server—certainly more than I can outline in one article. Do some reading—for example, peruse "Secure Internet Information Services 5 Checklist" (http://www.microsoft.com/technet/treeview/default.asp?url=/technet/itsolutions/security/tools/iis5chk.asp) and "Securing IIS on Windows 2000" (http://www.sans.org/infosecfaq/win2000/sec_iis.htm)—and tighten security even further. You can secure IIS 5.0 if you apply appropriate access rights and limit services, keep up on vulnerabilities, and apply security hotfixes as soon as Microsoft releases them.