Disabling the Trace Method in IIS

UPDATE

Check out the new HOWTO section for an up-to-date version of this post.

I have launched a new section on this site and you can find HOWTO: Disable Trace and Track in IIS there.

IIS6 and (presumably) IIS7 disable the HTTP TRACE method by default but quarter after quarter, the same IIS6 driven sites on my network routinely show up as being vulnerable to the TRACE method. What bugs me about this is that I know that TRACE requests made to the web server fail and I finally figured out why they 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, OPTIONS not only reports that TRACE is available but it also is Allowable, which simply is not the case. So the question becomes whether or not the scanner is actually executing a TRACE or if the scanner is simply executing an OPTIONS request and scraping http response headers when determining if a particular vulnerability exists. Scraping response headers and assuming vulnerabilities based upon the response in those headers is not unheard of with these scanners so it is easy to assume that this is why we keep getting hit with TRACE vulnerabilities.

However, the vulnerability that we are all getting tagged with on our IIS6 sites is not TRACE--it is TRACK. The description of the vulnerability is "Web Site Vulnerable to Trace/Track" and although they do the same type of things, they are different methods. TRACE is part of the HTTP specification--TRACK is not but it is enabled by default on IIS servers. TRACE shows up when you execute an OPTIONS request, TRACK does not. On your IIS 5 and IIS 6 sites, install URLScan (not IIS Lockdown!) and disable the methods there. You can use the script from this article to verify that it is all working once URLScan is installed and loaded. I've done this on all my IIS5 and IIS6 sites and disabled not only TRACE and TRACK but also OPTIONS and they no longer show up as vulnerable with this testing utility.