Re: [NSE] Microsoft SQL Server (MSSQL) library and scripts

[Patrik Karlsson <patrik () cqure net>]

On 2 apr 2010, at 05.48, David Fifield wrote:
> >
>
> So, after looking over the scripts I've come to the same conclusion as
> Fyodor in http://seclists.org/nmap-dev/2010/q1/1023, namely that
>
> mssql-databases
> mssql-linked-servers
> mssql-sp-configure
> mssql-tables
>
> are the best candidates to be combined. mssql-databases,
> mssql-linked-servers, mssql-sp-configure, and mssql-query are very
> similar, basically just doing different queries. I think mssql-query
> should remain on its own because it can be controlled with a script
> argument. mssql-tables is not as similar as these others by this simple
> metric, but it still seems pretty close to mssql-databases. mssql-tables
> is the only one I'm not sure about; what do you think?

I've merged mssql-databases, mssql-linked-servers and mssql-sp-configure into mssql-config.
There's a single argument (mssql-config.showall) which controls the amount of data returned by the script.
This could probably be controlled by the verbose flag to, like in many other scripts, but I tend to run in verbose mode 
often
and depending on the amount of databases on the server this script could return quite a lot of data.

There's a little change with the output produced by sp_configure as I'm now accessing the tables used by the 
sp_configure system SP directly.
By default the output of the Configuration section will contain the Features that are controlled using the "Surface 
area configuration" tool. 
When the showall argument is used, all options are returned.

I've kept mssql-tables a part and added support for keyword filters to further motivate keeping it separate.
So the script now accepts the argument mssql-tables.keywords which should contain a table with strings to match.
The keyword matching is strict and does not allow wildcards but is used OR:ed rather than AND:ed.
So running the script with the following argument:
--mssql-tables.keywords="{cvv,payment,login,password']"

will return any table OR column name matching any of the keywords supplied.
I've also added a table section to the end that specifies what filters and output limitations are active.
So output now looks like this:

| mssql-tables:  
|   testdb
|     Filter returned no matches
|   webshop
|     table     column  type    length
|     =====     ======  ====    ======
|     payments  cardholder      varchar 50
|     payments  cardno  varchar 50
|     payments  cardtype        varchar 50
|     payments  cvv     varchar 4
|     payments  expiry  varchar 50
|     payments  purchase_id     int     4
|     payments  user_id int     4
|   
|   Restrictions
|     Output restricted to 2 tables (see mssql-tables.maxtables)
|     Output restricted to 5 databases (see mssql-tables.maxdb)
|_    Filter: cvv,payments,pass,password


> I want to see what people think about the method used by
> mssql-hasdbaccess. It creates a table, stores access data in it, selects
> from the table, then drops the table. I guess this could be harmful if
> there's an existing table called #hasdbaccess. This is what it does:
>
> CREATE table #hasaccess(dbname varchar(255), owner varchar(255),
>       DboOnly bit, ReadOnly bit, SingelUser bit, Detached bit,
>       Suspect bit, Offline bit, InLoad bit, EmergencyMode bit,
>       StandBy bit, [ShutDown] bit, InRecovery bit, NotRecovered bit );
> INSERT INTO #hasaccess EXEC sp_MShasdbaccess;
> SELECT TOP 5 dbname, owner FROM #hasaccess WHERE dbname NOT IN (master, tempdb, model, msdb);
> DROP TABLE #hasaccess;

This isn't such a big problem as it may look like. First of the hashmark in front of the table name means that we're 
creating a temporary table in tempdb.
Second, the temporary table is unique to our session, so it can only exist if we run the command twice without 
disconnecting.
And lastly, if the table would exist (not possible with current design), the script would fail and  abort after 
unsuccessfully creating the table.
For more information on temporary MSSQL tables see the following link (specifically the section under Temporary Tables):
http://msdn.microsoft.com/en-us/library/ms174979.aspx


> I'm not sure this script is useful enough for this amount of
> intrusiveness, but maybe I just don't know.
Based on the previous elaboration on temporary tables, I don't think this is an intrusive method.
It's common practice when retrieving/merging information from multiple sources or when you need to filter the output of 
a stored procedure.
Many SP use temporary tables to store their intermediate data. There's a little difference when using temporary tables 
in SP though, as their scope is limited to the SP.

> What can someone do with the
> information provided by mssql-hasdbaccess?
mssql-hasdbaccess uses sp_MShasdbaccess to:
"Lists the name and owner of all the databases to which the user has access."
http://msdn.microsoft.com/en-us/library/aa238829(SQL.80).aspx

I think this is quite useful in determining what users to focus on when testing an SQL server.
I'm attaching the new mssql-config script and the revised version of mssql-tables

Attachment: mssql-tables.nse
Description:

Attachment: mssql-config.nse
Description:

> David Fifield
> _______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://seclists.org/nmap-dev/


//Patrik
--
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/