bugtraq - Re: URLScan detection

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Sun, 1 Jun 2003 20:14:13 -0600
From: "M. Burnett" <mb@...o.net>
To: <mail@...sense.kimihia.org.nz>, <bugtraq@...urityfocus.com>
Subject: Re: URLScan detection


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