[Snort-sigs] Generic SQL injection false positives

Paul Schmehl pschmehl_lists at ...3425...
Mon Dec 28 21:50:52 EST 2009


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





More information about the Snort-sigs mailing list