Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
AQ-2003-02: Microsoft IIS Logging Failure

From: Parcifal Aertssen (parcifalAQTRONIX.COM)
Date: Sat Dec 27 2003 - 17:55:25 CST

AQTRONIX Security Advisory AQ-2003-02

Topic: Microsoft IIS Logging Failure

Release date: 28 December 2003

Affected Systems: IIS 5.0 (previous versions not tested)
Not Affected Systems: IIS 6.0

Category: Failure to log certain activity, information disclosure
          without notice

Vendor URL: http://www.microsoft.com

Author: Parcifal Aertssen

This document (and updates) is available at:


The HTTP protocol consists of requests and responses. Requests are
sent from the clients (browsers) and they always start with a certain
keyword (verb). The most common request is a "GET" request, but there
are many more of these verbs, all of them are well documented within
the RFCs. But one of these verbs that Microsoft uses is not: it's the
"TRACK" request. The TRACK request returns the original request as an
entity (with a content-type of "message/http" and the returned body
contains your original request), just like a TRACE request. The TRACE
request is RFC compliant and well documented, the TRACK request is
not RFC compliant and not documented (only one page mentions this verb
in the MSDN library with no explanation).


Making an HTTP request with the verb TRACK is not being logged. This
makes it quite critical because it can be used to produce a lot of
traffic and to get the 'Server' header and other valuable information.
Furthermore because the TRACK request is the same as a TRACE request,
all known problems with TRACE requests also apply for this verb.
The most important issue with a TRACE request is cross-site
tracing (XST): a malicious web page or e-mail can send a TRACE/TRACK
request to another website (by using client side scripting) and by
analysing the response it can have access to your credentials and
your cookies on that site (think: session hijacking, passwords,...).
All unpatched and future exploits that work with a TRACE request,
should also work with the TRACK request but this time without being
logged, making it ideal for probing vulnerable IIS systems.

IIS 6 is not vulnerable. The IIS team probably found the bug and
removed it silently and didn't care about patching previous
versions of IIS because that's not part of their Trustworthy
Computing Initiative.


You can reproduce the problem using a tool like netcat and send the
following line, followed by two CRLF pairs:

You will see the response from IIS (just like a TRACE request), but
you won't find this in the IIS log files.

Vendor Response

I did not contact Microsoft about this vulnerability, because they
did not acknowledge me for my previous discovery. I found the ASP
Headers DoS (MS03-018) and received a private patch after 2 months.
They decided to release the patch in a cumulative one, even though
they had a patch ready. I thought this was a positive thing, the
less patches, the less work for me too. So I waited another 3 months
and still no word from Microsoft. When almost 6 months had passed,
I decided to go public, because I waited until "Microsoft could fix
the problem before malicious users even knew it existed", as it says
in their policy, they COULD have fixed it. One month later the
cumulative patch was released, but no acknowledgement for me. I told
Microsoft about their mistake and I told them I had other
vulnerabilities waiting, with no results, they simply ignored me.
So I decided to change my policy and release at least one advisory
without reporting anything to them.


Users running AQTRONIX WebKnight are protected from the first day
they installed it, people using Microsoft urlscan should add the
TRACK verb to the DenyVerbs section and make sure it is not in the
AllowVerbs section in the urlscan.ini file.

AQTRONIX WebKnight can be downloaded at:


2003.01.02 Found the vulnerability.
2003.05.29 Decided not to mail it to Microsoft
2003.12.28 Released initial advisory


The information in this advisory and any of its demonstrations is provided
"as is" without warranty of any kind.

AQTRONIX is not liable for any direct or indirect damages caused as a result
of using the information or demonstrations provided in any part of this

Editor's Note: The 43rd Most Powerful Person in Networking says...

Wondering as to whether the list is running? The NTBugtraq archives are updated first before messages are emailed to subscribers. Check the archives first to see if you have missed any messages;