Re: [NSE Script] MySQL Server Information

[jah <jah () zadkiel plus com>]

On 18/12/2007 23:53,  wrote:
> Fyodor wrote:
>   
> > On Tue, Dec 18, 2007 at 11:44:40PM +0000, jah wrote:
> >     
> > > On 18/12/2007 20:30, Thomas Buchanan wrote:
> > >
> > > But then as Fyodor says,
> > > On 18/12/2007 23:09, Fyodor wrote:
> > >       
> > > > We have categories to deal with this issue.  So a DB password checking
> > > > script would be good to have, but probably shouldn't be in the "safe"
> > > > category.
> > > >   
> > > >         
> > > So maybe we should complement MySQLinfo with an entirely separate script....
> > >       
> > Well, if it is only testing a few common defaults and is unlikely to
> > cause DB lockouts, it is probably OK to include in a single script.
> > But yes, a major brute forcing script should probably be separate from
> > one which simply gathers some available information from the DB.
> >
> >     
>
> I think I agree with jah.  Since it seems like it will require quite a 
> bit of work, including adding the SSL bindings, it might be best to have 
> a script like mine which just gathers the general information, and then 
> have one based on Thomas's (and maybe partially my) code for brute forcing.
>
> What do you guys think?
>   
I think that this thread is getting difficult to follow! ;)

 From my point of view I think it's clear that an ideal would be to have 
one script, which defaults to the "safe" mode of gathering information, 
but which can also be stepped-up to be more intrusive should the user 
require it.  Otherwise we'd have a brute-force script that did exactly 
the same as the info script (with, obviously, the bruting too) and that 
seems rather counter-intuitive.  Much better, I think, to have all the 
functionality in one script and a) not needlessly introduce code 
redundancy and b) not needlessly increase the amount of network activity 
in such cases (for example) where all scripts are run.

For now though the current script is very useful and stands alone.  In 
the future (and assuming that MySQLinfo is checked-in), it might be 
replaced with a script that increases the functionality, but behaves the 
same in it's default mode.

And here's a mad thought, there could be a complete overhaul of the 
script category framework which would allow a modifier category of some 
kind:

categories = {"safe", "discovery"}
modified-by = {"intrusive", "vulnerability"}

so that a script in the above categories would behave safely if a script 
scan called for safe and discovery scripts, but would behave more 
intrusively if a scan called for intrusive and vulnerability scripts.

hmmmmm, what thinketh youeth?

jah



_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org