mailing list archives
Re: [NSE] Several changes to mssql.lua and SQL Server scripts
From: Chris Woodbury <woodbusy () gmail com>
Date: Tue, 15 Feb 2011 15:17:34 -0600
On Sat, Feb 12, 2011 at 6:43 AM, Patrik Karlsson <patrik () cqure net> wrote:
I've been able to do some testing and here's some initial feedback:
Thanks for the quick turnaround and all the feedback! Sorry for my own
* To me, it was not obvious that the ms-sql-discover script needs to be run in order to get any result from the
As the dependencies are not "forced", and there's currently no way of achieving this, it requires the user to
specify both scripts each time which isn't very clear.
I would personally prefer being able to run just ms-sql-info to be able to retrieve the version information from the
Good point about the dependency not being clear. It probably makes
sense to include ms-sql-info in with the other scripts in terms of how
we handle the various modes of operation (i.e. has a discover script
been run or not, what ports have been scanned, etc.).
* The TCP port is not printed by neither ms-sql-discover or ms-sql-info even though it's in the SSRP string. I'm
including a patch for this .
This was a stupid mistake on my part, brought on by a last-minute
change (for some reason, I thought that doing a["b.c"] would get
around the issue of having to check whether b exists (since you'll get
an error indexing nil when you do a.b.c). It does of course get around
that issue, but it doesn't actually work.). Anyway, let's just revert
that whole last-minute change and go back to a.b.c-style indexing, to
be consistent with the rest of the use of SqlServerInstanceInfo and
SqlServerVersionInfo. Patch for this: 
* When attempting to connect over named pipes, for some reason, I keep getting ERROR: 18456. I'm obvioulsy doing
something wrong here.
Login error 18456 is "invalid username or password" (i.e. a normal
failed login attempt). I'll have a patch in a little bit that returns
a meaningful message for login errors (as well as fixing a few other
Incidentally, if you're getting error 18452, that's "User is not
associated with a trusted connection", which probably means that the
instance doesn't support SQL Server authentication.
* I've seen the following error a few times, not sure what triggers it:
| TCP: Connect failed, Named Pipes: Already connected via TCP
This happens when there is a TCP port and a named pipe for the
instance, but the TCP port can't be reached (e.g. it's firewalled, or
the instance is stopped). Patch for this: 
So, that was the easy stuff. Let me process the bigger issues you
raised, and I'll get back to you.
These are patches against /nmap-exp/patrik/nmap-mssql/ :
Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/