Apache cross site tracing vulnerability???

[Thasaidon]

Hi all,

it's been a while since I visited this forum, but my Freesco is purring like a kitten and I only have an odd few moments for myself.

In these few sparse moments I was fooling around with a pentesting tool to check my Freesco services.
One of those tests said the Apache I am running on my Freesco is vulnerable to "Cross Site Tracing".

The web server at "http://172.16.0.254/" is vulnerable to Cross Site Tracing. This vulnerability was found in the request with id 26.
User-agent: w3af.sourceforge.net

http://en.wikipedia.org/wiki/Cross-site_tracing

I did some google-ing and found a "solution" for this vulnerability.
http://www.kb.cert.org/vuls/id/867593

It suggests I use the "TraceEnable Off in Apache, but it doesn't state where.

So here are my questions...
Is my Apache really vulnerable for this exploit?
and just in case... where should this "TraceEnable Off" be configured?

Specs:
Freesco 0.3.8
server: Apache/1.3.27 (Unix) mod_perl/1.27 PHP/4.3.1 mod_mp3/0.39
Apache 1.3.27 Dingetje
Perl 5.6.1 Dingetje
Mysql 3.23.37 Lightning

[Lightning]

I am almost certain that is a compile time option. So if you read that article a bit further it shows this.

Alternatively, use the Apache mod_rewrite module to deny HTTP TRACE requests or to permit only the methods needed to meet site requirements and policy. TRACE requests can be disabled with the following mod_rewrite syntax:

RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^TRACE
RewriteRule .* - [F]

I suspect all you need to add is these lines from the example above. Also make sure that the rewrite module is being loaded in the modules section of the httpd.conf (it is by default). So make the change and let us know the results.

On my own system I have over a page of existing RewriteCond lines, but I don't remember where I got them at this point.

[Thasaidon]

Lightning,

thanx for the reply.
I read the part about the "Rewrite", but I wasn't sure this was enabled and the article suggested to go for the "adding the TraceEnable Off".

Anyway, the rewrite module is loaded according to the httpd.conf in /usr/local/apache/conf.

Code: Select all

LoadModule rewrite_module     libexec/mod_rewrite.so

So I added this bit of script in the httpd.conf

Code: Select all

#
# mod_rewrite to prevent "Cross Site Tracing"
#
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{REQUEST_METHOD} ^TRACE
    RewriteRule .* - [F]
</IfModule>

And restarted Apache, which came back without errors.

I can't test it until I get home, because I ran the pentest from my private Linux laptop.
But I'll let you know.

[Thasaidon]

Well, adding the script like stated above didn't do the trick.
I even rebooted my Freesco to make sure, but w3af still reports it's there.

Code: Select all

[Wed 20 Jan 2010 04:38:33 PM CET] The web server at "http://172.16.0.254/" is vulnerable to Cross Site Tracing. This vulnerability was found in the request with id 61.

TRACE http://172.16.0.254/ HTTP/1.1
Host: 172.16.0.254
Accept-encoding: identity
Accept: */*
User-agent: w3af.sourceforge.net

When I request the Apache status all seems fine, and the changes I made are still in the httpd.conf.

Code: Select all

apache configtest
Syntax OK

I've been googling for a while now, but can't seem to find an answer.
So what am I doing wrong here?

[Thasaidon]

Well, I've been at it for every spare minute I had.

I've tried...

Code: Select all

<Directory />
RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^TRACE
RewriteRule .* - [F]
</Directory>

and

Code: Select all

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{REQUEST_METHOD} ^TRACE
    RewriteRule .* - [F]
</IfModule>

and even just plain

Code: Select all

    RewriteEngine On
    RewriteCond %{REQUEST_METHOD} ^TRACE
    RewriteRule .* - [F]

And I've tried it in various places in my httpd.conf. At the start, bottom and other places.
But each time I restarted Apache (or the machine) it didn't work.

[dingetje]

What test tool are you using?

[Thasaidon]

I'm using w3af (w3af.sourceforge.net) on my Ubuntu 9.10 laptop.
w3af is a Web Application Attack and Audit Framework.

But I also tested from the commandline with a telnet to Freesco on port 80 and then using the "trace" command.

Code: Select all

telnet 127.0.0.1 80
TRACE / HTTP/1.1
Host: 127.0.0.1
testing123
testing123

which gives this output.

Code: Select all

HTTP/1.1 400 Bad Request
Date: Sat, 23 Jan 2010 12:35:08 GMT
Server: Apache/1.3.27 (Unix) mod_perl/1.27 PHP/4.3.1 mod_mp3/0.39
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1

173
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>400 Bad Request</TITLE>
</HEAD><BODY>
<H1>Bad Request</H1>
Your browser sent a request that this server could not understand.<P>
Request header field is missing colon separator.<P>
<PRE>
testing123</PRE>     <<<<<----- If this is returned, you have the vulnerability.
<P>
<HR>
<ADDRESS>Apache/1.3.27 Server at thasaidon.homeip.net Port 80</ADDRESS>
</BODY></HTML>

0

Connection closed by foreign host.

Personally I'm not all that worried about the vulnerability, but I figured this should have been a quick fix...
Guess I was wrong

[Lightning]

I have seen no other suggestions on how to fix this problem, however I did run across this quote that may make you feel better about it all together.

Actually, Apache says it is not a vulnerability, and TRACE cannot be disabled
except in the source code.
-----
No, because it is not a vulnerability. White Hat's claims are bogus
and have been rejected by every author of the HTTP standard, along
with several reviewers on bugtraq.

Removing TRACE does not in any way reduce exposure to cross-site
scripting bugs in clients since there are other ways to get access
to that information even if the server has disabled TRACE.
In any case, a site that does not use cookie-based authentication
is not vulnerable to cross-site scripting, and those that do are
only vulnerable to this particular issue for an MSIE browser that
has not been patched and is improperly configured to use the
deprecated HTTP-only scripting option. All other browsers are
no more "vulnerable" with or without TRACE.

The worst solution to this problem would be to run around and
turn off TRACE on all httpd servers -- a feature of HTTP that
depends on it being enabled by default. If you must disable it,
then you will have to edit the code directly. We might add a
directive to disable it in the future for performance reasons.

Cheers,

Roy T. Fielding, co-founder, The Apache Software Foundation

[Thasaidon]

Yup,

I read the Whitehats whitepaper too. And like I said, I'm not too worried about this "vulnerability".
I just thought I'd give it the quick fix because "just adding 3 lines of code", seemed so simple.

The only option would be to upgrade to an Apache version of 1.3.34 or higher, in which the code "TraceEnable off" could be inserted.
But then again... there is no guarantee this would work that simple too

I'll give it a rest... for now
Unless you have some other ideas

[Lightning]

Unless you have some other ideas

Nope I do not and even the thought of compiling another version of Apache is not very appealing to me and I suspect Dingetje feels the same way

[Thasaidon]

even the thought of compiling another version of Apache is not very appealing to me and I suspect Dingetje feels the same way

LoL, well I think you are already doing a great job on Freesco as it is so no complaints from me

The only question I have left is this...
In my search of getting this to work, I've been looking into Apache's log files and I noticed some are quite large (around 1Gb)
This is probably because some even contain log's from 2008

I always thought this line in CRON would remove all logs older than 7 days, including Apache logs...

Code: Select all

# To remove saved logs that are more than 7 days old.
0 0 * * *Irmlogs 7 >/dev/null 2>&1

So now I'm thinking of creating a CRON entry to delete Apache logs once in a while.

Code: Select all

#Delete Apache logs every 1st of the month at 00:05am
#5 0 1 * *Irm /usr/local/apache/logs/*.*

(the I between * and rm is a TAB)

Can I just delete the files or do I need to stop the webservice first?

[Lightning]

You actually are supposed to stop Apache before rotating or removing logs. As I recall Dingetje has some sort of log rotate/delete script for Apache running on his own system. So maybe he will post the script if my memory is correct

[Thasaidon]

You actually are supposed to stop Apache before rotating or removing logs. As I recall Dingetje has some sort of log rotate/delete script for Apache running on his own system. So maybe he will post the script if my memory is correct

Mmm... sounds interesting
why does "log rotate" sound so familiar?

I found a piece on rotatelogs, http://httpd.apache.org/docs/1.3/programs/rotatelogs.html, but I'm not sure if the logs are actually replaced by new ones (clearing the old), or if it's just a new log file which is beeing created, next to the old one.
Also, some log code with a statement like "common" at the end, don't seem to work with this.