Preventing Log Evasion SQL Injection in IIS

Preventing Log Evasion SQL Injection in IIS

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=
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=&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