[Snort-sigs] Generic SQL injection false positives

Paul Schmehl pschmehl_lists at ...3425...
Mon Dec 28 19:40:42 EST 2009


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





More information about the Snort-sigs mailing list