Vulnerabilities : HTTP TRACE Method Enabled

nlopez · 07-02-2009, 02:14 PM

Hi guys,

I recently installed UT for testing. Before we make a decition to put it into production, I decided to run a vulnerability scan with Rapid 7's Nexpose scanner. It turns out that it has one vulnerability which I would like to fix before production.

It is a HTTP TRACE Method Enabled vulnerability.

These are the solutions for Apache

Apache

Disable HTTP TRACE Method for Apache

Newer versions of Apache (1.3.34 and 2.0.55 and later) provide a configuration directive called TraceEnable. To deny TRACE requests, add the following line to the server configuration:

TraceEnable off

TraceEnable offFor older versions of the Apache web server, use the mod_rewrite module to deny the TRACE requests:

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

I tried accessing the console and looked through the file structure; however, I am not able to determine where to make the changes.

Any suggestions?

Evil_Bert · 07-02-2009, 08:15 PM

Don't hold your breath waiting for an answer. Most posts that point out a shortcoming in Untangle just get ignored.

mdh · 07-02-2009, 09:21 PM

Just because they are not publicly responded to within eight hours of having been posted does not mean they are ignored. There's probably an engineer bouncing up and down on his blue ball chair reading this and considering it. A lot of things happen behind the scenes...

sky-knight · 07-02-2009, 10:21 PM

Untangle 6.2 runs on Debian Lenny.

Debian 5.0 (Lenny) configures apache 2 to use /etc/apache2/conf.d as a configuration directory by default. Any files in this directory with an extension of .conf will be executed by the Apache2 service when it loads. Feel free to create your own file in that directory, and make all the adjustments you want.

Also I should point out that this vulnerability appears to only work on the HTTP service. It does not seem to affect the HTTPS service. So this issue exposes only the internal management. I have run nessus scans on all my devices and not seen this issue from the outside.

*update*

An updated NESSUS scan on my internal interface of UT (I've never checked this before) reveals the trace vulnerability specifically on the HTTP service running on port 80. I'll work on a configuration file to deal with the adjustments in the morning. It really shouldn't be that hard to turn the trace feature off. Also, I repeat that this issue is only on the INTERNAL HTTP management only, and doesn't constitute an exterior vulnerability.

Also, if you want to get this picky about it, the DNS server shows a DNS Server Cache Snooping Information Disclosure vulnerability as well.

nlopez · 07-03-2009, 04:00 AM

Thanks sky-knight.

I ran the scan on the external NIC. It could be that the internal NIC was scanned as I have UT bridged.

I have not yet deployed any of the Virtual servers.

sky-knight · 07-04-2009, 11:05 AM

Ok, sorry this took a bit longer than I expected...

The UT server doesn't have mod_rewrite enabled by default. So the "traditional" fix of:

Code:

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

Won't work...

I don't like hacking up my UTs with custom stuff as I know it can break things.

So, I set about a simpler path of creating a disabletrace.conf in /etc/apache2/conf.d and inserting

Code:

TraceEnable off

And restarting apache... that didn't work...

Then I found /etc/apache2/conf.d/security

This file is part of the stock debian lenny installation, when I cracked it open all the way down at the end of the file is the TraceEnable directive, force set to On.

I assume at this point that the files in conf.d are executed in alphabetical order, so my disabletrace.conf was being overridden by the setting in this security file. Also, I was operating under the false assumption that files in this directory needed the .conf extension... it seems whatever file is in here is parsed for configuration data.

Anyway, the security file is the easy fix.

Code:

nano /etc/apache2/conf.d/security

Scroll ALL the way to the bottom, put a # infront of TraceEnable On and remove the # in front of TraceEnable Off.

Then restart apache

Code:

apache2ctl restart

To test, you can use telnet

telnet UTIP 80

Then type in the following EXACTLY and bear in mind there is no echo.

Code:

TRACE / HTTP/1.0

And before you ask.. yes the caps matter.

Press enter twice.

Look at the first line, if traces are enabled you will get:

Code:

HTTP/1.1 200 OK

If they are disabled you will get:

Code:

HTTP/1.1 405 Method Not Allowed

Now, off to figure out why /etc/apache2/ports.conf has that Listen 64157 line...

Devs any particular reason you told apache to bind itself to this arbitrary port?

Oh and some more reading for the insomniacs or the insane.

More reading on the trace method
http://www.ducea.com/2007/10/22/apac...-trace-method/

And a good run down of the configuration files and directories configured by default in Debian.
http://www.ducea.com/2006/06/11/apac...iles-location/

P.S. Trace is a debugging feature of web servers and can be used by the software within Untangle.. this adjustment *may* break your box. I don't know how or why.. but it could. I don't know ruby on rails, nor do I know JSP to go audit the code of UT's web interface to figure it out... and to be point blank... I have no interest in those two technologies.

So I don't expect to EVER learn them.

I do expect this "patch" to "break" on the next "OS upgrade" for UT. Since Debian Squeeze is still in beta, we still have a while yet. And I mean break in that the security file will be overwritten in the upgrade. Given the extra security going into the Apache installation on the next Debian.. (based on the comments in the configuration files) It may just be disabled by default.

Spiral · 07-04-2009, 11:48 AM

Thanks for the insight.

nlopez · 07-04-2009, 03:38 PM

Excellent sky-knight. I appriciate the effort to correct this so quickly. I will run a new scan on the box when I get back to work on Tuesday.

I will keep in mind the break after upgrade.

Thanks again

nlopez · 07-15-2009, 06:25 AM

The scan returned zero results for HTTP Trace after making the changes.

Thanks again Sky-knight

07-02-2009, 02:14 PM	#1 (permalink)
nlopez Untanglit Join Date: Jul 2009 Posts: 13	Vulnerabilities : HTTP TRACE Method Enabled Hi guys, I recently installed UT for testing. Before we make a decition to put it into production, I decided to run a vulnerability scan with Rapid 7's Nexpose scanner. It turns out that it has one vulnerability which I would like to fix before production. It is a HTTP TRACE Method Enabled vulnerability. These are the solutions for Apache Apache Disable HTTP TRACE Method for Apache Newer versions of Apache (1.3.34 and 2.0.55 and later) provide a configuration directive called TraceEnable. To deny TRACE requests, add the following line to the server configuration: TraceEnable off TraceEnable offFor older versions of the Apache web server, use the mod_rewrite module to deny the TRACE requests: RewriteEngine On RewriteCond %{REQUEST_METHOD} ^TRACE RewriteRule .* - [F] I tried accessing the console and looked through the file structure; however, I am not able to determine where to make the changes. Any suggestions? Last edited by nlopez; 07-03-2009 at 04:12 AM..

07-02-2009, 08:15 PM	#2 (permalink)
Evil_Bert Master Untangler Join Date: Nov 2007 Location: Sydney, Australia Posts: 119	Don't hold your breath waiting for an answer. Most posts that point out a shortcoming in Untangle just get ignored. __________________ There are many alternate universes, but only this one has beer.

07-02-2009, 09:21 PM	#3 (permalink)
mdh Join Date: Aug 2007 URLs submitted: 171 Posts: 4,802	Just because they are not publicly responded to within eight hours of having been posted does not mean they are ignored. There's probably an engineer bouncing up and down on his blue ball chair reading this and considering it. A lot of things happen behind the scenes... __________________ This space reserved for profound thought.....which does happen on occasion."

07-02-2009, 10:21 PM	#4 (permalink)
sky-knight Join Date: Apr 2008 Location: Phoenix, AZ URLs submitted: 7 Posts: 9,951	Untangle 6.2 runs on Debian Lenny. Debian 5.0 (Lenny) configures apache 2 to use /etc/apache2/conf.d as a configuration directory by default. Any files in this directory with an extension of .conf will be executed by the Apache2 service when it loads. Feel free to create your own file in that directory, and make all the adjustments you want. Also I should point out that this vulnerability appears to only work on the HTTP service. It does not seem to affect the HTTPS service. So this issue exposes only the internal management. I have run nessus scans on all my devices and not seen this issue from the outside. update An updated NESSUS scan on my internal interface of UT (I've never checked this before) reveals the trace vulnerability specifically on the HTTP service running on port 80. I'll work on a configuration file to deal with the adjustments in the morning. It really shouldn't be that hard to turn the trace feature off. Also, I repeat that this issue is only on the INTERNAL HTTP management only, and doesn't constitute an exterior vulnerability. Also, if you want to get this picky about it, the DNS server shows a DNS Server Cache Snooping Information Disclosure vulnerability as well. __________________ Intouch Technology Rob Sandling, BS:SWE, MCP Office: 480-272-9889 rob@intouchtechllc.com Last edited by sky-knight; 07-02-2009 at 10:45 PM..

07-03-2009, 04:00 AM	#5 (permalink)
nlopez Untanglit Join Date: Jul 2009 Posts: 13	Thanks sky-knight. I ran the scan on the external NIC. It could be that the internal NIC was scanned as I have UT bridged. I have not yet deployed any of the Virtual servers. Last edited by nlopez; 07-03-2009 at 04:15 AM..

07-04-2009, 11:05 AM	#6 (permalink)
sky-knight Join Date: Apr 2008 Location: Phoenix, AZ URLs submitted: 7 Posts: 9,951	Ok, sorry this took a bit longer than I expected... The UT server doesn't have mod_rewrite enabled by default. So the "traditional" fix of: Code: RewriteEngine On RewriteCond %{REQUEST_METHOD} ^TRACE RewriteRule .* - [F] Won't work... I don't like hacking up my UTs with custom stuff as I know it can break things. So, I set about a simpler path of creating a disabletrace.conf in /etc/apache2/conf.d and inserting Code: TraceEnable off And restarting apache... that didn't work... Then I found /etc/apache2/conf.d/security This file is part of the stock debian lenny installation, when I cracked it open all the way down at the end of the file is the TraceEnable directive, force set to On. I assume at this point that the files in conf.d are executed in alphabetical order, so my disabletrace.conf was being overridden by the setting in this security file. Also, I was operating under the false assumption that files in this directory needed the .conf extension... it seems whatever file is in here is parsed for configuration data. Anyway, the security file is the easy fix. Code: nano /etc/apache2/conf.d/security Scroll ALL the way to the bottom, put a # infront of TraceEnable On and remove the # in front of TraceEnable Off. Then restart apache Code: apache2ctl restart To test, you can use telnet telnet UTIP 80 Then type in the following EXACTLY and bear in mind there is no echo. Code: TRACE / HTTP/1.0 And before you ask.. yes the caps matter. Press enter twice. Look at the first line, if traces are enabled you will get: Code: HTTP/1.1 200 OK If they are disabled you will get: Code: HTTP/1.1 405 Method Not Allowed Now, off to figure out why /etc/apache2/ports.conf has that Listen 64157 line... Devs any particular reason you told apache to bind itself to this arbitrary port? Oh and some more reading for the insomniacs or the insane. More reading on the trace method http://www.ducea.com/2007/10/22/apac...-trace-method/ And a good run down of the configuration files and directories configured by default in Debian. http://www.ducea.com/2006/06/11/apac...iles-location/ P.S. Trace is a debugging feature of web servers and can be used by the software within Untangle.. this adjustment may break your box. I don't know how or why.. but it could. I don't know ruby on rails, nor do I know JSP to go audit the code of UT's web interface to figure it out... and to be point blank... I have no interest in those two technologies. So I don't expect to EVER learn them. I do expect this "patch" to "break" on the next "OS upgrade" for UT. Since Debian Squeeze is still in beta, we still have a while yet. And I mean break in that the security file will be overwritten in the upgrade. Given the extra security going into the Apache installation on the next Debian.. (based on the comments in the configuration files) It may just be disabled by default. __________________ Intouch Technology Rob Sandling, BS:SWE, MCP Office: 480-272-9889 rob@intouchtechllc.com Last edited by sky-knight; 07-04-2009 at 11:12 AM..

07-04-2009, 11:48 AM	#7 (permalink)
Spiral Untangler Join Date: May 2008 Posts: 76	Thanks for the insight.

07-04-2009, 03:38 PM	#8 (permalink)
nlopez Untanglit Join Date: Jul 2009 Posts: 13	Excellent sky-knight. I appriciate the effort to correct this so quickly. I will run a new scan on the box when I get back to work on Tuesday. I will keep in mind the break after upgrade. Thanks again

07-15-2009, 06:25 AM	#9 (permalink)
nlopez Untanglit Join Date: Jul 2009 Posts: 13	The scan returned zero results for HTTP Trace after making the changes. Thanks again Sky-knight