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

[Chris Woodbury <chris3e3 () gmail com>]

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.

Let me know what you think of this approach.
-chris

Attachment: ms-sql-empty-password_multi.nse
Description:

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