Page 1 of 1

Apache cross site tracing vulnerability???

PostPosted: Tue Jan 19, 2010 2:08 pm
by 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

Re: Apache cross site tracing vulnerability???

PostPosted: Wed Jan 20, 2010 12:21 am
by 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.

Re: Apache cross site tracing vulnerability???

PostPosted: Wed Jan 20, 2010 2:33 am
by 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.

Re: Apache cross site tracing vulnerability???

PostPosted: Wed Jan 20, 2010 11:09 am
by 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?

Re: Apache cross site tracing vulnerability???

PostPosted: Thu Jan 21, 2010 6:46 am
by 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.

Re: Apache cross site tracing vulnerability???

PostPosted: Thu Jan 21, 2010 9:27 am
by dingetje
What test tool are you using?

Re: Apache cross site tracing vulnerability???

PostPosted: Thu Jan 21, 2010 11:58 am
by 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 :lol:

Re: Apache cross site tracing vulnerability???

PostPosted: Thu Jan 21, 2010 7:28 pm
by 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

Re: Apache cross site tracing vulnerability???

PostPosted: Fri Jan 22, 2010 3:37 am
by 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 :wink: :wink:

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

Re: Apache cross site tracing vulnerability???

PostPosted: Fri Jan 22, 2010 7:26 pm
by 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 :wink:

Re: Apache cross site tracing vulnerability???

PostPosted: Sat Jan 23, 2010 3:03 am
by Thasaidon
Lightning wrote:even the thought of compiling another version of Apache is not very appealing to me and I suspect Dingetje feels the same way :wink:

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

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 :D

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?

Re: Apache cross site tracing vulnerability???

PostPosted: Sat Jan 23, 2010 12:04 pm
by 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 :wink:

Re: Apache cross site tracing vulnerability???

PostPosted: Sat Jan 23, 2010 2:04 pm
by Thasaidon
Lightning wrote: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 :wink:

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.