Mailing List Archive

On Wed, 14 Apr 2004, Michel Arboi wrote:

> I know that this subject has been debated for a long time and that we
> could not reach a compromise. MHO, the current family sets sucks, mostly
> because it mixes several things:
> [snip]

What about removing the restriction for a plugin to belong to only one
"family"? Instead of a 'family' field, how about something like a
'keywords' or 'families' field (can't think of a good field name to
represent what I'm trying to say)? I think exceptions could be handled
more elegantly then. Just a thought. I wasn't around the last time
this was debated :)


Best regards,
Erik Stephens www.edgeos.com
Managed Vulnerability Assessment Services

Erik <erik@edgeos.com> writes:

> What about removing the restriction for a plugin to belong to only one
> "family"? Instead of a 'family' field, how about something like a
> 'keywords' or 'families' field

This has been discussed. That looks like a good idea but need some
changes in the core product (and the protocol?)

Anyway, we should decide what families are used for. I think they are
good to select or unselect a set of plugins.
Apart from DoS (which could be removed by an enhanced safe_checks, as
I said), I think that families are useful to find and enable or
disable a specific plugin, or to select a whole set, e.g Windows or
HTTP & CGI

Hi,

I would favor arranging the families by "how the plugin works". For example:

service_detection
banner_check
registry_check
http_file_existence
cross_site_scripting

This would result in a fair few more families than we currently have.

Paul


Michel Arboi wrote:

>I know that this subject has been debated for a long time and that we
>could not reach a compromise.
>MHO, the current family sets sucks, mostly because it mixes several
>things:
>- effects, like "denial of service" or "gain root"
>- target protocols, like "finger" or "RPC",
>- target OS, like "windows"
>- including the infamous "general" and "misc."
>
>This kind of mixing is hard to avoid, but I suggest that we choose a
>main "classification" and try to minimize the exceptions.
>I think (but you are allowed to disagree :) that targets (protocols
>and OS) are the best classification.
>Effects should be avoid, except "Denial of servce" maybe, although it
>could better be handler by a more subtle "safe_checks" (instead of a
>simple flag, we could have "all", all but DoS", "non intrusive /
>safe_checks")
>
>Things like "service identifications" could be in a special family,
>because we already have many of them and I plan to split find_services
>in small pieces.
>
>Comments?
>
>
>

--
Paul Johnston
Internet Security Specialist
Westpoint Limited
Albion Wharf, 19 Albion Street,
Manchester, M1 5LN
England
Tel: +44 (0)161 237 1028
Fax: +44 (0)161 237 1031
email: paul@westpoint.ltd.uk
web: www.westpoint.ltd.uk

Paul Johnston <paul@westpoint.ltd.uk> writes:

> I would favor arranging the families by "how the plugin works".

Another suggestion was to have several levels, but this is not
possible currently.


> service_detection
> banner_check

OK for this, they are my "exceptions".

> registry_check
> http_file_existence
> cross_site_scripting

OK. This means that instead of having huge "Windows" or "HTTP"
families, we spit then in several families. Looks good.

Anybody against this proposal?

The next questions will be:
- What are the new families?
- When do we switch?
- Who does the job <grin>

On Wed, 14 Apr 2004, Erik wrote:

> On Wed, 14 Apr 2004, Michel Arboi wrote:
>
> > I know that this subject has been debated for a long time and that we
> > could not reach a compromise. MHO, the current family sets sucks, mostly
> > because it mixes several things:
> > [snip]
>
> What about removing the restriction for a plugin to belong to only one
> "family"? Instead of a 'family' field, how about something like a
> 'keywords' or 'families' field (can't think of a good field name to
> represent what I'm trying to say)? I think exceptions could be handled
> more elegantly then. Just a thought. I wasn't around the last time
> this was debated :)

One dilemma that we face is to be able to identify plugins by their
scanning effects (DOS, disruptive, banner, etc.) to aid the scanning
process; then identify plugins by service being tested (ssh, ftp,
backdoors, etc.) to aid both scan choices and remediation processes; and
then identify remediation effort (patch via windowsupdate, other patching,
configuration, and so on) to help understand policy efforts and
remediation efforts. The first draft of this has helped at negotiating
vulnerabilities at each stage of the effort.

> Best regards,
> Erik Stephens www.edgeos.com
> Managed Vulnerability Assessment Services
> _______________________________________________
> Nessus-devel mailing list
> Nessus-devel@list.nessus.org
> http://mail.nessus.org/mailman/listinfo/nessus-devel
>

Michel Arboi wrote:

>Erik <erik@edgeos.com> writes:
>
>
>
>>What about removing the restriction for a plugin to belong to only one
>>"family"? Instead of a 'family' field, how about something like a
>>'keywords' or 'families' field
>>
>>
>
>This has been discussed. That looks like a good idea but need some
>changes in the core product (and the protocol?)
>
>
I think ultimately a flat one-to-one grouping mechanism for plugins is
going to be prone to the same ambiguities and overlap that you're seeing
now. Reassigning the plugins to a new list of families is still
worthwhile, because the current list could be improved...but it won't
really enhance the overall product.

If the changes would be significant, would it be possible to introduce
Erik's idea as something new and maintain the existing families as a
legacy holdover for backwards compatibility?

>Anyway, we should decide what families are used for. I think they are
>good to select or unselect a set of plugins.
>Apart from DoS (which could be removed by an enhanced safe_checks, as
>I said), I think that families are useful to find and enable or
>disable a specific plugin, or to select a whole set, e.g Windows or
>HTTP & CGI
>
>
I think the answer to this question will make the development of a new
list of families much easier. However, because of the technical
limitations of families, you can really only have one purpose. Any more
than that, and it becomes complicated. What if you have a plugin that
uses default account credentials to execute an HTTP query against a
sample application to enumerate EJBs in a remote container through JNDI,
possibly killing it in the process? Obviously a rediculous example, but
this plugin works over HTTP, exploits default passwords, uses a sample
application, tests JNDI security and ultimately just gathers information
in a manner that could potentially kill the service(s). You could pick
a family for this plugin, but there aren't really any that serve it
best, which is probably why we currently have a set of families that are
somewhat orthogonal.

A family, right now, is just a single valued property of a plugin...the
grouping function of families is done through a function of searching
those properties for equal values. Extending that idea, would it be
difficult to implement a generic plugin properties model, one that is
typed, supports multi-valued and/or nested attributes? Using this
approach, you could implement arbitrary plugin groups like Erik was
after above, for the purpose that Michel proposes for families (grouping
plugins for execution). You could then group plugins by creating simple
queries against these properties...i.e.:

- Plugins that work over HTTP. (PROTO == (HTTP || HTTPS))
- Plugins that attack IIS. (APP == ".*IIS.*")
- Plugins that address a SANS Top 20 issue (SANS20 == TRUE )
- Plugins that could kill the service. ( DANGEROUS == TRUE )
- Plugins that are designed to kill the service. ( DOS == TRUE )
- Plugins that are really only useful if you have credentials. (
REQCREDS == TRUE )
- Plugins that have a CVE associated with them ( #CVEID > 0 )
- Plugins that check for HIGH severity issues ( SEVERITY == HIGH )

You could also implement something that i've been yearning for. Some
type of model that helps reflect the maturity/quality of a plugin so you
can run wide open on test environments, but be more cautious in
production/customer environments (consider the sourceforge 'development
status' model)

- Plugins that are stable (DEVSTATUS == STABLE)

The other aspect of this, though, is that additional properties can help
on the reporting side of things. It takes some effort to get at the
information that is contained in the default output of reports. Most of
the time, it's nothing big (having to parse a list of CVE-IDs, using
regexes to extract data from recommendations in the info), but it slows
the process and can be problematic. Being able to directly access a set
of typed properties for each plugin, possibly including associated KB
entries/etc, would make it much easier to fold and spindle the output
into things that are useful for a given purpose. Looking at
vulnerability databases such ICAT and OSVDB, there are several
potentially useful properties of a plugin that could be added directly
to the plugin, or indirectly by reference to the associated db.

- Vulnerability Type - Buffer Overflow, Race Condition, etc
- Attack Scope - Local, Remote
- Loss - Availability, Confidentiality, Superuser Access, Process User
Access
- Known Exploits - True/False (or URLs)

This whole generic properties thing could be bunk, and is probably a lot
of effort for minimal return, but i think if we're considering going
back through and touching each of the nearly 2100 plugins that are out
there now, it'd be good to get the most bang for the buck.

My $.02.

Quoting Bob Gerdes <gerdes@rci.rutgers.edu>:
[multiple families]
> One dilemma that we face is to be able to identify plugins by their
> scanning effects (DOS, disruptive, banner, etc.) to aid the scanning
> process; then identify plugins by service being tested (ssh, ftp,
> backdoors, etc.) to aid both scan choices and remediation processes; and
> then identify remediation effort (patch via windowsupdate, other patching,
> configuration, and so on) to help understand policy efforts and
> remediation efforts. The first draft of this has helped at negotiating
> vulnerabilities at each stage of the effort.

From a A&P persepctive (working for a large company), I need to reference
plugins by different requirements, depending upon what I'm checking:

For internal systems I require to know the impact to the systems I'm scanning -
even though I normally scan systems before implementation, bringing a system
down -- or even doing a permanent DoS (in one case - on a printer) is a bad
thing.

For external systems, I'm restricting what I do on the scan, especially if I'm
scanning over the internet. On this basis its better to restrict to protocol -
if I see only http and ftp open then its not worth it performing DCE tests on
the system. This is due to trying to restrict the amount of traffic, and due to
having a limited time slot to perform the test in.

I think that for the next major release of Nessus, it may be worth looking at
the header of the Plugin, allowing more choice of how one may select plugins -
even if this does mean updating the protocol.

What I have in mind is a header with the rough information, for example:
Name="NTP Information Gathering"
Description="Check for whether NTP leaks system information"
Protocol="NTP"
Ports="123/udp"
Risk="Low"
Keywords[]="Informational","Access Control"
Resolution="Restrict the hosts which the NTP server allows information requests
from:\
restrict default ignore"

dave

On Thu, Apr 15, 2004 at 04:53:19PM -0400, David Lodge wrote:
> For external systems, I'm restricting what I do on the scan, especially if I'm
> scanning over the internet. On this basis its better to restrict to protocol -
> if I see only http and ftp open then its not worth it performing DCE tests on
> the system. This is due to trying to restrict the amount of traffic, and due to
> having a limited time slot to perform the test in.

You're right, however it's not your job to do that, it's Nessus's, and
you could do that _today_ by using the option "consider unscanned ports
as closed".

> I think that for the next major release of Nessus, it may be worth looking at
> the header of the Plugin, allowing more choice of how one may select plugins -
> even if this does mean updating the protocol.

We might go by keywords, or something else. However it's low on my list.


-- Renaud

Hi,

What do people actually use the plugin families for? Most uses I've seen
mention seem to be from people who don't know how Nessus optimizations
work in face of a closed port. For destructiveness, I don't think that's
the job of the family to express. Also I don't think it's down to the
family to do SANS top-20. My main interest in families was for
processing results where lots of plugins have fired. For example, when
no404 hasn't worked and all the CGI existence plugins fire. It would be
nice to have a family of plugins that just check for a file existence
and be able to remove them. In this vein, plugins that did some sort of
positive check on the content returned by that file would go in a
different family. Discussed with a colleague and he pointed out we don't
need families for this - we can look at dependencies on no404.nasl. So
my interest in families has dried up somewhat.

Paul

--
Paul Johnston
Internet Security Specialist
Westpoint Limited
Albion Wharf, 19 Albion Street,
Manchester, M1 5LN
England
Tel: +44 (0)161 237 1028
Fax: +44 (0)161 237 1031
email: paul@westpoint.ltd.uk
web: www.westpoint.ltd.uk

>What do people actually use the plugin families for?
I'll interpret this as what would I like to use plugin families for.

a) Enabling or disabling a whole group of tests because of potential side
effects.

I'm really looking for a finer classification than "dangerous plugins", as
the "big switch" isn't always good enough. For example, "will cause DoS on
vulnerable systems", "might kill service if running on early xyz operating
system", "might send output to vulnerable printers" are options that I might
select or deselect depending on purpose of tests.

b) Disabling tests not relevant to the type of system

The main objective is to get more accurate reports, e.g. don't report Tomcat
web problems on an IIS box. That doesn't help the credibility of the reports
when passed to our IT guys. Yes, really this should be part of Nessus core
and automatically handled by the optimisation, but it's not always so.
The second objective is to speed up the testing, by not applying router
tests to windows systems, etc. Not as important as the system information is
not always accurate.

c) Making the plugin selection options manageable

Fundamentally having sufficient number of categories - not so few categories
that the plugin lists are too long, not so many that they only contain a
small number of items (like current NIS category). I seem to remember
usability studies for menu systems (remember Prestel/Viewdata?) concluded
that around 10 items at each hierarchy level was about right - maybe p to 20
with modern screen sizes. An extra hierarchy level could be effectively
added if plugin names were sorted into alphabetical order, and some naming
consistency were imposed.

d) Selecting vulnerability severity

I'd sometimes like to filter out the inconsequential informational items.
Things like "traceroute info", "digital cert info". So an "Info only"
category would be nice. I suppose this is the converse of the request for
SANS top 20, which is looking for "most severe", though personally I'd like
to know about any severe items, whether or not they were in SANS' list.

e) Selecting by service

On occasion I'd like to select by the TCP service. So far, I've only needed
this when trying to find which plugins test which services - in other words
I don't need to select "all HTTP" for an actual test, just like to know all
the HTTP tests and to find the plugin code for a specific vulnerability.
Actually, rather than using families for this, I'd really prefer more
consistency in the plugin filenames and descriptions - and for the client
and reports to list filenames as well as descriptions. The sort of
consistency would use names like <proto>_<platform>_<vuln>, such as
http_iis_dir-traversal.nasl.

Andrew Yeomans


--------------------------------------------------------------------------------
The information contained herein is confidential and is intended solely for the
addressee. Access by any other party is unauthorised without the express
written permission of the sender. If you are not the intended recipient, please
contact the sender either via the company switchboard on +44 (0)20 7623 8000, or
via e-mail return. If you have received this e-mail in error or wish to read our
e-mail disclaimer statement and monitoring policy, please refer to
http://www.drkw.com/disc/email/ or contact the sender.
--------------------------------------------------------------------------------

Robert Rich <rrich@gstisecurity.com> writes:

> I think ultimately a flat one-to-one grouping mechanism for plugins is
> going to be prone to the same ambiguities and overlap that you're
> seeing now.

Keywords may be an answer, but we should define precisely what the
question is :)

> If the changes would be significant, would it be possible to introduce
> Erik's idea as something new and maintain the existing families as a
> legacy holdover for backwards compatibility?

Is this really necessary?

> I think the answer to this question will make the development of a new
> list of families much easier. However, because of the technical
> limitations of families, you can really only have one purpose. Any
> more than that, and it becomes complicated. What if you have a plugin
> that uses default account credentials to execute an HTTP query against
> a sample application to enumerate EJBs in a remote container through
> JNDI, possibly killing it in the process? Obviously a rediculous
> example, but this plugin works over HTTP, exploits default passwords,
> uses a sample application, tests JNDI security and ultimately just
> gathers information in a manner that could potentially kill the
> service(s).

Well, I'd say that it is mainly an attack against a Java based HTTP
service, so maybe a "HTTP - Java" family?

> - Plugins that work over HTTP. (PROTO == (HTTP || HTTPS))
> - Plugins that attack IIS. (APP == ".*IIS.*")
> - Plugins that address a SANS Top 20 issue (SANS20 == TRUE )
> - Plugins that could kill the service. ( DANGEROUS == TRUE )
> - Plugins that are designed to kill the service. ( DOS == TRUE )
> - Plugins that are really only useful if you have credentials. (
> REQCREDS == TRUE )
> - Plugins that have a CVE associated with them ( #CVEID > 0 )
> - Plugins that check for HIGH severity issues ( SEVERITY == HIGH )
> - Plugins that are stable (DEVSTATUS == STABLE)

This would be very flexible, but would need much rework in the GUI,
wouldn't it?

> This whole generic properties thing could be bunk, and is probably a
> lot of effort for minimal return, but i think if we're considering
> going back through and touching each of the nearly 2100 plugins that
> are out there now, it'd be good to get the most bang for the buck.

Good point.

--
arboi@alussinan.org http://arboi.da.ru
FAQNOPI de fr.comp.securite http://faqnopi.da.ru/

"Yeomans, Andrew" <Andrew.Yeomans@DRKW.com> writes:

> a) Enabling or disabling a whole group of tests because of potential side
> effects.

Not the role of families, IMHO.

> I'm really looking for a finer classification than "dangerous plugins", as
> the "big switch" isn't always good enough. For example, "will cause DoS on
> vulnerable systems", "might kill service if running on early xyz operating
> system", "might send output to vulnerable printers" are options that I might
> select or deselect depending on purpose of tests.

We already have "safe_checks", and I sggest that we add another level
that will launch dangerous attacks but not DoS or floods.

> b) Disabling tests not relevant to the type of system

This is supposed to be the role of "optimize".

> The main objective is to get more accurate reports, e.g. don't report Tomcat
> web problems on an IIS box.

This is a _false positive_ and the plugin should be fixed.
Currently, we do not use the result of www_fingerprinting_hmap as we
consider it as experimental, but this may change in the near future.

> The second objective is to speed up the testing, by not applying router
> tests to windows systems, etc.

Why not? A windows system may act as a router.

> c) Making the plugin selection options manageable
> Fundamentally having sufficient number of categories - not so few categories
> that the plugin lists are too long, not so many that they only contain a
> small number of items (like current NIS category). I seem to remember
> usability studies for menu systems (remember Prestel/Viewdata?) concluded
> that around 10 items at each hierarchy level was about right - maybe p to 20
> with modern screen sizes.

That's the main problem for me: when I want to disable a specific
script, it is easier to remove it from the directory than play with
the GUI.

> d) Selecting vulnerability severity
> I'd sometimes like to filter out the inconsequential informational items.
> Things like "traceroute info", "digital cert info". So an "Info only"
> category would be nice.

However, some plugins depends upon such information.
Maybe you should post-process your report?

> e) Selecting by service
> On occasion I'd like to select by the TCP service. So far, I've only needed
> this when trying to find which plugins test which services - in other words
> I don't need to select "all HTTP" for an actual test

A month ago, I needed to just fire the Windows tests on a class B, to
speed the test up, and I realized that the current family structure
was not great.
I only scanned 135-139+445 but it was not as quick as I'd hope. And
probably more intrusive.

--
arboi@alussinan.org http://arboi.da.ru
FAQNOPI de fr.comp.securite http://faqnopi.da.ru/