[Snort-sigs] WEB-CGI phf access - SID 886

JJ Cummings cummingsj at ...2420...
Tue Dec 29 17:23:06 EST 2009


Partially on-topic, yes I have been working on a new feature within pulled
pork what will automatically create predefined VRT rulesets of disabled  and
enabled rules based on the requirements of the end user.

I.E.
Security
Connectivity
Balanced

JJC

On Tue, Dec 29, 2009 at 3:07 PM, Matt Olney <molney at ...435...> wrote:

> So, a little bit about how the VRT approaches these older rules:
>
> 1)  There is a field in many rules called "metadata".  This field is used
> by our product to determine which rules to turn on and off for base rule
> sets.  I know that JJ (pulled pork) has been working on integrating a
> similar set of functionality into pulled pork.  But here is the important
> part, if there is no metadata then we've essentially said don't turn this
> rule on by default.
>
> 2)  We will also disable rules that we feel are particularly problematic,
> either false-positive wise, or performance wise.
>
> 3)  We generally only revisit rules when we get information from users that
> there is an issue (none reported on this rule), when there is unpdated
> functionality in snort that impacts the rule (note that this old rule uses
> the newer uricontent) or if we stumble across something in testing.  When we
> do this we typically disable, delete or modify the rule, although sometimes
> we do simply say the rule is what it is, and we can't change it without
> impacting functionality.
>
> In this case I would simply say that you should disable the rule.  I
> certainly wouldn't go out and add a pcre check on this, as it isn't worth
> the additional overhead.  This would, in general, be part of the tuning
> process.
>
> Now, with all of that said...I'm thinking we could probably disable this
> rule, I'll throw a bug entry together and make sure I'm not missing
> anything.
>
> Matt
>
>
> On Tue, Dec 29, 2009 at 4:25 PM, Guise McAllaster <
> guise.mcallaster at ...2420...> wrote:
>
>> Here is another ancient rule that has some false positive:
>>
>> alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-CGI phf
>> access"; flow:to_server,established; uricontent:"/phf"; nocase;
>> metadata:service http; reference:arachnids,128; reference:bugtraq,629;
>> reference:cve,1999-0067; classtype:web-application-activity; sid:886;
>> rev:12;)
>>
>> If people still care about this vuln, could we change it to be more
>> robust?  I see it false positive on things like 'GET
>> /foo/bar/PHFDD_user.js'.
>>
>> Maybe something like this:
>>
>> alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-CGI phf
>> access"; flow:to_server,established; uricontent:"/phf"; nocase; nocase;
>> pcre:"/\/phf\/?\?/Ui"; metadata:service http; reference:arachnids,128;
>> reference:bugtraq,629; reference:cve,1999-0067;
>> classtype:web-application-activity; sid:886; rev:13;)
>>
>> Similar simple file access rules could probably be modified in a similar
>> manner (although I have not looked).
>>
>> If people don't care about the rule, maybe we could prune it out along
>> with all exploit specific rules that are over 10 years old.
>>
>> Thanks.
>>
>> Guise
>>
>>
>> ------------------------------------------------------------------------------
>> 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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/snort-sigs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-sigs/attachments/20091229/45cfbd08/attachment.html>


More information about the Snort-sigs mailing list