Web Server HTTP Trace Method Support Cross Site Tracing Vulnerability
- From: "Bailey, Matthew" <MBailey@xxxxxxxxxxx>
- To: <isalist@xxxxxxxxxxxxx>
- Date: Wed, 1 Oct 2003 08:22:50 -0700
We are in the process of assessing any vulnerabilities on our external
facing interfaces. I currently have OWA published through our ISA
server and a scan of the external IP reveals the follow vulnerability:
Web Server HTTP Trace Method Support Cross Site Tracing Vulnerability
Details:
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.
Solution for IIS:
Microsoft IIS: Microsoft released URLScan, 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.
So, I have run URLScan on the server that is running OWA with the
settings recommended by the above article and the settings recommended
by MS for an OWA server. However, it didn't close the vulnerability. I
am wondering if the actual vulnerability is from the ISA server since
OWA is published through it.
Here are my questions:
Is it possible that the vulnerability is on ISA and NOT on OWA?
Can I run URLScan on the ISA server? And will it have any actual effect
since IIS isn't even running. Will it break ISA?
This is driving me nuts and any help would be appreciated,
- Matt
Matthew Bailey
LAN Engineer
CSK Auto, Inc.
Voice: 602.631.7486
Fax: 602.294.7486
Other related posts:
