[NT] Microsoft IIS Logging Failure
From: SecuriTeam (support_at_securiteam.com)
Date: 01/07/04
- Previous message: SecuriTeam: "[NEWS] Multiple Payload Handling Flaws in ISAKMPd (Continued)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
To: list@securiteam.com Date: 7 Jan 2004 18:07:34 +0200
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
The SecuriTeam alerts list - Free, Accurate, Independent.
Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html
- - - - - - - - -
Microsoft IIS Logging Failure
------------------------------------------------------------------------
SUMMARY
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.
However, one of these verbs that Microsoft uses is not: it is 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). This request is not logged by the IIS server allowing
attacks using this request to go unnoticed.
DETAILS
Vulnerable systems:
* IIS version 5.0 and prior
Immune systems:
* IIS version 6.0
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 analyzing the response it can have access to
your credentials and your cookies on that site (think: session hijacking,
passwords,...). All un-patched 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.
Exploit:
You can reproduce the problem using a tool like netcat and send the
following line, followed by two CRLF pairs: TRACK / HTTP/1.0
You will see the response from IIS (just like a TRACE request), but you
will not find this in the IIS log files.
Vendor timeline:
2003.01.02 Found the vulnerability
2003.05.29 Decided not to mail it to Microsoft
2003.12.28 Released initial advisory
ADDITIONAL INFORMATION
The original advisory is available at:
<http://www.aqtronix.com/Advisories/AQ-2003-02.txt>
http://www.aqtronix.com/Advisories/AQ-2003-02.txt.
The information has been provided by <mailto:parcifal@aqtronix.com>
Parcifal Aertssen.
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.
- Previous message: SecuriTeam: "[NEWS] Multiple Payload Handling Flaws in ISAKMPd (Continued)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
- [NEWS] McAfee ePolicy Orchestrator Remote Compromise
... The following security advisory is sent to the securiteam mailing list, and can be
found at the SecuriTeam web site: http://www.securiteam.com ... request, UUID, and computer
hostname. ... The data that follows first specifies a directory and xml filename, ...
+06h DWORD file offset of XML ... (Securiteam) - [EXPL] Windows 2000 Server UPNP DoS (Exploit)
... The following security advisory is sent to the securiteam mailing list, and can be
found at the SecuriTeam web site: http://www.securiteam.com ... A memory leak with windows
2000 server UPNP allow attackers to exploit ... The earlier one trashed the EIP of the target
... * Strangely though changing the operation number in the DCERPC request to ...
(Securiteam) - [NEWS] Dedicated Mobile Services Carry Out Anonymous Web Attacks
... The following security advisory is sent to the securiteam mailing list, and can be
found at the SecuriTeam web site: http://www.securiteam.com ... to anonymously browse web resources
and execute attacks against them. ... An attacker can take advantage of the Google's WMLProxy
Service by sending ... a HTTP GET request with carefully modified URL of a malicious
nature. ... (Securiteam) - [NT] eZ Multiple Packages Stack Overflow Vulnerability
... The following security advisory is sent to the securiteam mailing list, and can be
found at the SecuriTeam web site: http://www.securiteam.com ... A stack-based buffer overflow
problem seems ... to arise when an overly long request is made to the server, ...
saved data which we can overwrite. ... (Securiteam) - [UNIX] Apache HTTP Server 413 Error Page XSS
... The following security advisory is sent to the securiteam mailing list, and can be
found at the SecuriTeam web site: http://www.securiteam.com ... Apache HTTP Server 413
Error Page XSS ... Apache 2.X returns a '413 Request Entity Too Large' error, ...
(Securiteam)