Re: Snort and Nessus Signature

[Vikram Phatak <vphatak () lucidsecurity com>]

Wow.  I did not expect that kind of response...  I offered to discuss in 
detail with Crux or anyone else interested.  Have I somehow offended you?

Jason wrote:

> Vikram Phatak wrote:
>
> > Hi Crux,
> >
> > It is not a simple matter to integrate Nessus & Snort since there are 
> > quite a few errors in the snort signatures, or in the supporting 
> > information for many of the snort signatures (CVE, BID, descriptions, 
> > etc.).  
>
>
> How so? Please provide a little more information. 

First, if you look at the non-VRT certified signatures from Snort, or 
historically at Snort signatures in general, they do not consistently 
have references, and in many cases needed to be updated to support 
functions available in newer versions of Snort (like PCRE) that provide 
better accuracy and lower false positives.  Sourcefire recognized this - 
which is why they rewrote over 1000 signatures (may be more now) which 
can be purchased as part of their VRT Certifiied signature program.

Having said that, we have found that there can be multiple CVE entries 
for the same vulnerability, signatures that have no CVE, multiple nessus 
plugins that have the same CVE (sometimes correct, sometimes not) etc.  
You cannot simply assume that everything is correct, and correlate 
automatically and expect to have any confidence in your results - which 
means you need to inspect every single correlation (which takes time).  
Also, there is no mechanism for validating the OS & Applications that 
are important to you have complete coverage, unless you begin with the 
OS & Applications, pick the related CVE (or other DB) entries and then 
find the nessus plugin and snort signatures.

> > Also, many snort signatures do not have CVE, BID references since 
> > historically they have written based upon packet captures of specific 
> > exploits,  (such as "Sasser") as opposed to vulnerabilities
> > (LSASS), which is how CVE entries are sorted.
>
>
> Absolutely incorrect. LSASS is the detect method and the rules detect 
> exploitation of a vulnerability not an exploit.


Um.  Please check your facts.  Sourcefire did not provide its VRT 
service until Feb/March '05, while LSASS vulnerability that the SASSER 
worm exploited came out in April/May '04.   The only signatures publicly 
available at the time were exploit signatures based upon PCAPs of the 
different worm variants...  Despite any marketing that would have you 
believe otherwise.

Please see http://seclists.org/lists/bugtraq/2004/May/0016.html 

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"W32/Sasser.worm.a
[NAI])"; content:"|BC 3B 74 0B 50 8B 3D E8 46 A7 3D 09 85 B8 F8 CD 76 40
DE 7C 5B 5C D7 2A A8 E8 58 75 62 96 25 24|"; classtype:misc-
activity;rev:1;)

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"W32/Sasser.worm.b
[NAI])"; content:"|58 BC 0C FF 59 57 32 31 BD EC 34 64 6E D6 E3 8D 65 04
68 58 62 79 DF D8 2C 25 6A B5 28 BA 13 74|"; classtype:misc-
activity;rev:1;)

While there may have been some cases where vulnerability based 
signatures were written by the open source community, it was not the 
norm, since in order to write a vulnerability based signature, you (very 
often) need to disassemble / debug binaries of both the original 
software and the patch in order to diff the two and examine how the 
applications can be misused.  This is time consuming and difficult.  If 
on an average week there are 10-20 vulnerabilities (that you care about) 
announced, it is not possible to provide timely and accurate signatures 
without coordination.  I am not saying this cannot be done via the 
open-source community, I am saying historically, it has not been done.  
Also I feel that it is unrealistic to believe that a service (not 
software) that is time sensitive and time consuming can be performed 
effectively day after day, week after week by anybody other than an 
organized group because of the coordination required.

So, having said all of that, I know that Lucid Security's 
signatures/rules are vulnerability based, but many organizations 
signatures frequently are not, especially historically - which is 
important when you are trying to correlate historical data.  I know this 
is true because Lucid Security decided to write vulnerability based 
signatures for many historical vulnerabilities since it was the only way 
to correlate the data with any confidence.  And the expense we incurred 
to provide this kind of solution was not insignificant.

> >   And there is no publicly available DB that I know of that 
> > correlates exploits to vulnerabilities.
> >
> > So - In many cases, you will need to determine which vulnerability a 
> > specific exploit was written to take advantage of, and work your way 
> > back from there.
>
>
> bugtraq reference: 1565
> references: 1441
> arachNIDS references: 432
> McAfee reference: 9
> nessus reference: 676
> url reference: 971
> any reference: 2713
>
> Total number of rules 3910
>
> Bugtraq coverage: 40%
> cve coverage: 36%
> arachNIDS coverage: 11%
> McAfee coverage: 2%
> Nessus coverage: 17%
> url coverage: 25%
>
> Percentage coverage any reference: 70%

I was not talking about signatures in the sentences you quoted - I was 
referring to a lack of exploit to vulnerability DB. 
(OS & App version has the following: CAN-2004-0894 
<http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0894> 
Vulnerability -->Exploits)
Also, I am not saying the information does not exist.  I am saying that 
it is disjointed and requires a lot of work to examine and prune, etc.

But to your point - assuming 100% accuracy of references and that most 
eventually point back to something that can be correllated with a Nessus 
plugin - which 70% are covered?  How do I, as an admin, know I am not 
missing something?  There needs to be some examination of effectiveness 
before simply saying "lets correlate".  Or rather, correlate - but audit 
your results.  That was the point of my prior posting.

> > We (Lucid Security) have found that it was far more efficient (and 
> > reliable) to choose the OS & Application versions that we want to 
> > protect (MSFT, Linux, Solaris, Apache, IIS, SQL, etc.) and prioritize 
> > accordingly.  We then chose the appropriate CVE entries that met the 
> > requirements of our "filter" and wrote and tested signatures based 
> > upon the vulnerability accordingly.  If there was an existing 
> > signature that met our requirements, then great! But we found that 
> > was rarely the case.  
>
>
> I take it you are not in the spirit of the community and as such are 
> either selling your wares and saying screw the rest of the community 
> or you are simply spreading FUD. Which is it?
Nice.  Do you attack Ron or Marty with this kind of nonsense?  I am 
offering advice from experiences that we have gone through and you are 
asking me if I am saying "screw the community" or "spreading FUD"?  It 
is like asking, "Do you still beat your wife?"


   -Vik

--
Vikram Phatak
CTO, Lucid Security
http://www.lucidsecurity.com



------------------------------------------------------------------------
Test Your IDS

Is your IDS deployed correctly?
Find out quickly and easily by testing it 
with real-world attacks from CORE IMPACT.
Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708 
to learn more.
------------------------------------------------------------------------