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

[Patrik Karlsson <patrik () cqure net>]

On 2 apr 2010, at 20.08, David Fifield wrote:

> On Fri, Apr 02, 2010 at 11:39:58AM +0200, Patrik Karlsson wrote:
> > 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:
>
> This looks good. Let's talk about categories. All the scripts are in
> {"auth", "intrusive"}. I will suggest these:
>
> mssql-brute           {"auth", "intrusive"}
> mssql-config          {"discovery", "safe"}
> mssql-empty-password  {"auth", "intrusive"}
> mssql-hasdbaccess     {"auth", "discovery", "safe"}
> mssql-query           {"discovery", "safe"}
> mssql-tables          {"discovery", "safe"}
> mssql-xp-cmdshell     {"intrusive"}

Sounds good to me. I've corrected this now.

> Finally, we need to decide on the name prefix. I like the shorter mssql,
> but we already have a script called ms-sql-info and the service names
> ms-sql-s and ms-sql-m. I guess we don't *have* to have the script prefix
> match the service name exactly, as we have pgsql scripts but the service
> name postgresql, and I think that's reasonable.
>
> These script names should at least match that of ms-sql-info, either by
> renaming them to have an ms-sql prefix, or by changing ms-sql-info to
> mssql-info. Are there any strong opinions about this?

It might be good to use dashes a strict delimiters though and avoid using them in service names?
Either works for me though.

> > > 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 didn't know about the temporary tables. Considering that, it's fine.
Great!
> David Fifield
> _______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://seclists.org/nmap-dev/


As I've only changed the categories this time, I'm not attaching updated versions of the scripts until we decide on the 
names.

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