[Snort-sigs] Generic SQL injection false positives

Matt Olney molney at ...435...
Wed Jan 27 14:45:18 EST 2010


Guise,

I'll kick this over to Shong and have her look at it.  I'm sure she'll
get back to you shortly.  But first, I have something you need to do.

Either intentionally, or, I hope, unintentionally, you misspelled Ms.
Hong's name as "shlong".  Now you don't know her, nor do you know the
quality and quantity of the output that she provides on behalf of
Sourcefire and its customers.  I am quite willing to put up with your
various quirks and means of communication, and I'm very happy to work
with you to correct issues in our rule set.  I'll even put up with the
dismissive manner that you take when discussing the VRT and
Sourcefire.

I feel, strongly, that this sort of behavior isn't appropriate on this
list.  I would certainly not be happy if someone on the VRT did this,
and I am not happy with this.  I would hope that you would appologize
for this error.  You will probably consider this overly touchy and
sensitive, but I'm very protective of the people who work on this
team.

I'm sure you understand,

Matt

On Wed, Jan 27, 2010 at 2:28 PM, Guise McAllaster
<guise.mcallaster at ...2420...> wrote:
> Matt,
>
>
>
> Thank you again for following up on this and helping getting
> improvements in place.  Your continued responses and actual actions
> are much appreciated.
>
>
>
> As far as Shlong being a emerging star (and "hard work" -- it's just
> some minor PCRE changes) ... hmmmm (*thinks of someone else who could
> be VRT star*).  Consider this latest revision of 13514:
>
>
>
> alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"SQL
> generic sql update injection attempt - GET parameter";
> flow:established,to_server; uricontent:"update"; nocase;
> pcre:"/update\s+[^\/\\]+set\s+[^\/\\]+/Ui"; metadata:policy
> security-ips drop, service http;
> reference:url,www.securiteam.com/securityreviews/5DP0N1P76E.html;
> classtype:web-application-attack; sid:13514; rev:7;)
>
>
>
> This doesn't detect the classic/normal attacks.  A single space or a
> '+' between 'update' and 'set' will not match the PCRE.  Examples:
>
>
>
> /.php?user=monley';+update+set+awesome=1+where+name=guise--+
>
> /facepalm.php?user=guise'; update set awesome=0 where name=snigel--
>
> /bottompostsux.php?user=junkman';/**/update/**/set/**/awesome=1/**/where/**/name=ET--
>
>
>
> The other SQL injection rule updates may suffer from the same (or
> similar) PCRE shortcomings but you can check yourself.  I've already
> offered my suggestion (which was not used) and I cannot in good
> conscience continue to correct VRT rules for free :) but the way I see
> it, if you bother cranking up the PCRE engine, you might as well take
> advantage of all its powerfulness.
>
>
>
> Seriously, thanks again for responding about these rules.  As an
> indirect result of investigating it, I found a serious flaw in my
> snort setup and now it is fixed and boss give Guise compliment and is
> happy :)
>
>
>
> Guise
>
> On 1/26/10, Matt Olney <molney at ...435...> wrote:
>> Thanks to the hard work of Shong, one of our emerging stars on the
>> analyst team these are among the changes in this week's update:
>>
>> Updated rules:
>> 13512 <-> SQL generic sql exec injection attempt - GET parameter
>> (sql.rules, High)
>> 13513 <-> SQL generic sql insert injection atttempt - GET parameter
>> (sql.rules, High)
>> 13514 <-> SQL generic sql update injection attempt - GET parameter
>> (sql.rules, High)
>> 13990 <-> SQL union select - possible sql injection attempt - GET
>> parameter (sql.rules, Medium)
>>
>> Thanks for the heads up on these, keep letting us know if you have any
>> issues.
>>
>> Matt
>>
>




More information about the Snort-sigs mailing list