[Snort-sigs] Generic SQL injection false positives

Guise McAllaster guise.mcallaster at ...2420...
Tue Dec 29 10:28:35 EST 2009


Sir, let me clarify a few thing.  Firstly, "content" matches will not match
against a normalized buffer so you are correct that data such as "D/**/ROP,
DR/**/OP or DRO/**/P" will bypass a content match looking for "DROP".
However, using uricontent will match the normalized buffer which should
(hopefully -- this is what we need clarifications on as to what specific the
normalization is) have removed such things as "%20", "+", and "/**/".

Now, as for your comments, I am confused.  You say, "*If you use
content:"foo"; nocase; first, and then pcre:"/^foo$/i"; next, content will
never match, so pcre will never be checked.*"  Yet data containing "foo"
will match the content check and snort will move on to chech the PCRE
match.  Howevers, the PCRE is not correctly what you want I think.  It will
only match "foo" and nothing else (e.g.
"<beginning_of_line>foo<end_of_line>").  For example, "0foo", "bfoo",
"foobar", and "foosball", will not match.

As an aside, thank you Matt and VRT for looking in to these rules as they
are a mountain of false positives in my environment and thus not useful in
the currently.

Guise

On Tue, Dec 29, 2009 at 2:50 AM, Paul Schmehl <pschmehl_lists at ...3425...>wrote:

> Now that I've had some time to think about this, I do not think that
> normalization will remove these.  I suspect that they will be passed to the
> sql server.
>
> The problem with trying to detect them is this.  If you use content:"foo";
> nocase; first, and then pcre:"/^foo$/i"; next, content will never match, so
> pcre will never be checked.  But to catch every possible instance you would
> have to try to match on the /**/ first, then strip it from the content and
> match on update.  I don't think snort can do that.
>
> To bypass detection, I could use any one of the following: D/**/ROP,
> DR/**/OP or DRO/**/P.  How would you test for all those instances?  In a
> simple rule that's designed to detect "generic" sql injection, I think you
> stick with detecting update and set.
>
> If you want to catch instances of comments inserted into sql injection, you
> would need a separate rule that attempts to detect the evasion. Considering
> that urls normally have forward slashes in them, that would not be easy to
> do.
>
>
> --On December 28, 2009 6:40:42 PM -0600 Paul Schmehl <
> pschmehl_lists at ...3425...> wrote:
>
>  I believe normalization will remove those as well, but someone from
>> Sourcefire will have to confirm that.
>>
>> --On December 29, 2009 12:15:53 AM +0000 Guise McAllaster
>> <guise.mcallaster at ...2420...> wrote:
>>
>>  Sure:
>>>
>>> http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/
>>>
>>> Search for "/**/"
>>>
>>> A good point somebody says is that we need to know what exactly the
>>> URL normalization is done so we can know what it eliminates.  Some
>>> like "%20" and "+" or "++" are sure recognized but others?  What are
>>> they?
>>>
>>> Snort has been victim to some bypasses in the past (no offense, VRT).
>>>
>>> Guise
>>>
>>> On 12/28/09, Paul Schmehl <pschmehl_lists at ...3425...> wrote:
>>>
>>>> Can you provide an example of that?
>>>>
>>>> --On December 28, 2009 4:15:20 PM -0600 Guise McAllaster
>>>> <guise.mcallaster at ...2420...> wrote:
>>>>
>>>>
>>>>> From what I've seen, some SQLi will work using "/**/" instead of
>>>>> spaces.  Other bypasses are possible as well I thinks.  Others want to
>>>>> contribute some useful bypasses to spaces?
>>>>>
>>>>> Guise
>>>>>
>>>>> On 12/28/09, Paul Schmehl <pschmehl_lists at ...3425...> wrote:
>>>>>
>>>>>> --On December 28, 2009 12:10:37 PM -0600 Matt Olney
>>>>>> <molney at ...435...> wrote:
>>>>>>
>>>>>>  I see a lot of false positive for generic SQL injection rules.  For
>>>>>>> example, SID 13514 shown here:
>>>>>>>
>>>>>>> alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"SQL
>>>>>>> generic sql update injection attempt"; flow:established,to_server;
>>>>>>> content:"update"; nocase; pcre:"/update[^\n]*set/i"; metadata:policy
>>>>>>> security-ips drop, service http;
>>>>>>> reference:url,www.securiteam.com/securityreviews/5DP0N1P76E.html;
>>>>>>> classtype:web-application-attack; sid:13514; rev:4;)
>>>>>>>
>>>>>>> Alas it alerts for normal traffic like this:
>>>>>>>
>>>>>>> GET /get_updates_1/assessment/frameset_yellow.asp  HTTP/1.1
>>>>>>>
>>>>>>
>>>>>> I don't see how a sql injection attempt is going to begin with any
>>>>>> character other than a space preceding it.  How would the sql engine
>>>>>> be able to parse that?  ISTM that the update could simply be anchored
>>>>>> on both sides; e.g pcre:"$update^/i";  For update to work, the only
>>>>>> thing that can be on either side of it is a non-alpha character or a
>>>>>> single quote, which the sql parser will discard.  If you want to
>>>>>> include set (which makes sense), I would make it a separate
>>>>>> detection.  A typical update statement would be UPDATE table SET
>>>>>> blah='foo' where blah='bar' or blah like '%doo%';
>>>>>>
>>>>>> Something like this would be better, in my opinion.
>>>>>>
>>>>>> alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"SQL
>>>>>> generic sql update injection attempt"; flow:established,to_server;
>>>>>> content:"update"; nocase; pcre:"/$update^/i"; content:"set"; nocase;
>>>>>> pcre:"/$set^/i"; metadata:policy security-ips drop, service http;
>>>>>> reference:url,www.securiteam.com/securityreviews/5DP0N1P76E.html;
>>>>>> classtype:web-application-attack; sid:13514; rev:5;)
>>>>>>
>>>>>> Mind you, I haven't tested it, but it would certainly eliminate the
>>>>>> false positive given in the example.
>>>>>>
>>>>>> Paul Schmehl, If it isn't already
>>>>>> obvious, my opinions are my own
>>>>>> and not those of my employer.
>>>>>> ******************************************
>>>>>> WARNING: Check the headers before replying
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> -- ------- This SF.Net email is sponsored by the Verizon Developer
>>>>>> Community Take advantage of Verizon's best-in-class app development
>>>>>> support A streamlined, 14 day to market process makes app
>>>>>> distribution fast and easy Join now and get one step closer to
>>>>>> millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev
>>>>>> _______________________________________________
>>>>>> Snort-sigs mailing list
>>>>>> Snort-sigs at lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/snort-sigs
>>>>>>
>>>>>
>>>>
>>>>
>>>> Paul Schmehl, If it isn't already
>>>> obvious, my opinions are my own
>>>> and not those of my employer.
>>>> ******************************************
>>>> WARNING: Check the headers before replying
>>>>
>>>>
>>>>
>>>
>>
>>
>> Paul Schmehl, If it isn't already
>> obvious, my opinions are my own
>> and not those of my employer.
>> ******************************************
>> WARNING: Check the headers before replying
>>
>
>
>
> Paul Schmehl, If it isn't already
> obvious, my opinions are my own
> and not those of my employer.
> ******************************************
> WARNING: Check the headers before replying
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-sigs/attachments/20091229/9e95b8f3/attachment.html>


More information about the Snort-sigs mailing list