Nmap Development mailing list archives
Re: [NSE] Several changes to mssql.lua and SQL Server scripts
From: Chris Woodbury <woodbusy () gmail com>
Date: Fri, 18 Feb 2011 16:23:20 -0600
So, I made some of the changes I talked about before. To summarize: * I factored the typical hostrule and portrule logic into Helper.GetHostrule_Standard() and Helper.GetHostrule_Standard(). All but -info and the -discover scripts use these. * Typical scripts now run as the following: * No instance target specified (i.e. the mssql.instance-x script args): run as a port-script against ms-sql-s ports * Instance target(s) specified: run as a host-script against the targeted instance(s) * ms-sql-info now runs as the following: * No instance target specified: run as a host-script against all discoverable instance(s) * Instance target(s) specified: run as a host-script against the targeted instance(s) * ms-sql-discover will always run (as a host-script), unless restricted by mssql.scanned-ports-only (as before) * I moved discovery logic from ms-sql-discover to Helper.Discover() (which now does full discovery, not just SSRP). * I changed Helper.DiscoverByTcp() to return a table of instances, for consistency with the other DiscoverBy___ functions. * I renamed Helper.GetInstanceByName() to Helper.GetTargetInstances() and expanded it to handle instance-port and to handle tables in instance-name and instance-port. Names from instance-name are also case-insensitive now. The individual scripts are a lot cleaner and smaller now, and I think that the scripts are easier to use as well (e.g. not having to include ms-sql-discover in order to get good results). On Thu, Feb 17, 2011 at 3:27 PM, Patrik Karlsson <patrik () cqure net> wrote:
There might be a problem with this approach. As ms-sql-discover runs it uses the information retrieved from the browser to determine what tcp ports exist. WIth this information it then sets each of the ports as being fingerprinted as ms-sql-s. When the next script runs the portrule is triggered for each of these ports. Unfortunately, I don't think there's currently a way to first connect to the browser, mark the ports as ms-sql-s and then trigger the portrule within the same script. One way could be to place the discovery code within the hostrule or portrule function, however doing this causes the following stacktrace: stack traceback: ./nse_main.lua:654: in function <./nse_main.lua:653> [C]: in function 'socket_lock' [string "local connect, socket_lock = ...;..."]:3: in function 'connect' Another way is going down the path of forced dependencies, which I believe has been discussed in the past.
In the version I'm sending, I think this works out. The only way that you would "miss" instances is if they were on a non-standard port and you didn't target them (e.g. mssql.instance-port=1435) and you didn't run ms-sql-discover. Otherwise, if it's on 1433, we'll find it; if the user uses mssql.instance[-name|-port], we'll find it; if ms-sql-discover is run and the instance is in the SQL Browser, we'll find it.
Taking a instance oriented approach, where it's up to Nmap (or thescript 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-argsmssql.instance-name='SQLEXPRESS'3. ./nmap -p 1435 --script ms-sql-query 10.0.200.111 --script-argsmssql.instance-port=1435I realize that the port argument in the 3rd example isredundant/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'sproposed force patch [3] that would force the script to run against the port supplied using -p.I'm not completely convinced one way or the other, but I think I might prefer having an argument like mssql.force (we'd need a better name, though).I agree.
In the version I'm sending, mssql.Helper.Discover() will take any ports specified by instance-port and will run DiscoverByTcp() on them. So, you could actually run it without specifying the port in the -p (in fact, it even works if you do a nmap -sn). Does that make sense to do it that way?
* Am I wrong, or is it unnecessary to have 1433 in the portrule? Is it possible to have a situation in which there is a SQL Server available on 1433 and to have Nmap not classify it as "ms-sql-s"?The 1433 will allow the script to run even though no version/service scanning has been performed.
Actually, I tested it out, and I'm more sure now. Even if you don't do -sV, Nmap will still tag 1433 as "ms-sql-s." I changed the portrule for now to use shortport.service( "ms-sql-s" ). If we find that it needs to be the old way, it's easy to change back, since it's just in one place now (mssql.Helper.GetPortrule_Standard() ). Let me know your thoughts. If you'll have time, let's also coordinate projects. -chris
Attachment:
20110218.patch
Description:
_______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
Current thread:
- Re: [NSE] Several changes to mssql.lua and SQL Server scripts, (continued)
- 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 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 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 Chris Woodbury (Feb 18)
- Re: [NSE] Several changes to mssql.lua and SQL Server scripts Patrik Karlsson (Feb 19)
- Re: [NSE] Several changes to mssql.lua and SQL Server scripts Chris Woodbury (Feb 24)
- Re: [NSE] Several changes to mssql.lua and SQL Server scripts Patrik Karlsson (Feb 25)
- Re: [NSE] Several changes to mssql.lua and SQL Server scripts Chris Woodbury (Feb 25)
- Re: [NSE] Several changes to mssql.lua and SQL Server scripts Patrik Karlsson (Feb 26)
- Re: [NSE] Several changes to mssql.lua and SQL Server scripts Chris Woodbury (Feb 26)
- Re: [NSE] Several changes to mssql.lua and SQL Server scripts Patrik Karlsson (Feb 26)
- Re: [NSE] Several changes to mssql.lua and SQL Server scripts Chris Woodbury (Feb 28)
- Re: [NSE] Several changes to mssql.lua and SQL Server scripts Patrik Karlsson (Mar 02)
- Re: [NSE] Several changes to mssql.lua and SQL Server scripts Chris Woodbury (Mar 08)