Snort mailing list archives

Re: Generic SQL injection false positives


From: Guise McAllaster <guise.mcallaster () gmail com>
Date: Mon, 28 Dec 2009 22:15:20 +0000

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


------------------------------------------------------------------------------
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


Current thread: