mailing list archives
Re: [NSE] Improved version of ms-sql-info
From: Chris Woodbury <chris3e3 () gmail com>
Date: Sun, 6 Feb 2011 15:35:55 -0600
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.
I sympathize with you here. One of my main motivations in working with
the SQL Server scripts was to make it easier to deal with multiple SQL
Server instances, particularly those on non-standard ports. To that
end, I've come up with something that I think handles your situation
(and others, of course) pretty well. I've made an ms-sql-discover
script (same concept as your broadcast-ms-sql-discover, but just for
one host) that runs as a hostscript and stores what it finds in
nmap.registry. The other SQL Server scripts can then run as
hostscripts (so you don't have to be limited to the ports that were in
the Nmap scan) and easily use the pre-discovered instances, instead of
relying on Nmap's service fingerprinting. So, you could handle your
situation with something as simple as "nmap -sU -p U:1434 --script
ms-sql-discover,ms-sql-empty-password" (actually, specifying the port
is unnecessary, as the script will target 1433 and 1434 anyway). And
all of the other SQL Server scripts could be used in the same way.
Anyway, I'll have this available to look at soon, but I wanted to say
that I hadn't forgotten about this.
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, (continued)