I'll post a little more about the theory behind some of these rules...but I wanted to say quickly that I'm considering breaking this into two rules, one for GET requests (I was thinking we could push the SQL detection to the right of the ? separator and another for post requests.  I'll put together some ideas tomorrow and see what you guys think.<br>
<br>Matt<br><br><div class="gmail_quote">On Tue, Dec 29, 2009 at 6:44 PM, Paul Schmehl <span dir="ltr"><<a href="mailto:pschmehl_lists@...3438...5...">pschmehl_lists@...3425...</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
OK, if you change the rule to use uricontent instead of content, then<br>
you'll avoid missing content that will appear after being normalized.<br>
However, I'm not convinced that normalizing will strip out sql comments<br>
like /**/.  If I'm correct in that, then even uricontent:'update"; nocase;<br>
pcre:"/^update$/i" will miss things like UP/**/DATE.  If uricontent<br>
doesn't match, pcre will never be tested, because content/uricontent<br>
matches are linear and from left to right.  The first content/uricontent<br>
must match something in the packet or the rest of the rule will be ignored.<br>
<br>
Anchoring the sql query syntax (e.g. pcre:"/^update$/i"; forces a match on<br>
only that word and no others.  ISTM that would be what you want if you're<br>
trying to catch sql injection and avoid false positives.<br>
<br>
--On December 29, 2009 9:28:35 AM -0600 Guise McAllaster<br>
<div><div></div><div class="h5"><<a href="mailto:guise.mcallaster@...202....2420...">guise.mcallaster@...2420...</a>> wrote:<br>
<br>
> Sir, let me clarify a few thing.  Firstly, "content" matches will not<br>
> match against a normalized buffer so you are correct that data such as<br>
> "D/**/ROP, DR/**/OP or DRO/**/P" will bypass a content match looking for<br>
> "DROP".  However, using uricontent will match the normalized buffer<br>
> which should (hopefully -- this is what we need clarifications on as to<br>
> what specific the normalization is) have removed such things as "%20",<br>
> "+", and "/**/".<br>
><br>
> Now, as for your comments, I am confused.  You say, "If you use<br>
> content:"foo"; nocase; first, and then pcre:"/^foo$/i"; next, content<br>
> will never match, so pcre will never be checked."  Yet data containing<br>
> "foo" will match the content check and snort will move on to chech the<br>
> PCRE match.  Howevers, the PCRE is not correctly what you want I<br>
> think.  It will only match "foo" and nothing else (e.g.<br>
> "<beginning_of_line>foo<end_of_line>").  For example, "0foo", "bfoo",<br>
> "foobar", and "foosball", will not match.<br>
><br>
> As an aside, thank you Matt and VRT for looking in to these rules as<br>
> they are a mountain of false positives in my environment and thus not<br>
> useful in the currently.<br>
><br>
> Guise<br>
><br>
><br>
> On Tue, Dec 29, 2009 at 2:50 AM, Paul Schmehl <<a href="mailto:pschmehl_lists@...3425...">pschmehl_lists@...3425...</a>><br>
> wrote:<br>
><br>
> Now that I've had some time to think about this, I do not think that<br>
> normalization will remove these.  I suspect that they will be passed to<br>
> the sql server.<br>
><br>
> The problem with trying to detect them is this.  If you use<br>
> content:"foo"; nocase; first, and then pcre:"/^foo$/i"; next, content<br>
> will never match, so pcre will never be checked.  But to catch every<br>
> possible instance you would have to try to match on the /**/ first, then<br>
> strip it from the content and match on update.  I don't think snort can<br>
> do that.<br>
><br>
> To bypass detection, I could use any one of the following: D/**/ROP,<br>
> DR/**/OP or DRO/**/P.  How would you test for all those instances?  In<br>
> a simple rule that's designed to detect "generic" sql injection, I think<br>
> you stick with detecting update and set.<br>
><br>
> If you want to catch instances of comments inserted into sql injection,<br>
> you would need a separate rule that attempts to detect the evasion.<br>
> Considering that urls normally have forward slashes in them, that would<br>
> not be easy to do.<br>
><br>
><br>
><br>
><br>
> --On December 28, 2009 6:40:42 PM -0600 Paul Schmehl<br>
> <<a href="mailto:pschmehl_lists@...3425...">pschmehl_lists@...3438...5...</a>> wrote:<br>
><br>
><br>
> I believe normalization will remove those as well, but someone from<br>
> Sourcefire will have to confirm that.<br>
><br>
> --On December 29, 2009 12:15:53 AM +0000 Guise McAllaster<br>
> <<a href="mailto:guise.mcallaster@...2420...">guise.mcallaster@...202....2420...</a>> wrote:<br>
><br>
><br>
> Sure:<br>
><br>
> <a href="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/" target="_blank">http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/</a><br>
><br>
> Search for "/**/"<br>
><br>
> A good point somebody says is that we need to know what exactly the<br>
> URL normalization is done so we can know what it eliminates.  Some<br>
> like "%20" and "+" or "++" are sure recognized but others?  What are<br>
> they?<br>
><br>
> Snort has been victim to some bypasses in the past (no offense, VRT).<br>
><br>
> Guise<br>
><br>
> On 12/28/09, Paul Schmehl <<a href="mailto:pschmehl_lists@...3437......">pschmehl_lists@...3425...</a>> wrote:<br>
><br>
> Can you provide an example of that?<br>
><br>
> --On December 28, 2009 4:15:20 PM -0600 Guise McAllaster<br>
> <<a href="mailto:guise.mcallaster@...2420...">guise.mcallaster@...202....2420...</a>> wrote:<br>
><br>
><br>
><br>
> From what I've seen, some SQLi will work using "/**/" instead of<br>
> spaces.  Other bypasses are possible as well I thinks.  Others want to<br>
> contribute some useful bypasses to spaces?<br>
><br>
> Guise<br>
><br>
> On 12/28/09, Paul Schmehl <<a href="mailto:pschmehl_lists@...3437......">pschmehl_lists@...3425...</a>> wrote:<br>
><br>
> --On December 28, 2009 12:10:37 PM -0600 Matt Olney<br>
> <<a href="mailto:molney@...435...">molney@...435...</a>> wrote:<br>
><br>
><br>
> I see a lot of false positive for generic SQL injection rules.  For<br>
> example, SID 13514 shown here:<br>
><br>
> alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"SQL<br>
> generic sql update injection attempt"; flow:established,to_server;<br>
> content:"update"; nocase; pcre:"/update[^\n]*set/i"; metadata:policy<br>
> security-ips drop, service http;<br>
> reference:url,<a href="http://www.securiteam.com/securityreviews/5DP0N1P76E.html" target="_blank">www.securiteam.com/securityreviews/5DP0N1P76E.html</a>;<br>
> classtype:web-application-attack; sid:13514; rev:4;)<br>
><br>
> Alas it alerts for normal traffic like this:<br>
><br>
> GET /get_updates_1/assessment/frameset_yellow.asp  HTTP/1.1<br>
><br>
><br>
> I don't see how a sql injection attempt is going to begin with any<br>
> character other than a space preceding it.  How would the sql engine<br>
> be able to parse that?  ISTM that the update could simply be anchored<br>
> on both sides; e.g pcre:"$update^/i";  For update to work, the only<br>
> thing that can be on either side of it is a non-alpha character or a<br>
> single quote, which the sql parser will discard.  If you want to<br>
> include set (which makes sense), I would make it a separate<br>
> detection.  A typical update statement would be UPDATE table SET<br>
> blah='foo' where blah='bar' or blah like '%doo%';<br>
><br>
> Something like this would be better, in my opinion.<br>
><br>
> alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"SQL<br>
> generic sql update injection attempt"; flow:established,to_server;<br>
> content:"update"; nocase; pcre:"/$update^/i"; content:"set"; nocase;<br>
> pcre:"/$set^/i"; metadata:policy security-ips drop, service http;<br>
> reference:url,<a href="http://www.securiteam.com/securityreviews/5DP0N1P76E.html" target="_blank">www.securiteam.com/securityreviews/5DP0N1P76E.html</a>;<br>
> classtype:web-application-attack; sid:13514; rev:5;)<br>
><br>
> Mind you, I haven't tested it, but it would certainly eliminate the<br>
> false positive given in the example.<br>
><br>
> Paul Schmehl, If it isn't already<br>
> obvious, my opinions are my own<br>
> and not those of my employer.<br>
> ******************************************<br>
> WARNING: Check the headers before replying<br>
><br>
><br>
> ---------------------------------------------------------------------<br>
> -- ------- This SF.Net email is sponsored by the Verizon Developer<br>
> Community Take advantage of Verizon's best-in-class app development<br>
> support A streamlined, 14 day to market process makes app<br>
> distribution fast and easy Join now and get one step closer to<br>
> millions of Verizon customers <a href="http://p.sf.net/sfu/verizon-dev2dev" target="_blank">http://p.sf.net/sfu/verizon-dev2dev</a><br>
> _______________________________________________<br>
> Snort-sigs mailing list<br>
> <a href="mailto:Snort-sigs@lists.sourceforge.net">Snort-sigs@...3134...ourceforge.net</a><br>
> <a href="https://lists.sourceforge.net/lists/listinfo/snort-sigs" target="_blank">https://lists.sourceforge.net/lists/listinfo/snort-sigs</a><br>
><br>
><br>
><br>
><br>
><br>
> Paul Schmehl, If it isn't already<br>
> obvious, my opinions are my own<br>
> and not those of my employer.<br>
> ******************************************<br>
> WARNING: Check the headers before replying<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> Paul Schmehl, If it isn't already<br>
> obvious, my opinions are my own<br>
> and not those of my employer.<br>
> ******************************************<br>
> WARNING: Check the headers before replying<br>
><br>
><br>
><br>
><br>
> Paul Schmehl, If it isn't already<br>
> obvious, my opinions are my own<br>
> and not those of my employer.<br>
> ******************************************<br>
> WARNING: Check the headers before replying<br>
><br>
><br>
><br>
<br>
<br>
<br>
Paul Schmehl, If it isn't already<br>
obvious, my opinions are my own<br>
and not those of my employer.<br>
******************************************<br>
WARNING: Check the headers before replying<br>
<br>
<br>
------------------------------------------------------------------------------<br>
This SF.Net email is sponsored by the Verizon Developer Community<br>
Take advantage of Verizon's best-in-class app development support<br>
A streamlined, 14 day to market process makes app distribution fast and easy<br>
Join now and get one step closer to millions of Verizon customers<br>
<a href="http://p.sf.net/sfu/verizon-dev2dev" target="_blank">http://p.sf.net/sfu/verizon-dev2dev</a><br>
_______________________________________________<br>
Snort-sigs mailing list<br>
<a href="mailto:Snort-sigs@lists.sourceforge.net">Snort-sigs@...639...forge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/snort-sigs" target="_blank">https://lists.sourceforge.net/lists/listinfo/snort-sigs</a><br>
</div></div></blockquote></div><br>