Nmap Development mailing list archives
Re: [NSE] Several changes to mssql.lua and SQL Server scripts
From: Patrik Karlsson <patrik () cqure net>
Date: Sat, 12 Feb 2011 13:43:21 +0100
On Feb 11, 2011, at 08:42 , Chris Woodbury wrote:
On Fri, Feb 11, 2011 at 1:05 AM, Patrik Karlsson <patrik () cqure net> wrote:On Feb 11, 2011, at 07:51 , Chris Woodbury wrote:I have a significant set of changes to the NSE's SQL Server functionality that I would like to propose[...].Wow! This is some *really* impressive work!Thanks! I hope you still think so after you've tested it ;)
I've been able to do some testing and here's some initial feedback: * To me, it was not obvious that the ms-sql-discover script needs to be run in order to get any result from the ms-sql-info script. 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 instances. * 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 [1]. * When attempting to connect over named pipes, for some reason, I keep getting ERROR: 18456. I'm obvioulsy doing something wrong here. * I've seen the following error a few times, not sure what triggers it: | [10.0.200.111\MSSQLSERVER] | TCP: Connect failed, Named Pipes: Already connected via TCP * Like I mentioned in an earlier post [2] I think it makes sense to iterate over all instances for some scripts like eg. - ms-sql-empty-password - ms-sql-brute However, I think this needs to be something forced by the user, instead of default behaviour, so that it won't happen "by accident". Personally I wouldn't expect that the following command would perform password guessing against all instances, like it currently does: nmap -PN -p 1435 --script ms-sql-discover,ms-sql-brute 10.0.200.111 The correct way of scanning only 1435 would be: nmap -sS -sU -p U:1434,T:1435 --script ms-sql-discover,ms-sql-brute 10.0.200.111 --script-args mssql.scanned-ports-only In my personal opinion, I think that may be a little bit too complicated and I'm leaning more towards a instance oriented approach rather than a port oriented. Taking ms-sql-query as an example I see the following use cases: 1. I want to run a query against a default instance running on port 1433 This currently isn't a problem at all as the portrule will match port 1433 and run the query. 2. I want to run a query against an instance registered with the browser called INST1 running on port 1435 This is problematic as the portrule won't match unless port 1435 is detected as ms-sql-s which currently requires a version scan running with a version intensity of 8. A quick test running this against a system here takes 64 seconds which is kind of a pain to do each time you want to run a query against that instance. Using the combination of ms-sql-discover and ms-sql-query this could be achieved through the following command: sudo ./nmap -sT -sU -p T:1435,U:1434 10.0.200.111 --script ms-sql-discover,ms-sql-query --script-args=mssql.scanned-ports-only 3. I want to run a query against an instance on port 1435, that isn't registered with the browser This case has the same problem with service detection as described in the second case. The ms-sql-discover script fails to detect the port as sql server as it's running on a non default port and the browsers not responding. If I'm not totally off here there's currently no other way to query an instance on this port other than going through the tedious service scan. While this port oriented approach gives the user good control over what Nmap is doing I think it requires the user to know quite a lot of how instances work and are resolved. Another potential problem would be limiting the execution of a script to a single instance in the case of named pipes as they would be accessed over the same port. I haven't been able to verify this yet though. Taking a instance oriented approach, where it's up to Nmap (or the script really) to determine the correct ports to use, the commands for the above use cases would end up like this instead: 1. No change 2. ./nmap -p 1435 --script ms-sql-query 10.0.200.111 --script-args mssql.instance-name='SQLEXPRESS' 3. ./nmap -p 1435 --script ms-sql-query 10.0.200.111 --script-args mssql.instance-port=1435 I realize that the port argument in the 3rd example is redundant/misleading/strange, but unfortunately necessary as we're running as a host rule at this point. I guess that use case 3 could also be achieved through Martin Swende's proposed force patch [3] that would force the script to run against the port supplied using -p. I'm attaching a "quick n' dirty" patch [4] against your latest scripts that changes the behaviour of ms-sql-query and adds some necessary functions to the mssql library in order to illustrate this approach. The patch also allows the instance-name to be "all", which will result in all instance being processed by the script. An additional script argument controlling the protocol (named pipes or tcp) could perhaps also be needed for use case 3. To me, and perhaps only me?, this approach is clearer even though it will connect to ports outside of the given -p scope. Comments, ideas and suggestions are most welcome. [1] ms-sql-tcp-port.patch [2] http://seclists.org/nmap-dev/2011/q1/325 [3] http://seclists.org/nmap-dev/2010/q4/543 [4] ms-sql-connect-by-instance-name.patch //Patrik
Attachment:
ms-sql-connect-by-instance-name.patch
Description:
Attachment:
ms-sql-tcp-port.patch
Description:
p.s. I saw the svn update you did on the scripts the other day, and I made sure to replace all of the nmap.registry.args with nmap.get_script_args() calls. I'd been using that before, but I didn't know you could pass it a table with multiple names for a single argument - that's pretty cool, and certainly eases the headache of changing argument names.//Patrik -- Patrik Karlsson http://www.cqure.net http://www.twitter.com/nevdull77-chris
-- Patrik Karlsson http://www.cqure.net http://www.twitter.com/nevdull77
_______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
Current thread:
- [NSE] Several changes to mssql.lua and SQL Server scripts Chris Woodbury (Feb 10)
- Re: [NSE] Several changes to mssql.lua and SQL Server scripts Patrik Karlsson (Feb 10)
- Re: [NSE] Several changes to mssql.lua and SQL Server scripts Chris Woodbury (Feb 10)
- Re: [NSE] Several changes to mssql.lua and SQL Server scripts Patrik Karlsson (Feb 12)
- Re: [NSE] Several changes to mssql.lua and SQL Server scripts Chris Woodbury (Feb 15)
- Re: [NSE] Several changes to mssql.lua and SQL Server scripts Patrik Karlsson (Feb 15)
- Re: [NSE] Several changes to mssql.lua and SQL Server scripts Chris Woodbury (Feb 15)
- Re: [NSE] Several changes to mssql.lua and SQL Server scripts Chris Woodbury (Feb 16)
- Re: [NSE] Several changes to mssql.lua and SQL Server scripts Patrik Karlsson (Feb 16)
- Re: [NSE] Several changes to mssql.lua and SQL Server scripts Patrik Karlsson (Feb 16)
- Re: [NSE] Several changes to mssql.lua and SQL Server scripts Chris Woodbury (Feb 10)
- Re: [NSE] Several changes to mssql.lua and SQL Server scripts Chris Woodbury (Feb 16)
- Re: [NSE] Several changes to mssql.lua and SQL Server scripts Patrik Karlsson (Feb 17)
- Re: [NSE] Several changes to mssql.lua and SQL Server scripts Patrik Karlsson (Feb 10)
- Re: [NSE] Several changes to mssql.lua and SQL Server scripts Chris Woodbury (Feb 16)
- Re: [NSE] Several changes to mssql.lua and SQL Server scripts Patrik Karlsson (Feb 17)