Re: Generic SQL injection false positives

[Guise McAllaster <guise.mcallaster () gmail com>]

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 () tx rr com>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 () 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