By Robert Auger ( rauger (at) spidynamics (dot) com )
SPI Dynamics
Version 1.6
Last Modified: 8/25/2005
[TEXT] size: 8k (MD5 SUM: 12261e1bd161bc85a8563d730e3c6068)
Introduction
One of the most important functions a Web site has is the ability to track who is visiting it, where
they are coming from, and what they are doing. While logs themselves may not always be the most accurate
measurement of what's going on, they do provide a high level overview useful for tracking common user
functions and tasks. There are instances when certain types of data aren't logged such as referrers,
cookies, user agents, and POST data. Logging can also be used to track abnormal behavior including
malicious requests sent by a potential attacker trying to break into your site. These logs can be
extremely valuable in identifying if an attack was successful or not, as well as some of the exact
commands that an attacker may have executed.
While performing a security review of Microsoft Internet Information Server (IIS), I started to explore IIS's logging
capabilities and how they worked. Months earlier I discovered an issue in Sun One Application server
(http://www.spidynamics.com/spilabs/advisories/sun-one.html) that allowed an attacker to evade certain logging functionality by
sending a carefully crafted request. With this in mind, I started looking at IIS to see if it had similar issues. I
discovered that if an attacker sends more then 4,097 characters to any logged field, IIS will substitute the data within that
field with three periods. (I.E., ... )
The Problem
To demonstrate the problem you need access to a tool such as Telnet, or Netcat (http://netcat.sourceforge.net/ ) in order to
send the raw HTTP request. Before sending our evasion request we're going to review how normal traffic appears in an IIS log
file.
Normal Request
GET /?id=80
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
Host: TestServer
Logged Response
2005-08-10 16:35:32 172.16.10.3 - 172.16.10.111 80 GET /Default.asp id=80 200
Mozilla/4.0+(compatible;+MSIE+5.01;+Windows+NT+5.0)
In the example above the query string 'id=80' is logged after the filename. Next we'll send a
request with a query string value totaling over 4,097 characters in an effort to evade logging.
Note: "id=" counts as part of the total length.
Attack Request
GET /?id=<insert 4095 A's>
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
Host: TestServer
Logged Response (IIS 5.0 with default logging)
2005-08-10 17:21:29 172.16.10.3 - 172.16.10.111 80 GET /Default.asp ... 200
Mozilla/4.0+(compatible;+MSIE+5.01;+Windows+NT+5.0)
Logged Response (IIS 6.0 with default logging)
2005-08-10 17:09:54 172.16.10.116 GET /Default.asp ... 80 - 172.16.10.3 Mozilla/4.0+(compatible;+MSIE+5.01;+Windows+NT+5.0)
200 0 0
As you can see IIS didn't log the entire query string, but it was processed. This problem isn't limited to simply the query
string value, but affects every portion of logging that accepts more than 4,097 characters as input including HTTP header
values.
An attacker who wishes to exploit a SQL injection vulnerability for the purpose of stealing customer data will do everything
possible to avoid being noticed. Following is an example request that an attacker may send to evade logging:
GET /?test=<insert 4095 A's>&id=1'+UNION+ALL+SELECT+Names,Address,OrderId,CreditCard+FROM+Orders+where+'1'='1
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
If an attacker can partially evade logging, they may be able to mask a particular vulnerability that may be known or unknown.
How-To Prevent IIS Log Evasion with UrlScan
Disclaimer: This information should be used as a guide. The exact configuration mentioned within this document may not be the
best solution for your environment. The author assumes no responsibility for any damages or losses that may occur.
Microsoft released a security hardening tool for IIS dubbed "UrlScan" allowing server administrators to set various security
lockdown measures including the ability to restrict the size of a user's request. With Urlscan not only can we set request
size restrictions (blocking an attackers attempt to thwart IIS's logging capabilities), but we can also log the entire
request string sent by the attacker for further analysis.
To start, first download UrlScan from (http://www.microsoft.com/downloads/details.aspx?familyid=23d18937-dd7e-4613-9928-7f94ef1c902a&displaylang=en) and configure
it to block long requests. Blocking long requests ensures that the request never reaches the target application, which
thwarts an attacker's attempt to mask the attack against a specific application.
Installation Steps:
1. After downloading Setup.exe from Microsoft's site, double-click it.
2. If, after carefully reviewing the End User License Agreement, you agree to the installation of UrlScan, click "Yes."
3. When you see a pop-up box stating, "UrlScan has been successfully installed", installation is complete.
Two files (UrlScan.ini and UrlScan.dll) will be installed under %windir%\system32\inetsrv\urlscan, which is usually under
C:\WINNT\system32\inetsrv\urlscan on a Windows 2000 server.
Configuration Steps:
1. Go to the directory created by UrlScan (as stated above) and open the UrlScan.ini file.
2. The default setting "MaxQueryString=2048" is an acceptable default that will prevent query strings longer than 2,048
characters from being passed to the application.
3. Configure any other options you may need.
In URLScan 2.5, Microsoft introduced the "LogLongUrls" option that allows logging up to 128k of a request. This option can be
enabled in UrlScan.ini by changing "LogLongUrls=0" to "LogLongUrls=1". By setting this option, you can log any attempts by an
attacker who is trying to exploit this issue. You must restart IIS for this change to take effect.
Conclusions
Microsoft's URLScan is a very useful tool that every IIS administrator should take the time to investigate. This document
outlines steps to harden your system against a specific threat. Documentation on how to enable length restrictions on request
header data can be found at the URLScan homepage (http://www.microsoft.com/technet/security/tools/urlscan.mspx) Readers of
this document are encouraged to explore other configuration options in URLScan to further lock down their machine. Microsoft
confirms that this behavior works as designed. Previous versions of IIS (version 4.0 and below) were not tested for this
vulnerability and may also be affected.
References
UrlScan Information Page:
http://www.microsoft.com/technet/security/tools/urlscan.mspx
UrlScan Download Page:
http://www.microsoft.com/downloads/details.aspx?familyid=23d18937-dd7e-4613-9928-7f94ef1c902a&displaylang=en
Using URLScan on IIS
http://support.microsoft.com/default.aspx?scid=kb;[ln];307608
About the Author
Robert Auger is a Security Engineer for S.P.I. Dynamics (http://www.spidynamics.com) where he is responsible for Web
application security R&D. He is a known expert on Web application security vulnerabilities and exploits and currently runs a
popular Web application security resource Web site http://www.cgisecurity.com. Robert co-founded the Web Application Security
Consortium (WASC) - a group dedicated to developing and promoting "security standards of best practice" for the World Wide
Web - in 2004 where he currently leads the WASC-Articles project. He has also contributed attack signatures to SNORT, an open
source network intrusion detection system (IDS). Robert has served as an expert technical advisor to the media on stories
related to Internet security. Additionally, he writes the "Top Five Vulnerabilities" for Computer Reseller News every month.
The current copy of this document can be here:
http://www.webappsec.org/projects/articles/
Information on the Web Application Security Consortium's Article Guidelines can be found here:
http://www.webappsec.org/projects/articles/guidelines.shtml
A copy of the license for this document can be found here:
http://www.webappsec.org/projects/articles/license.shtml