Home    |    View Topics    |    Search    |    Contact Us    |   



Category:   Application (Web Server/CGI)  >   Microsoft Internet Information Server (IIS) Web Server Vendors:   Microsoft
Microsoft IIS Fails to Log HTTP TRACK Requests
SecurityTracker Alert ID:  1008563
SecurityTracker URL:
CVE Reference:   GENERIC-MAP-NOMATCH   (Links to External Site)
Date:  Dec 28 2003
Impact:   Modification of system information
Exploit Included:  Yes  
Version(s): 5.0
Description:   A logging vulnerability was reported in Microsoft Internet Information Server. A type of remote request is not logged.

AQTRONIX reported that the server does not log HTTP 'TRACK' requests. As a demonstration exploit, you can reportedly connect to the target server and send the following text followed by two carriage return/line feed sequences:


The report indicates that IIS version 6 is not vulnerable.

Impact:   A remote user can make an HTTP TRACK request to obtain information about the server without the request being logged.
Solution:   No solution was available at the time of this entry.
Vendor URL: (Links to External Site)
Cause:   State error
Underlying OS:  Windows (Any)

Message History:   None.

 Source Message Contents

Subject:  AQ-2003-02: Microsoft IIS Logging Failure

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:

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;



Go to the Top of This SecurityTracker Archive Page

Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2019, LLC