TUCoPS :: Web :: IIS

TUCoPS :: Web :: IIS :: bt320.txt
IIS URLScan detection


Product: URLScan (for IIS)
Vendor : Microsoft
Date   : Monday 27 May 2002

URLScan is a popular "Security Tool" used to filter out malicious
looking URLs. It has a variety of filters, including blocking requests
with excess escaped characters or for files with given extensions, eg,
.exe.

http://www.microsoft.com/technet/security/tools/tools/urlscan.asp

URLScan can be detected on IIS servers by the way it responds to HEAD
requests.

When a bad URL is rewritten it is changed to the GET request type.

Here's an example in action:

First an innocent request:

HEAD /OMG HTTP/1.1
Host: iis
Connection: close

Response:

HTTP/1.1 404 Object Not Found
Server: Microsoft-IIS/5.0
Date: Tue, 28 May 2002 04:30:42 GMT
Content-Length: 4040
Content-Type: text/html


Now one that will be blocked by URLScan. Note the .exe extension. This
is a common extension to block with URLScan's out-of-the-box settings:

HEAD /OMG.exe HTTP/1.1
Host: iis
Connection: close

Response:

HTTP/1.1 404 Object Not Found
Server: Microsoft-IIS/5.0
Date: Tue, 28 May 2002 04:32:15 GMT
Connection: close
Content-Length: 4040
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html dir=ltr>
[huge page of HTML snipped]


So when URLScan zapped the request it displayed the content of the
document. It rewrote the HEAD request to a GET request. This does
violate RFC 2616 section 9.4, which states:

    The HEAD method is identical to GET except that the server MUST NOT
    return a message-body in the response.

The version of URLSCAN.DLL in use is 6.0.3547.0

Now you can tell if the server admin is being proactive in security or
whether they are an easy target.



Vendor reply, explaining this behaviour is as follows:

Hi Stephen:

I got some feedback from the developers of this tools and what you are
saying is true.  When UrlScan rejects a request, it changes the inbound
data from whatever is was to a known GET request for the reject page.
You can change this behavior by setting "UseFastPathReject=1".

This is by design to ensure that no non-GET requests can reach the
reject URL.  The behavior described below is a side effect of this.

Please let me know if you have any further questions or feedback.  I
would be happy to address them.

Thanks again for your inquiry.

Kind regards,

--- end quote

Thank you to my employer at the time, Gorilla Technology  
www.gorilla.co.nz 

-- 
Stephen Cope - http://sdc.org.nz/