Evading Detection

Not all web platform issues necessarily give rise to direct attacks. Log evasion is a good example of a web platform vulnerability that creates no direct path to breaking into a web server but instead obscures detection of the attacker. Next, we'll present two examples of such issues that allow an attacker to bypass the correct logging of their requests .

Log Evasion Using Long URLs

Popularity:	3
Simplicity:	1
Impact:	5
Risk Rating:	3

 Attack    Some web server software fails to log URI data beyond a certain number of characters. For example, Sun-One Application Server only logs the first 4,042 characters of a request URI. Microsoft's IIS has the same issue when a query string or header value is over 4,097 characters . This was done to prevent DoS attacks by attackers flooding the logs, but attackers have now used this feature for their own benefit. Let's look at the IIS example in more detail to illustrate how this feature can be used by attackers to hide their presence in the web logs.

When writing to the web logs, IIS will automatically truncate the query string to '...' when the length exceeds 4,097 characters. This allows an attacker to create a fake query that is filled with 4,097 characters with an attack appended at the end. The web server will still process the request properly and discards the fake parameter, allowing the attack to succeed, but it will not log the request.

Let's look at a specific example of using log evasion to hide a SQL injection attack against IIS. This kind of an attack is easily noticeable in the web logs if the attack is executed via the query string, as shown in the following example.

 GET /article.asp?id=convert(int,(select+top+1+name+from+sysobjects+ where+xtype='u')) HTTP/1.0 Connection: Close Host: www.site.com User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322) 

The web server responds as normal, and this is what the log entry looks like:

 2005-10-04 22:10:24 127.0.0.1 - 127.0.0.1 80 GET /product_detail.asp id=  convert(int,(select+top+1+name+from+sysobjects+where+xtype='u'))  17080040e07 [Microsoft][ODBC_SQL_Server_Driver][SQL_Server]Syntax_error_ converting_the_nvar char_value_'tbl_Globals'_to_a_column_of_data_type_int. 500 4910 561 Mozilla/5.0+(Windows;+U;+Windows+NT+5.1;+enUS;+rv:1.7.10)+Gecko/ 20050716+Firefox/1.0.6 

We can clearly see from the bolded text in this example the SQL injection attack occurring and the database error that was returned in the response. It's quite easy at this point to identify someone attempting SQL injection on the application by parsing the IIS logs for either any SQL database errors going back to the user or any SQL keywords being used in the request.

Let's now look at the same request, hidden inside a long URI designed to evade detection in the IIS logs. We'll use the same attack request but with a fake parameter of 'foo' being used to fill the log buffer:

 GET /product_detail.asp?id=convert(int,(select+top+1+name+from+ sysobjects+where+xtyp e='u'))&  foo=<4097 a's>  HTTP/1.0 Host: localhost User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0) 

Since the 'foo' parameter is fake, the web application ignores it and the attack executes successfully. The log file logs the following request:

 2005-10-04 22:31:01 127.0.0.1 - 127.0.0.1 80 GET /product_detail.asp  ...  500 4965 4287 Mozilla/4.0+(compatible;+MSIE+5.01;+Windows+NT+5.0) - - 

Notice how the query string has now been replaced with '...' and no error text from the response is logged. The attacker can proceed with any similar parameter mischief without any logging.

Hiding Requests Using TRACK

Popularity:	3
Simplicity:	1
Impact:	5
Risk Rating:	3

 Attack    TRACK is an HTTP method supported only by IIS that does exactly the same thing as the TRACE method. The response to a TRACK request is a repeat of the request sent. For example:

 TRACK / HTTP/1.1 Host: www.site.com User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)     HTTP/1.1 200 OK Server: Microsoft-IIS/5.x Date: Tue, 04 Oct 2005 23:07:12 GMT X-Powered-By: ASP.NET Content-Type: message/http Content-Length: 102     TRACK / HTTP/1.1 Host: www.site.com User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0) 

In Microsoft IIS 5.x, all TRACK requests are not logged by the web server. This request by itself is not very dangerous and cannot be used to retrieve pages or submit attacks, but it can be used in DoS attacks.

We recently experienced the use of TRACK personally when called to investigate some unusual behavior on a client's web server. The CPU was high and the machine responded sluggishly. After throwing up a sniffer on the network, we noticed that although HTTP traffic was extremely high, the web logs contained no record of many of the requests visible via the sniffer. After taking a closer look at the web requests using the sniffer, we noticed a lot of TRACK /<long URL> HTTP/1.0 requests hitting the server that simply were not being recorded in the logs.

Note 

TRACK requests are also a crafty way to DoS a web server without filling up the logs. See Chapter 12 for more web DoS attacks.

IIS Log Evasion Countermeasure

 Countermeasure    A good solution is to use URLScan to prevent these issues. By default, when URLScan is installed there is a setting of MaxQueryString=2048. This will stop the long URL evasion method effectively. In URLScan 2.5, there is an option called LogLongUrls. By turning this option on, URLScan will log up to 128K of the request, which will allow any attack to be seen in the log. URLScan can also be used to deny methods such as TRACK or TRACE. A good rule of thumb is to deny all request methods except for HEAD, GET, and POST.

Tip 

More information about URLScan can be found in Appendix C.