We've contracted with IBM to perform some threat analysis of our network.
We get these qualsys reports of our vulnerabilities. They were analyzing
our domino based quickr server running on i.
One vulnerability is Web Server HTTP Trace/Track Method Support Cross-Site
Tracing Vulnerability.
Is this something we should be concerned about? Why? What should we do
about it?
As I read it below, it sounds like http specs require this, and most
common web servers have this vulnerability.
Details of threat are as follows:
Level 2 Web Server HTTP Trace/Track Method Support Cross-Site Tracing
Vulnerability port 80/tcp
QID: 86473
Category: Web server
CVE ID: CVE-2004-2320, CVE-2007-3008
Vendor Reference: -
Bugtraq ID: -
Service Modified: 11/19/2008
User Modified: -
Edited: No
THREAT:
A Web server was detected that supports the HTTP TRACE method. This method
allows debugging and connection trace analysis for connections
from the client to the Web server. Per the HTTP specification, when this
method is used, the Web server echoes back the information sent to it by
the client unmodified and unfiltered. Microsoft IIS web server uses an
alias TRACK for this method, and is functionally the same.
A vulnerability related to this method was discovered. A malicious, active
component in a Web page can send Trace requests to a Web server that
supports this Trace method. Usually, browser security disallows access to
Web sites outside of the present site's domain. Although unlikely and
difficult to achieve, it's possible, in the presence of other browser
vulnerabilities, for the active HTML content to make external requests to
arbitrary
Web servers beyond the hosting Web server. Since the chosen Web server
then echoes back the client request unfiltered, the response also
includes cookie-based or Web-based (if logged on) authentication
credentials that the browser automatically sent to the specified Web
application on
the specified Web server.
The significance of the Trace capability in this vulnerability is that the
active component in the page visited by the victim user has no direct
access to
this authentication information, but gets it after the target Web server
echoes it back as its Trace response.
Since this vulnerability exists as a support for a method required by the
HTTP protocol specification, most common Web servers are vulnerable.
The exact method(s) supported, Trace and/or Track, and their responses are
in the Results section below.
IMPACT:
If this vulnerability is successfully exploited, users of the Web server
may lose their authentication credentials for the server and/or for the
Web
applications hosted by the server to an attacker. This may be the case
even if the Web applications are not vulnerable to cross site scripting
attacks
due to input validation errors.
SOLUTION:
Solutions for some of the common Web servers are supplied below. For other
Web servers, please check your vendor's documentation.
Apache: Recent Apache versions have a Rewrite module that allows HTTP
requests to be rewritten or handled in a specific way. Compile the
Apache server with the mod_rewrite module. You might need to uncomment the
'AddModule' and 'LoadModule' directives in the httpd.conf
configuration file. Add the following lines for each virtualhost in your
configuration file (Please note that, by default, Rewrite configurations
are not
inherited. This means that you need to have Rewrite directives for each
virtual host in which you wish to use it):
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^TRACE
RewriteRule .* - [F]
</IfModule>
With this configuration, Apache catches all TRACE requests, and replies
with a page reporting the request as forbidden. None of the original
request's contents are echoed back.
A slightly tighter fix is to use:
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_METHOD} !^(GET|POST|HEAD)$
RewriteRule .* - [F]
</IfModule>
Please note that RewriteEngine can be processor intensive and may impact
the web server performance. The trace method can also be controlled
by use of the TraceEnable directive.
In the httpd.conf add or modify:
TraceEnable Off
Microsoft IIS: Microsoft released URLScan (
http://www.microsoft.com/windows2000/downloads/recommended/urlscan/default.asp
), which can be
used to screen all incoming requests based on customized rulesets. URLScan
can be used to sanitize or disable the TRACE requests from the
clients. Note that IIS aliases 'TRACK' to 'TRACE'. Therefore, if URLScan
is used to specfically block the TRACE method, the TRACK method should
also be added to the filter.
URLScan uses the 'urlscan.ini' configuration file, usually in
\System32\InetSrv\URLScan directory. In that, we have two sections -
AllowVerbs and
DenyVerbs. The former is used if the UseAllowVerbs variable is set to 1,
else (if its set to 0), the DenyVerbs are used. Clearly, either can be
used,
depending on whether we want a Default-Deny-Explicit-Allow or a
Default-Allow-Explicit-Deny policy. To disallow TRACE and TRACK methods
through URLScan, first remove 'TRACK', 'TRACE' methods from the
'AllowVerbs' section and add them to the 'DenyVerbs' section. With this,
URLScan will disallow all 'TRACE' and 'TRACK' methods, and generate an
error page for all requests using that method. To enable the changes,
restart the 'World Wide Web Publishing Service' from the 'Services'
Control Panel item.
Sun ONE/iPlanet Web Server: Here are the sun recommandations to disable
the trace method
(
http://sunsolve.sun.com/search/document.do?assetkey=1-26-50603-1).
For more details about other web servers : Cert Advisory (
http://www.kb.cert.org/vuls/id/867593).
COMPLIANCE:
Not Applicable
EXPLOITABILITY:
There is no exploitability information for this vulnerability.
ASSOCIATED MALWARE:
There is no malware information for this vulnerability.
RESULTS:
TRACE / HTTP/1.1
Host: xqp02.dekko.com
Via: <script>alert('QualysXSS');</script>
HTTP/1.1 200 OK
Server: Lotus-Domino
Date: Wed, 16 Feb 2011 04:22:42 GMT
Connection: close
Pragma: no-cache
Cache-Control: no-cache
Expires: Wed, 16 Feb 2011 04:22:42 GMT
Content-Type: message/http
Content-Length: 84
TRACE / HTTP/1.1
Host: xqp02.dekko.com
Via: <script>alert('QualysXSS');</script>
TRACE / HTTP/1.0
Via: <script>alert('QualysXSS');</script>
HTTP/1.1 200 OK
Server: Lotus-Domino
Date: Wed, 16 Feb 2011 04:22:42 GMT
Connection: close
Pragma: no-cache
Cache-Control: no-cache
Expires: Wed, 16 Feb 2011 04:22:42 GMT
Content-Type: message/http
Content-Length: 61
TRACE / HTTP/1.0
Via: <script>alert('QualysXSS');</script>
Rob Berendt
midrange.com
