RE: [NSE Script] MySQL Server Information

["Rob Nicholls" <robert () everythingeverything co uk>]

When I said "best place", my concern at the time was that there might not be
an easy way to resume password cracking if you had to stop part way through,
but perhaps we could use LUA to save a temporary file that it deletes once
the script has completed, and if the file is present it'll resume from
wherever it was when the script was stopped? I would probably find it
annoying (if you planned on using nmap to perform a lengthy password
cracking exercise) if you couldn't see the results of the host's port scan
until the password cracking had finished, which might mean users having to
run a preliminary scan to detect the ports (as some of us will want to
perform manual testing) and follow it with a second scan with the scripts
enabled, increasing the amount of network traffic (something jah picked up
on too, although I suspect most password cracking tasks would be performed
on-site so it's probably less of an issue there).

My main use of nmap is to perform port scans of a server to discover what
services are listening. If you know you specifically want to try and crack
passwords for given accounts for a given server (perhaps on a given
service), it seems a bit odd to me use nmap as a starting point (but I guess
I'm also still getting used to nmap being able to run scripts). I know why
it'd be useful to add such a script to nmap, especially for users that
aren't aware of other tools, but part of me feels like we'd be "reinventing
the wheel" when there are already perfectly good tools (such as hydra)
dedicated to this task. Especially when such effort could be put into other
scripts that could be more innovative and useful to a larger number of
users.

I don't mean to sound negative as I honestly do love the direction that NSE
is taking nmap (I plan on improving my knowledge of LUA and contributing
more scripts in the future), but most of the scripts we have at the moment
aren't an improvement (yet!) over other tools (such as Nessus *ducks the
flying objects thrown at him*). So I'd prefer to see scripts that detect
things that tools like Nessus won't spot, rather than see it replicate some
of the functionality (for example, the SSLv2 script is nice, but I'd also
like to know if a server supports 40 and 56-bit SSLv3/TLS ciphers). I also
do a lot of testing from Windows (as I seem to test a lot of Windows servers
and networks), and until nmap gains SSL support on Windows it really limits
its usefulness as a standalone tool - without it there's no way to check for
SSLv3 ciphers or run scripts against SSL services such as secure web servers
(which is the way that a lot of web servers are going nowadays). 
 
If we do add a password cracking script, would it perhaps be possible/make
more sense to have a standalone script (and rely on the service/version
information to provide any necessary wrappers to talk to well known
services)? Otherwise I can see each service/script having its own brute
force section of code (*points at jah's comment about code redundancy*).

I can definitely see the benefit of Chris' suggestion and Thomas' improved
script for checking a handful of passwords for default accounts (a lot
easier than firing up another program just to check that "sa" isn't set to
"password" or left blank), and it might be worth checking default usernames
and passwords on other well known services too (Scott:Tiger, cisco:cisco,
admin:password etc.); I think Chris' original comment about checking for
weak passwords threw me as it wasn't clear at the time just how limited the
check for weak passwords would be.

I like jah's suggestion about arguments that modify the behaviour, but I'd
probably like an additional option of being able to specify two files, one
for usernames (that I can type up, or perhaps dump out of getacct.exe or
enum.exe) and one to point at whatever huge dictionary file I've got to
hand, rather than a single file full of pairs. I can't see my dictionary
files changing that often, but I can see the list of users changing a lot ;)


Rob



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