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
