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.

$ telnet hostname:80

    TRACE / HTTP/1.0
    Host:
    TestA: Hello
    TestB: World

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

$ telnet security.gib.local 80
Trying 192.168.0.107...
Connected to  security.gib.local .
Escape character is '^]'.
TRACE / HTTP/1.0


HTTP/1.1 403 Forbidden
Date: Wed, 25 Jul 2012 20:26:56 GMT
Server: Apache
Connection: close
Content-Type: text/html; charset=iso-8859-1

Forbidden

You don't have permission to access /
on this server.


Connection closed by foreign host.

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  ".  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.

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.   

TraceEnable 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]

##this one work for me Apache 1, be sure put it in the PORT 80 stand 

...
# disable TRACE in the www.example.com virtual host
RewriteEngine On 
RewriteCond %{REQUEST_METHOD} ^TRACE 
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.

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.