« Apache Combined and CombinedIO Logs | Main | Tomcat 6.0.18 is out »

07/29/2008

Disabling the Trace Method in IIS

UPDATE

There is a more current version of this post in the HOWTO section: HOWTO: Disable Trace and Track in IIS

 

IIS6 and (presumably) IIS7 disables the HTTP TRACE method by default but for a while there, the same IIS6 driven sites on my network reported being vulnerable to TRACE/TRACK. It is not unusual at all when a new IIS site goes live to see the following vulnerability show up in a PCI compliance scan:  Web Server HTTP Trace/Track Method Support Cross-Site Tracing Vulnerability.  What bugged me about this is that I knew that TRACE requests made to the web site failed and, after a little investigation and talking it over with some of the security folks, I figured out why they may still show up.

Take a look at this output to one of my test sharepoint servers when I execute a TRACE against it:

===================================
HTTP/1.1 501 Not Implemented
Content-Length: 0
Server: Microsoft-IIS/6.0
MicrosoftOfficeWebServer: 5.0_Pub
etc.
===================================

This is super. Executing a TRACE against the server SHOULD fail. However, if I execute an OPTIONS request against the same server, I get the following output:
===================================
HTTP/1.1 200 OK
Date: %DATE/TIME%
Server: Microsoft-IIS/6.0
MicrosoftOfficeWebServer: 5.0_Pub
etc.
etc.
etc.
etc.
etc.
etc.
Public: OPTIONS, TRACE, GET, HEAD, DELETE, PUT, POST, COPY, MOVE, MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, SEARCH
Allow: OPTIONS, TRACE, GET, HEAD, COPY, PROPFIND, SEARCH, LOCK, UNLOCK
Cache-Control: private
===================================

As you can see, an HTTP OPTIONS request not only reports that TRACE is public but it also is allowable, which simply is not the case since TRACE requests made to the site resulted in a 501-Not Implemented. So, the question becomes whether or not the scanner is actually executing a TRACE request or if the scanner is simply executing an OPTIONS request and scraping http response headers when determining if a particular vulnerability exists.  If your security guys are basing vulnerability assessments based on what is reported back from an OPTIONS request, then they need to try and actually execute a TRACE and TRACK request instead.  Scraping response headers and assuming vulnerabilities based upon the response in those headers is not unheard of with some scanners (and individuals!) so it is easy to assume that this is why we keep seeing these TRACE vulnerabilities.

However, if a pci compliance scan continuously reports that the site could be vulnerable to the TRACE/TRACK cross-site scripting flaw on IIS-driven sites, it is most likely not TRACE that is the problem--it is TRACK.  TRACE is part of the HTTP specification--TRACK is not but it is enabled by default on some versions of IIS.  On your IIS 5 and IIS 6 sites, install URLScan (not IIS Lockdown!) and disable the methods there. You can use the script I wrote from this article to verify that it is all working once URLScan is installed and loaded.

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a01156fbc6fe6970c0115722880e9970b

Listed below are links to weblogs that reference Disabling the Trace Method in IIS:

Comments