mailing list archives
Re: [NSE] Several changes to mssql.lua and SQL Server scripts
From: Patrik Karlsson <patrik () cqure net>
Date: Fri, 25 Feb 2011 20:53:38 +0100
On Feb 25, 2011, at 00:15 , Chris Woodbury wrote:
I like the idea of stopping to clean up and focus on testing and merging. I've done some testing on my own and gotten
some other people to test as well this week.
Based on all of that, I have a few comments:
* Now that we have instance-name and instance-port, I'm not sure that it's intuitive that the way to hit all
instances is by specifying instance-name=all, especially considering the case where there are instances we don't know
the names of. How about having a script argument like mssql.all-instances?
I've added a instance-all argument to align better with the other names. Does that make sense?
* I really like the idea that it's now possible to use SQL Server as a proxy for doing Windows password testing.
However, I think we should put up some hurdles for the user. Virtually all the Windows networks I've worked with have
had account lockout policies in place, and I'm concerned that someone could accidentally end up brute-forcing a
domain and locking out a bunch of accounts. I think we ought to add a script argument to enable it.
At first, I didn't understand the problem here, as you previously wrote that you modified the script to abort once it
detected a lockout.
When I tested it I noticed what happened, and that there's no way of detecting that an account has been locked out
based on the error message returned by the server.
I agree that there's a risk of locking out a number of accounts, potentially the whole domain, if you run the script
without knowing what your doing or how it works.
Either we document this with a few exclamation marks, or we simply fail to start the script (if Windows authentication
is used) and return an explanation why and instructions how to proceed.
We could use an argument that tells the script how many attempts to perform for each account, if unset and the
authentication method is set to Windows, the script won't start.
How about that?
* I'm not sure I understand the rule changes for ms-sql-info. Going back to a point you made previously about not
forcing the user to know about how SQL Server works, I think we ought to remove the portrule for 1434/udp and just
have it function as a host-script. If the user specified instances via script-args, it will just show those;
otherwise, it will show all instances. How about that?
I agree and reverted my changes and it now behaves as you describe.
Also, it looks like ms-sql-discover didn't get changed by my last patch. There should have been several changes
there; can you take a look at that?
I wonder why this happened? Anyway, it's commited now.
Let me know what you think about all of that. In the meantime, I'm going to do some documentation.
On Sat, Feb 19, 2011 at 2:42 AM, Patrik Karlsson <patrik () cqure net> wrote:
Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/