Default Settings Lead to Insecure IIS Servers

Last week, security guru rain.forest.puppy (RFP) disclosed another major hole in IIS that lets malicious users submit encapsulated DOS commands inside a malformed URL to IIS 5.0 and IIS 4.0 servers. The result is that anyone could use DOS commands, such as DIR COPY and DEL, as long as the Anonymous user account had permission.

If you used the defaults, some OSs were visible to malicious users who used this exploit. Anything your Anonymous account (typically IUSR_yourservername) could access was open to this exploit. However, if you followed the Microsoft IIS Security Checklist and set the file permissions on your IIS server accordingly, you were much less vulnerable. Let me wave the security banner for a moment. Anything you install with the default settings is more than likely not secure, which also goes for security products such as firewalls.

I don't have enough room to cover everything in the checklists. However, you should pay special attention to a few items, such as Bypass Traverse Directory Checking. In both Windows 2000 and Windows NT 4.0, by default this setting is set to Everyone. I remove all users from this group and follow the recommendations for setting more conservative file permissions. I also strongly suggest that you look at the permissions assigned to your IIS server, OS directories, and your Web folders. This task isn't easy on an existing server, but it's a snap on a new installation. Both the IIS 5.0 and IIS 4.0 checklists suggest how best to implement ACLs on your IIS servers.

These two actions alone would have minimized some of the impact of RFP's discovery. He released details about the exploit shortly after Microsoft released the patch, so you might see attempts on your Web server shortly, if you haven't already.

Without introducing my feelings about full disclosure, I think that because RFP released the exploit so quickly after Microsoft released the bulletin, many administrators accelerated deployment of the patch—more quickly than good business practice dictates. In my environment, I heard about two IIS-based applications crashing IIS as a result of the patch. Was the time spent reinstalling those two applications worth the risk of being exploited? In my case, it was.