Re: [NSE] Improved version of ms-sql-info

[Patrik Karlsson <patrik () cqure net>]

On 28 jan 2011, at 10.38, Chris Woodbury wrote:

> On Wed, Jan 26, 2011 at 12:07 PM, Patrik Karlsson <patrik () cqure net> wrote:
> > > This has the advantage of working every time, as long as the
> > > TCP port for the SQL Server instance is accessible (and, if it
> > > weren't, the logging-in method wouldn't work either), and it also
> > > doesn't run the risk of failed login attempts (which are dangerous now
> > > that SQL Server has account lockout policies). Plus, the lost side
> > > functionality is now available in the ms-sql-empty-password script.
> >
> > This is almost true. One extremely annoying thing I noticed today when I scanned a server with 11 instances  was 
> > that I had to wait for Nmap to fingerprint the services on all ports before being able to run ms-sql-empty-password 
> > against them. I aborted the scan and ended up testing quicker manually (I type very quickly (-: ).
> > Anyway, I don't believe that this should be considered as a problem with this new revised script.
>
> That's a good point, and I think it's really an issue with all of the
> ms-sql- scripts in general. It gets even worse once you get into
> multiple servers, each with their own random ports hosting SQL
> Servers. I wonder if the best approach might be to give each of the
> scripts support to run against individual instances (TCP ports in the
> Nmap scan) as well as support to run against all of the instances
> listed by the SQL Server Browser. That gives you the flexibility to
> target a specific instance if you want while still being able to hit
> all of the instances quickly.
>
> I went ahead and tried this idea out on ms-sql-empty-password.nse. It
> certainly makes the script a lot bigger, which is unfortunate, but I
> like the idea of just being able to run SQL Server scans with -sSU -p
> T:1433,U:1434 and not having to worry about parsing the ms-sql-info
> results and then building a big port list for a second run.

I agree that it made the script a lot bigger, but it could be worth it. However, I think we need to make the different 
modes clearer.
We should probably add some script argument that "forces" all instances to be tested so that it doesn't get triggered 
accidentally.

> Let me know what you think of this approach.

I think that scanning all instances for an empty password (or possible perform additional password guessing using the 
brute script) could be useful.
However, I'm not sure about the other scripts. Perhaps we could add support for connecting to instance names to the 
library for them instead?
This would first query the browser for the particular instance and then connect to the correct host and port.
I think that most of this code could probably be placed in the library together with the script argument controlling 
the instance name.
This way only minor modifications would need to be made to the scripts. You would specify the instance name like a 
library parameter like this:

nmap -sU -p 1434 1.2.3.4 --script ms-sql-query --script-args mssql-query="SELECT user,pass FROM 
logins",mssql.instance=SQLEXPRESS

Any thoughts?

> -chris
> <ms-sql-empty-password_multi.nse>


//Patrik

--
Patrik Karlsson
http://www.cqure.net
http://www.twitter.com/nevdull77





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