mailing list archives
Re: [NSE] Improved version of ms-sql-info
From: Patrik Karlsson <patrik () cqure net>
Date: Sun, 30 Jan 2011 19:48:05 +0100
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
We should probably add some script argument that "forces" all instances to be tested so that it doesn't get triggered
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 22.214.171.124 --script ms-sql-query --script-args mssql-query="SELECT user,pass FROM
Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/
Re: [NSE] Improved version of ms-sql-info Chris Woodbury (Jan 28)
Re: [NSE] Improved version of ms-sql-info Chris Woodbury (Feb 06)
- Re: [NSE] Improved version of ms-sql-info Patrik Karlsson (Jan 30)