--- "George A. Theall" <[EMAIL PROTECTED]> wrote:
> On Thu, Oct 06, 2005 at 06:53:34AM -0700, Jon Passki wrote:
>
> > My pain
> > has been a couple fold: discretionary reporting of the
> stimul{us,i}
> > sent and the response received; no matching between BID and CVE
> > entries;
>
> Would you mind expanding on these points a bit?
Sure, I would love to!
Discretionary logging of stimuli and responses:
Perhaps I'm not too familiar with all the logging capabilities of
nessus, but we run it with 'paranoia_level' of '3' and
'log_whole_attack' of 'yes'. I have not seen in the kbs,
nessusd.messages or the NBE file is the actual stimuli ever
recorded. For example, Plugin ID 11438
(tomcat_directory_listing_and_file_disclosure.nasl) stores the
stimulus in 'req' and the response in 'res'. Neither of these are
recorded for someone to perform any type of false positive
validation. Additionally, the get_http_port and http_get_cache
NASL functions each send out information (1 and 2 requests,
respectively). For this example (which I recently had some
experienc with), the latter http_get_cache calls connected to a
load balanced site. The first two calls went to the same back-end,
while the http_keepalive_send_recv call went to a different one.
On top of it, the responses were different from each of the web
sites (one had "Directory Listing" in the response, the other
didn't). And then there was a bug in the script that Renaud took
care of :-)
I had to recreate all of the traffic and understand which function
was sending/rec'v what. This type of scenario is going to be
difficult to capture with logic (knowing it's load balanced,
knowing how to either provide affinity with the load balancer or
detect a difference on the back-end) but easier to understand with
a human analyst... if the stimuli and responses are present.
Currently, pcap dumping is the only way to CYA on this (or running
the test again, if one can).
No Matching between BID and CVE's:
Take a look at Plugin ID 14748. It has two BID's and four CVE's.
Which BID does {CAN-,CVE-}2004-0786 match up to? Notwithstanding
incomplete BID or CVE entries (which is not a biggie for me, and
I've sent a couple bug reports in on this in the past), it would be
_nice_ to have them somehow related. This is probably a human task
again, since the BID db may not have a CVE entry and vice versa,
and they both have had minor errors in the past. Currently, for
that one, here's the matches I have
CVE BID
2004-0747 11182
2004-0748 11094
2004-0751 11154
2004-0786 11187
2004-0809 11185
Sometimes it's a one to many relationship, which I've seen more w/
BID's -> CVE'S than vice versa. If you notice in the plugin
description, it only catalogs two issues (CVE-2004-0809 and
CVE-2004-0786, respectively). What to me seems cleaner (and
something I'll help out with ongoing if it's a direction Tenable
wants to go) is to group up one Apache banner grab and report on
all the issues. I don't recall if NASL2 supports case statements,
but it would make the reporting cleaner and the number of plugins
drop down.
Hopefully that cover your question, George!
TIA,
Jon
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
_______________________________________________
Nessus mailing list
[email protected]
http://mail.nessus.org/mailman/listinfo/nessus
