Re: Generic SQL injection false positives

[Paul Schmehl <pschmehl_lists () tx rr com>]

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 () tx rr com> 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 () gmail com> 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 () tx rr com> wrote:
> > > Can you provide an example of that?
> > >
> > > --On December 28, 2009 4:15:20 PM -0600 Guise McAllaster
> > > <guise.mcallaster () gmail com> 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 () tx rr com> wrote:
> > > > > --On December 28, 2009 12:10:37 PM -0600 Matt Olney
> > > > > <molney () sourcefire com> 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 () 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


------------------------------------------------------------------------------
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 () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-sigs