Bugtraq mailing list archives

Re: URLScan detection

From: "M. Burnett" <mb () xato net>
Date: Sun, 1 Jun 2003 20:14:13 -0600

One problem with using UseFastPathReject, as Microsoft recommends, is 
that it too can be used to identify URLScan. UseFastPathReject just 
sends back a generic 404 message. However, If a site normally uses a 
custom 404 message, but rejects attacks with a generic message, it 
will be pretty easy to identify URLScan running on the server.

There is also another way to identify URLScan: make an HTTP OPTIONS 
request to a file that you know exists (except an exe file). IIS will 
normally return a 200 for anything handled by the default handler and 
403 for anything mapped to a script handler (i.e., ASP or IDC). Exe 
files can return 200, 403, or 404, depending on permissions.

So if you do something like OPTIONS /index.htm you should get a 200 
without URLScan and a 404 when URLScan is blocking the OPTIONS 
method.

Mark Burnett
www.iissecurity.info




On Sat, 31 May 2003 13:58:58 +1200, Stephen Cope wrote:

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

Current thread:

URLScan detection Stephen Cope (Jun 01)
- Re: URLScan detection M. Burnett (Jun 03)