GUI

[hdm at metasploit.com (H D Moore)]

On Friday 27 January 2006 04:16, vmukhi at vsnl.com wrote:
> 1. Execute recon modules that will parse the output from nmap, nikto,
> nessus etc. These will determine the target o/s and service versions.

The 'recon' stuff is going to be much, much different in alpha-r3. The 
type 'recon' is being replaced by 'aux' (for auxiliary) and recon will be 
a subtype. We are looking into different options for persistent storage 
for recon/aux modules - so far Og looks nice, but its going to be a 
little bit before we have the whole structure finished. The goals of 
aux/recon modules:

1) Provide a module type that can do just about anything - this where 
information retrieval, discovery, and admin-access exploits go. Brute 
forcers, SQL injection modules, and all of those classes of modules would 
fall under 'aux'.

2) Allow persistent storage and reporting of data generate by both 
exploits and the aux modules. This includes discovery information, data 
obtained through information leak aux modules, cracked user accounts, 
sniffed passwords, etc.

3) Create a structure for manipulating this data, keying off new events, 
and allowing automation through plugins.

> 2. Select exploits which have targets that match the recon results (for
> example, if nmap detects iis5.0, the gui will recommend exploits that
> should work against iis5.0). In the same vein if we detect that port 21
> is closed, no point in displaying ftp exploits.

We are hoping that this can be done through the aux/recon backend - you 
can use a 'aux' import module to load up vuln scan results or perform a 
portscan, and a correlator module will provide a list of exploit options 
that match the current data.

> 3. Allow the user in one shot to select multiple exploits, payload and
> encoders and run all of these in permutation/combination. This would be
> a useful way to test IDS signatures against different encoders. It
> should also manage all the successfully exploited sessions. Logically
> you can extend this to scan a complete subnet and execute a
> mass-attack.

You can run into a few problems with this - using the wrong exploit 
parameters will usually take down the target service, so trying to run 
every permutation won't work in most cases. Something needs to determine 
what targets to try and what payloads to use. IPS/IDS detection of 
shellcode is basically worthless right now, at least from what I have 
seen. The MSF releases put the dynamic encoders at a higher priority than 
the static ones, so this shouldn't even be a question once 3.0 stable 
hits.

> We've decided however to abandon FXRuby in favour of Qt (for ease of
> development). Do more experienced Ruby coders think this is a wise
> decision?

QT is nice, but the license is a bit restrictive. Have you considered 
using wxWidgets? Its cross-platform, very lax on licensing, and tends to 
be slightly less annoying to build than FOX :-) The FOX 1.2 vs 1.4 stuff 
is breaking fxruby in a few distributios right now.

Thanks for sharing you work, we are trying to have alpha-r3 ready for 
testing by next week.

-HD

PS. You might want to post this to framework-beta instead, not sure how 
many of the framework@ users care about the 3.0 betas :-)