Disable Trace/Track in Apache HTTPD

Very recent effort to address Security/Vulnerability Violations as noted by our security team scans.

Disable Trace/Track in Apache HTTPD

Introduction

Disabling TRACE and TRACK in Apache for PCI-related vulnerabilities like Web Server HTTP Trace/Track Method Support Cross-Site Tracing Vulnerability is surprisingly quite easy with the Apache web server.  The main thing to keep in mind is understanding that if you are running apache and this vulnerability pops up during a scan, you can be reasonably certain that TRACK is not the problem—TRACE is.

The HTTP TRACK method is something Microsoft cooked up that performs essentially the same thing that TRACE does with the exception that it never got used—except by penetration testers, hackers, worms, and vulnerability scanners.

Validation Steps

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

    Host: <hostname_you_are_testing>

    TestA: Hello

    TestB: World

Press enter twice and if trace is enabled, you should see output similar to the following:

    HTTP/1.1 200 OK

    Server: Apache

    Date: Tue, 04 Aug 2009 20:17:15 GMT

    Content-Type: message/http

    Content-Length: 76

   

    TRACE / HTTP/1.0

    Host: <hostname_you_are_testing>

    TestA: Hello

    TestB: World

Request and Response over telnet for the HTTP TRACK method is identical, for testing purposes, as it is for TRACE.  Simply subsitute TRACK 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 for telnet.

If you use Perl, I did 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.

Remediation

TRACE is enabled by default in an apache installation.  There are two ways to remediate.  The first can be used if you are running Apache 1.3.34, 2.0.55, or anything in the 2.2 release.  Simply add the TraceEnable directive into your httpd.conf and set the value to Off.  

The second mechanism involves creating a mod_rewrite rule that will disable http methods, which is also quite popular and works with ANY version of apache that supports mod_rewrite.  The directives below would need to be set, which are written assuming that this is the first time use for mod_rewrite.

The first thing to do is make sure that mod_rewrite is loaded.  If mod_rewrite.so is missing from your apache configuration but you have it installed, (and your install location is /usr/local/apache), then add the following statement to your httpd.conf:

    LoadModule  rewrite_module  "/usr/local/apache/modules/mod_rewrite.so"

Then add the following as well to your httpd.conf file:

    RewriteEngine On

    RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)

    RewriteRule .* - [F]

Restart apache, re-run the steps in the Validation section, and with either method, you should receive an HTTP 405-Method Not Allowed status code back.

Note:

I've seen a lot of posts in forums from people that are attempting to validate TRACE is enabled by issuing an HTTP OPTIONS request against a target web server.  This is not a valid test because HTTP OPTIONS reports back the methods that a particular web server may support and not necessarily the HTTP methods that are enabled on a site.  Even disabling the TRACE method will not remove TRACE from the Supported Methods line in an OPTIONS request, so if you see or hear of anyone telling you that you can validate by issuing an OPTIONS call, they are incorrect