HOWTO: Disable Trace/Track in IIS
It is not uncommon to see the following low-level vulnerability show up on a PCI Compliance Assessment Scan: Web Server HTTP Trace/Track Method Support Cross-Site Tracing Vulnerability. The wording for this vulnerability can be a little misleading because one can be vulnerable due to TRACE being enabled, because TRACK is enabled, or because both are enabled. Since version 5, IIS has disabled the TRACE method so chances are very good that you are not vulnerable to TRACE if you are running Internet Information Server (IIS). However, TRACK, which is Microsoft's implementation of an HTTP Method that does just about the same thing TRACE does, is enabled within IIS4 and IIS5. If you are running an IIS5 server that shows up with this vulnerability, please understand that you are likely not vulnerable to TRACE--just TRACK. The section below should provide you with information on what you can do to assess whether the threat is real or a false positive. IIS6 and IIS7 reportedly do not have HTTP TRACE or TRACK enabled by default and simple tests confirm it for me.
"False Positive" Assessment
If you web server is listening on port 80, by far the easiest (and universal) way to determine whether it is vulnerable or not is using telnet. Simply open up your telnet application and connect to your web site/web server over port 80, ( telnet <hostname> <port>). If you are using the Microsoft telnet client, be careful because it doesn't echo back what you were typing in. Once you connect, type the following:
TRACE / HTTP/1.0
Press enter twice and if TRACE is enabled, you should see output similar to the following:
HTTP/1.1 200 OK
Date: Tue, 04 Aug 2009 20:17:15 GMT
TRACE / HTTP/1.0
Request and Response over telnet for the HTTP TRACK method is identical, for testing purposes, as it is for TRACE. If you need to test a host that is listening on ssl port 443 (and does not have an HTTP port exposed), use openssl's s_client. Simply type " openssl s_client -connect <hostname:sslport> ". You will connect and then you can enter the above request the same as you would have for the telnet test.
One thing to keep in mind is that if requests to "/" get redirected or met with a 404 error, you might want to send that request along to an image or existing html file. Sending the request along to an ASP page would not necessarily provide you with the information you need because by default, IIS allows only certain HTTP methods for ASP's.
If you use Perl, I put a script together called 'test4trac', which will test a site to see if trace and track are allowable. It can be downloaded from my blog's download page and more information is available at the test4trac information page.
The only supported mechanism in place for remediation is by installing URLScan from Microsoft, (version 2.5 and version 3.1 are still available). The urlscan.ini file included as part of URLScan sets by default a configuration setting "UseAllowVerbs=1". In the [AllowVerbs] section of the ini file, http methods GET, HEAD, and POST are the only ones listed, so simply by installing URLScan, you are protected from TRACE or TRACK.
Most of the time, this is all you need to worry about but if you are running an IIS web site, keep in mind that some user-agents issue an OPTIONS command prior to actually issuing a GET or a POST so you may have to keep an eye on site behavior over some course of time in order to see whether you have inadvertently broken something for your end-users.