Snort mailing list archives
Re: Generic SQL injection false positives
From: Guise McAllaster <guise.mcallaster () gmail com>
Date: Tue, 29 Dec 2009 15:28:35 +0000
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 fromSourcefire 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. Forexample, 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.1I 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-sigsPaul Schmehl, If it isn't already obvious, my opinions are my own and not those of my employer. ****************************************** WARNING: Check the headers before replyingPaul Schmehl, If it isn't already obvious, my opinions are my own and not those of my employer. ****************************************** WARNING: Check the headers before replyingPaul 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
Current thread:
- Re: Generic SQL injection false positives, (continued)
- Re: Generic SQL injection false positives Alex Kirk (Dec 28)
- Re: Generic SQL injection false positives Paul Schmehl (Dec 28)
- Re: Generic SQL injection false positives Guise McAllaster (Dec 28)
- Re: Generic SQL injection false positives Graham Bignell (Dec 28)
- Re: Generic SQL injection false positives Paul Schmehl (Dec 28)
- Re: Generic SQL injection false positives Paul Schmehl (Dec 28)
- Re: Generic SQL injection false positives Guise McAllaster (Dec 28)
- Re: Generic SQL injection false positives Paul Schmehl (Dec 28)
- Re: Generic SQL injection false positives Matt Olney (Dec 28)
- Re: Generic SQL injection false positives Paul Schmehl (Dec 28)
- Re: Generic SQL injection false positives Guise McAllaster (Dec 29)
- Re: Generic SQL injection false positives Matt Olney (Dec 29)
- Re: Generic SQL injection false positives Paul Schmehl (Dec 29)
- Re: Generic SQL injection false positives Matt Olney (Dec 29)
- Re: Generic SQL injection false positives Guise McAllaster (Dec 29)