[Snort-sigs] Generic SQL injection false positives

Matt Olney molney at ...435...
Mon Dec 28 20:09:28 EST 2009


I've got a new SO worked up that we're going to publish to labs soon that
shows exactly whats in the various buffers.  I'll gen up some pcaps and
publish the results here.  Hopefully we'll get it released soon after the
first of the year.  There are some sql-inject brute force scripts I've been
meaning to test anyways.

If you guys have tools you want me to check out as part of this, send me
info.

Matt

On Mon, Dec 28, 2009 at 7:40 PM, 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
>
>
>
> ------------------------------------------------------------------------------
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-sigs/attachments/20091228/65d44dbd/attachment.html>


More information about the Snort-sigs mailing list