Re: [NSE Script] MySQL Server Information

[jah <jah () zadkiel plus com>]

On 18/12/2007 20:30, Thomas Buchanan wrote:
> As far as I know, patterns in Lua are case-sensitive, although I can't 
> find any specific online references that supports that statement. 
> Here's a quick test from a command-line Lua interpreter:
>
> D:\Scratch\lua5_1_2_Win32_bin>lua5.1.exe
> Lua 5.1.2  Copyright (C) 1994-2007 Lua.org, PUC-Rio
> > a = "a"
> > m = string.match(a, "a")
> > print(m)
> a
> > m = string.match(a, "A")
> > print(m)
> nil
> >
I must have done something daft, because I cannot, for the life of me, 
reproduce the matches I got when testing.  I'm sure you and Thomas must 
be correct!
> This was really the main reason I wanted to jump in.  About 3 weeks 
> ago, I started working on a MySQL script myself.  Unfortunately, 
> things got very busy, and I haven't had time to make significant 
> progress on it. However, I was able to successfully login to MySQL 
> servers using the extended login capabilities introduced in 4.1.  To 
> login with a password requires the ability to create SHA1 hashes of 
> the password and the salt received from the server, which was my 
> motivation for the NSE/OpenSSL patches I posted to the list recently: 
> http://seclists.org/nmap-dev/2007/q4/0472.html
>
> I'm really busy through the end of the year, but I'd love to be able 
> to help with this effort.  I can post the very rough code that I have 
> cobbled together for you guys to look at, or I can try to integrate my 
> login code into Kris's script once I have time.
Do post it Thomas, I definitely think it would be a worthwhile addition 
to an already useful script.  But...

On 18/12/2007 18:49, Rob Nicholls wrote:
> A check for a blank password might be okay (and possibly the password "sa"?),
> but nmap probably isn't the best place to test for passwords, and I suspect
> people would like to avoid accidentally locking out accounts or potentially
> cause a denial of service (for any service).
I agree, in part, with Rob.  I don't think it would be wise to a) slow 
down the script by testing for passwords by default and b) make the 
script (and therefore, nmap) more intrusive by default.  I'd like to see 
the functionality implemented with the use of arguments for the script 
which then unlock the extra feature.  The way I see it working would be 
to have something like:

an arg for default passwords:  --script-args mysqlinfo={user=defaults}
an arg for user:pwd pairs:  --script-args 
mysqlinfo={user[1]=root,pass[1]=blank,user[2]=username,pass[2]=pwd}
an arg for a text file containing user:pwd pairs:  --script-args 
mysqlinfo={user=pairs_file.txt}

The script would only do what it does now without any args passed to it, 
nice and safe.  I have to say though, nmap might not be the 'best place' 
to test for passwords, but it's a very good place in my opinion - nmap 
is an awesome tool simply because of the variety of things it has the 
ability to do!

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....


jah

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