Openfire and http TRACE method

Openfire Openfire Support
1

A system that I’'d configured using Wildfire 3.2.2 got nailed as having a mid level vulnerability on port 9090 because of a “Multiple Vendors Web Servers HTTP TRACE Method Vulnerability”.

The details:

The “TRACE” method is that responses clients’’ request messages from server to the clients such “echo.” If this method is successfully abused, the authentication information such as basic authentication for HTTP is possibly able to be sniffed.

How do I make this go away using Openfire/Wildfire?

Grant

2

Do you have a link where all the details of the vulnerability can be found so we can investigate?

Thanks,

Alex

3

Here’‘s the output that was forwarded to me. If possible I’'d like to remove this alert but it rated a B which I can get to slide by.

Grant

Inspection Type

Vulnerability Name

Multiple Vendors Web Servers HTTP TRACE Method Vulnerability

Outline

There is a possibility of information leak. The “TRACE”

method is that responses clients’’ request messages from server to

the clients such “echo.” If this method is successfully

abused, the authentication information such as basic

authentication for HTTP is possibly able to be sniffed.

Impact

There is no problem on the HTTP TRACE Method itself. However,

this method possibly causes information leak of HTTP header such

as basic authentication by a request of the TRACE method if the

Web site has a cross-site scripting vulnerability.

Countermeasures

It is able to avoid this issue by voiding the TRACE method. It

is necessary to re-integrate the server software to void. In case

of using Apache, the optional module, which is mod_rewrite, and In

case of IIS, URLScan, which is in the IIS Lockdown tool, controls

the TRACE method. This countermeasure is one of the risks of the

server management workload so that please consider the necessity

before taking the re-integrating action.

Inspection Type

Note

http://www.kb.cert.org/vuls/id/867593

http://www.cgisecurity.com/whitehat-mirror/WH-WhitePaper_XST_ebook.pdf

http://www.atmarkit.co.jp/fsecurity/rensai/webhole04/webhole01.html

Inspection Type

Additional Information

Port9090

HTTP/1.1 200 OK

Expires: Thu, 01 Jan 1970

00:00:00 GMT

Set-Cookie:

JSESSIONID=1h43cam3g7nac;path=/

Content-Type:

message/http

Content-Length: 49

TRACE / HTTP/1.1

Host:

foo.bar

X-Header: test

4

I’‘ve since locked port 9090 and am using only 9091 but I’'m not sure that actually makes any difference because it would seem that that webserver would respond the same.

Grant

5

Hi Grant,

I see no problem that you get back the header you did send. Of course you send the username and the password when you login within the HTTP header, and you send the cookie every time.

http://www.kb.cert.org/vuls/id/867593 describes the problem with XST vulnerable browsers like IE6. I wonder if every HTTP server vendor should disable this method just because one company releases bogus browsers.

The right solution is imho to use a non-vulnerable browser as you have this problem with every web server you access. Or you close IE before accessing the Openfire web admin console and access only it.

LG

6

There are real problems and there are supposed problems. Unfortunately in the corporate world they are one and the same. I’‘ve had to create new rpms for openssh 4.6p1 because this scanner nailed the 4.3p2 in RHEL5 as being vulnerable. One more hit like that and the company pays big bucks. The http TRACE item is only a B whereas the openssh hit was a D which gets the whole corporation buzzing. I realize that there wasn’‘t really any problem with openssh as it’‘s been patched but it doesn’‘t matter. One of the largest corporations in the world (Japanese) scans it’‘s subsideraries and nailed us on these points. If we can’‘t fix them we’'re labeled as an insecure network and insurance goes through the roof.

All of it is sillyness but it’‘s very real to the President and the VPs of the corporation. I will be able to make the rest of the hits go away although I’‘m not REALLY making the boxes more secure but I figured if I can do something about the TRACE method then I would. The lame solution would be to put Apache in front of Openfire and proxy traffic to it and set up mod_rewrite to drop the TRACE method but I thought I’‘d bring it up here just to see if there’‘s an easier solution or possibly this is something that the developers hadn’'t looked into.

Grant

7

Hi Grant,

within servlets one can overwrite the existing doTrace() method and call doGet() or something else instead. Some plugins use servlets, so one could patch them.

I have anyhow no idea about the JSP pages Openfire uses.

LG