Re: CVE-2012-5076 and CVE-2012-1723 Rules

[Y M <snort () outlook com>]

Miso, I use both, VRT and ET in my production systems. Pesonally, they both complement each other for greater 
coverability. But this comes at the cost of managing the rules, responding to alerts; while eliminating alerts of the 
same threat being fired by two different rulesets, in a timely fashion. Although this is doable, but it takes a lot of 
time, tracking and engineering of the rulesets. All the comparisons I have seen between the VRT and ET rulesets have 
been largely subjective. Also which rules are being enabled out of the box is important but overlooked. On the surface, 
ET rules might fire far more since the majority of rules in a .rules file are enabled out of the box, on the other 
hand, VRT rules have the majority of them disabled as the "policy" employed when deploying the rules governs which 
rules are enabled. This is evident when running both rules (separately) through PulledPork. For almost a month, I have 
been watching how and when both teams update their rules. Release dates of updated rules by both teams happen at almost 
identical dates, give or take two or three days for both. This is not the case when using the Registered ruleset of the 
VRT team as it is almost a month behind the Subscriber ruleset, which is currently being discussed by Joel and Nathan 
in previous emails. My approach to this is completely different. The selection of which rules (.rules) to include is 
largely dependant on the environment and systems you run, network traffic, where your sensors are placed in the 
network, which rules can cover more of a particular threat, and your response methodology. I try to utilize the best of 
both worlds and this is an on-going process that require close attention as much as possible given that resources 
permit.
Thanks. YMDate: Mon, 26 Nov 2012 12:11:05 -0600
Subject: Re: [Snort-sigs] CVE-2012-5076 and CVE-2012-1723 Rules
From: miso.patel () gmail com
To: snort () outlook com
CC: jesler () sourcefire com; lists () packetmail net; snort-sigs () lists sourceforge net

YM,

My engineers indicate that the "ET" rules are best for protecting against the latest threats (because there are many 
improvements daily).  And they say that the VT ruleset is good but they are as if the anti-virus solutions. Very late 
and sometimes never ("quotes").


I like to akin to defense in depth so I use the ET for super protection and then the use of the VRT to make happy the 
auditors :) 

Thanks.

-Miso, CISO


On Mon, Nov 26, 2012 at 11:52 AM, Y M <snort () outlook com> wrote:





My intention of adding the ET ruleset was never driven for a comparison sake. The website I was checking clearly had 
similar behavior/symptoms of exploit methods based on Java and/or Adobe and I was not aware that the AV already 
detected them at the time. My intention was if this is a new exploit that's not yet covered by VRT/ET, I would gather 
as much information and forward them to the community. However, once I saw the AV complaining about it, I thought to 
share it anyway for further improvements as it may benefit someone.


 
If the specifics that I was testing with can add some help, like the blackhole website, pcaps or any other information 
I have, please let me know so I can forward them.

 Joel and Nathan, thank you both for the wonderful attitude and news about the community ruleset.


 
YM
Subject: Re: [Snort-sigs] CVE-2012-5076 and CVE-2012-1723 Rules
From: jesler () sourcefire com
Date: Mon, 26 Nov 2012 10:14:20 -0500


CC: snort () outlook com; snort-sigs () lists sourceforge net
To: lists () packetmail net



On Nov 26, 2012, at 10:00 AM, "lists () packetmail net" <lists () packetmail net> wrote:

On 11/25/2012 07:34 PM, Joel Esler wrote:> I'll take a look and see what we can

do to improve any coverage we are missing,

blackhole, especially v2, is a pain.


Joel, on the ET side and based on my network analysis, I am seeing very good

methods for combating some of this.  I would like for us to work more on this,

any more news regarding a community focused ruleset without delay between

registered users and subscribers?


We cover blackholev2 in much the same way.  Eoin's rules started our coverage with bhekv2 and we've made modifications 
along the way, and added a ton ourselves.  They have worked very well.  I watch exploit kits pretty regularly to make 
sure we improve coverage for these.  I just wrote protection for 3 other exploit kits this weekend and they should be 
shipped soon after testing.


As far as the community ruleset, the tl;dr is yes.
Longer:We were going to get this done in Q2 of this year, but with the massive ClamAV transition that took place this 
was placed on the back burner.  Now that we have recovered much of our cycles and reorganized the organization a bit to 
deal with the changes, we are now moving forward on it again.  There was some legal license work to do with the legal 
team that I had to get knocked out first, which involves writing provisions into the VRT license for the community 
ruleset (and some other beneficial changes!) along with making it simpler to read.  I'm due to provide my followup 
comments to the legal team this week about it, and then our DIE team can get working on the actual coding of the 
ruleset.  The way we have decided to do it is beneficial for everyone.  Registered, Subscriber, OEM, etc.  It'll 
involve a bit of coding, but it shouldn't be an issue.


On 11/25/2012 04:26 AM, Snort Troubleshooting wrote:

I went ahead and downloaded ET (open-source) rules and stuck them in there.
Then I browsed to the blackhole website again, and Snort fired on two ET


Rules, namely, sid:2015724, and sid:2015725.
You've just stumbled across some idiosyncratic differences between the VRT and

ET rulesets.  This has been discussed in the past but myself being a participant

in the ET ruleset I can say that as compared to VRT, ET/we are more focused on

the exploit kit and permutations of the exploit kits as a community and have

great coverage based on community input.


As I said above, we have some fantastic coverage for exploit kits (in exploit-kit.rules) and we adapt it to change the 
situations that pop up when needed.



--
Joel Esler
Senior Research Engineer, VRT


OpenSource Community Manager
Sourcefire
                                          



------------------------------------------------------------------------------

Monitor your physical, virtual and cloud infrastructure from a single

web console. Get in-depth insight into apps, servers, databases, vmware,

SAP, cloud infrastructure, etc. Download 30-day Free Trial.

Pricing starts from $795 for 25 servers or applications!

http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________

Snort-sigs mailing list

Snort-sigs () lists sourceforge net

https://lists.sourceforge.net/lists/listinfo/snort-sigs

http://www.snort.org





Please visit http://blog.snort.org for the latest news about Snort!

------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov

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


Please visit http://blog.snort.org for the latest news about Snort!