Preventing Log Evasion in IIS
By Robert Auger ( rauger (at) spidynamics (dot) com )
SPI Dynamics Inc

Document Version: 1.6
Last Modified: August 26th, 2005

 
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 found at:
http://www.webappsec.org/articles/

Information on the Web Application Security Consortium's (WASC) Article Guidelines can be found at:
http://www.webappsec.org/articles.html

A copy of the license for this document can be found at:
http://www.webappsec.org/license.html