Re: Improve to BACKDOOR c99shell.php command request

[Alex Kirk <akirk () sourcefire com>]

You can always make suggestions about rules, Guise, that's the point of this
list.

That said, this suggestion looks pretty reasonable - it removes none of the
alerts the existing rule generates on the malicious PCAP we have over here,
I see no real potential for false negatives being introduced, and it should
solve the issue you raise. I'll see about updating the rule within the next
couple of releases.

As for the VRT hiring someone to review the rules, that's a decision that
would go on well above my head, so I can't really comment on that. The
people who would make that decision are on this list, though, and if it's
something that's feasible, I'm sure they'll keep you in mind.

On Thu, Jan 21, 2010 at 11:17 AM, Guise McAllaster <
guise.mcallaster () gmail com> wrote:

> Hello. Can I make more suggestion about rules?
>
>
>
> This one, SID 12077, has good intentions and I like it but is not
> skillfully crafted.  Here it is now in backdoor.rules:
>
>
>
> alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"BACKDOOR
> c99shell.php command request"; flow:established,to_server;
> content:"act=";
>
> pcre:"/act=(cmd|search|upload|about|encoder|bind|ps_aux|ftpquickbrute|security|sql|eval|feedback|selfremove|fsbuff|ls|phpinfo)/smi";
> reference:url,vil.nai.com/vil/content/v_136948.htm;
> classtype:policy-violation; sid:12077; rev:2;)
>
>
>
> What if we change it to look in URI buffer (I see false positive now
> b/c of Referer header) and make changes so things such as
> 'react=about' don't alert this?
>
>
>
> alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"BACKDOOR
> c99shell.php command request"; flow:established,to_server;
> uricontent:"act="; nocase;
>
> pcre:"/[&\?]act=(cmd|search|upload|about|encoder|bind|ps_aux|ftpquickbrute|security|sql|eval|feedback|selfremove|fsbuff|ls|phpinfo)/Ui";
> reference:url,vil.nai.com/vil/content/v_136948.htm;
> classtype:policy-violation; sid:12077; rev:3;)
>
>
>
> The more I look at the Snort rules supplied by SourceFire, the more I
> see a lot of room to improve performance and reduce false positives.
> (Please don't flame me, I'm just stating truth, not trying to be
> mean.)  Perhaps VRT will hire someone to just go over the existing
> rules and make them better?  If you let me work from France, I might
> be willing to fill such a position....
>
>
>
> Guise
>
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for
> Conference
> attendees to learn about information security's most important issues
> through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> Snort-sigs mailing list
> Snort-sigs () lists sourceforge net
> https://lists.sourceforge.net/lists/listinfo/snort-sigs



-- 
Alex Kirk
AEGIS Program Lead
Sourcefire Vulnerability Research Team
+1-410-423-1937
alex.kirk () sourcefire com

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev

_______________________________________________
Snort-sigs mailing list
Snort-sigs () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-sigs