Extending Metaploit 3.0 to Vulnerability Scanning

[mike.bailey at assuris.net (Mike Bailey)]

Neat..   That's starting to sound like a Nagios-like tool only for
vulnerability assessment.  Might as well write some path deployer modules
too. It would be pretty to later be able use the recon results to build a 3D
"vuln space" image of the network.

 

> -----Original Message-----
> From: mmiller at hick.org [mailto:mmiller at hick.org] 
> Sent: Friday, October 07, 2005 11:26 AM
> To: Chuck
> Cc: framework at metasploit.com
> Subject: Re: [framework] Extending Metaploit 3.0 to 
> Vulnerability Scanning
>
> 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.