Extending Metaploit 3.0 to Vulnerability Scanning

[mmiller at hick.org (mmiller at hick.org)]

Hi Chuck,

On Fri, Oct 07, 2005 at 11:02:38AM -0400, Chuck wrote:
> Hello all,
>
>    What I have been thinking about, though, is the feasibility of
> creating a new vulnerability scanner in Ruby that would be kind of an
> extension of Metasploit 3.0 (it would use the same exploits, primarily
> the check functions).  I think that using an established and modular
> language makes a lot of sense for the "plugins" rather than Nessus'
> custom language (NASL).

...

>    My question for the list (primarily HD and the other developers
> that are working on version 3.0) is basically, how hard it would be to
> create such an animal?  It sounds relatively easy to me to build the
> engine and then you need the modules.  The good thing is that I think
> the community has already shown support by writing modules for
> Metasploit (in part because they are "more fun" than simply
> vulnerability checks).  Unfortunately, I probably will not have much
> time to contribute to the project (long story), but I wanted to throw
> the idea out there and see if was feasible and if anyone would pick up
> the ball and run with it.

We've been planning on implementing a feature like this in 3.0, though
perhaps not to the extent that you describe.  In 3.0 we are adding a new
type of module called 'recon' modules.  These modules could range from
simple portscanners to true vulnerability scanners.  As information is
collected from the recon modules, the framework will provide a subsystem
for correlation and categorization of information such that events can
be automatically performed when things occur.  For instance, the dcom
exploit could be automatically launched when a recon module determines
that port 135 is open on a host.  That's just a very simple example.  It
could be improved by requiring more information about a host to be
determined before launching an exploit.  For instance, another recon
module could fire once port 135 is detected to be open in order to
attempt to determine the remote operating system version (through
arbitrary means).  Once that information is collected, it would be
passed back to the framework correlation engine which would in turn fire
off any events (such as an exploit) that now had enough criteria met in
order to be launched.

Furthermore, we plan on implementing it in such a fashion that the
correlation engine state can be dumped to a database and resumed at a
later date.  This will allow you to take "views" of a network, when
doing a pentest for instance, and later pick up where you left off such
that you don't have to do recon again, although things may have changed
between the last recon cycle and the current setting.  It will also 
allow for easy report generation, as exploits will also feedback
information to the framework correlation engine that a host has been
compromised (so that recon modules can pivot through the host and the
cycle can begin anew).  This isn't particularly revolutionary or
anything, but it should be quite useful.

While we do plan to release the recon module system publicly, we have
not yet decided if we are willing to release the correlation engine
publicly due to there being a large potential for abuse.  Instead, we
might consider releasing such a feature on a request-only basis (which
we would either approve or not).  Again though, nothing firm yet, but
that's just kind of my personal stance on this.  We are still discussing
it internally.