[Dshield] FW: Microsoft IIS Logging Failure

YevetteM yevettem at gsmt.com
Mon Dec 29 19:38:53 GMT 2003

I am forwarding this from the NTBugtraq list incase anyone missed it.

 -----Original Message-----

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;



More information about the list mailing list