Cleaning Up After a SQL Injection Attack, Part 2

Jeff Knapp — Sun, 27 Dec 2009 04:59:07 +0000

Got a call today off our previous article in this series from Branden of Hot Media Group, Inc., aChicago-based web application development, networking, and graphic design firm who found himself with a database full of malware infections, but the characteristics of his attack didn't match what we had written about, so he called us up. We reviewed his symptoms and were able to tweak the code we provided previously to work with this new set of issues.

We weren't able to see how the site was attacked, nor did we worry about how the site would be steeled against future occurrence (always use stored procedures and/or parametrized queries, kids!) -- this was purely a cleanup job.

This is the code we had:

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=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
PRINT ('UPDATE ['+@T+'] SET ['+@C+']=REPLACE(['+@C+'],'''', '''')') FETCH NEXT FROM Table_Cursor INTO @T,@C END CLOSE Table_Cursor DEALLOCATE Table_Cursor 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 OPEN Table_Cursor FETCH NEXT FROM Table_Cursor INTO @T,@C WHILE(@@FETCH_STATUS=0) BEGIN PRINT ('UPDATE ['+@T+'] SET ['+@C+']=cast(replace(cast(['+@C+'] as nvarchar(4000)),'''','''') as ntext)')
FETCH NEXT FROM Table_Cursor INTO @T,@C
END
CLOSE Table_Cursor
DEALLOCATE Table_Cursor

And that worked fine, but it had some shortcomings -- mostly it only stripped out a single bit of invasive code, and our new friend had quite a bit of code to deal with, so instead of the almost quaint looking malware code:

We had this jumble of code in every ntext field in his database:


journals on losing post-pregnancy weight
personal trainer certification atlanta
quit smoking water vapor rings
eyes in the darkness
cheated map on dota 6.54b
occupations for bored teen boys
cgw southeast partners ilp
does iq tests accurately measure intelligence
free total psychic reading
minnesota past life regression
date of abraham lincolns death

After trying to figure out the best way to escape all the single quotes, Branden -- an accomplished ColdFusion developer -- suggests "why don't we just drop everything to the right of the ''') FETCH NEXT FROM Table_Cursor INTO @T,@C END CLOSE Table_Cursor DEALLOCATE Table_Cursor

Again, I defanged the routine by changing it to PRINT, so I can see what it spits out...

It spits out a whole pile of UPDATE statements, affecting every field of every table it found of the applicable types. (In practice, it wouldn't print the UPDATE statements, it would actually, you know, execute them...)

UPDATE [InProcessOrders] SET [StatusMessage]=RTRIM(CONVERT(VARCHAR(4000),[StatusMessage]))+''UPDATE [Handhelds] SET [RecKey]=RTRIM(CONVERT(VARCHAR(4000),[RecKey]))+''

UPDATE [Handhelds] SET [RecName]=RTRIM(CONVERT(VARCHAR(4000),[RecName]))+''

... and so forth.

But we can see that it appends its malicious SCRIPT tag at the end of every field in the hopes that it will someday be displayed unfettered on a webpage, where its payload can be hidden in an IFRAME.

Cleaning Up The Mess

So now you have a database that's infected with the evil code at the end of every data field. To get rid of it, you need to re-run the code, but with a replace statement instead of an appending of the field.

NOTE: If you have more than 4000 characters in a data field, go for your backup, because the malicious script only grabs the first 4000 characters and then appends itself; so this solution will leave you with truncated fields. If your fields are not over 4000 characters, you should be OK.

So if we take the disassembled code and just edit it just a little bit... change the UPDATE statement so that is REPLACES the ill-gotten script block with nothing, it's like the script block was never there. (Except in the aforementioned cases where the original data was over 4000 characters...)

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=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
PRINT ('UPDATE ['+@T+'] SET ['+@C+']=REPLACE(['+@C+'],'''', '''')')
FETCH NEXT FROM Table_Cursor INTO @T,@C
END
CLOSE Table_Cursor
DEALLOCATE Table_Cursor

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
OPEN Table_Cursor
FETCH NEXT FROM Table_Cursor INTO @T,@C
WHILE(@@FETCH_STATUS=0)
BEGIN
PRINT ('UPDATE ['+@T+'] SET ['+@C+']=cast(replace(cast(['+@C+'] as nvarchar(4000)),'''','''') as ntext)')
FETCH NEXT FROM Table_Cursor INTO @T,@C
END
CLOSE Table_Cursor
DEALLOCATE Table_Cursor

And there you have it. If you edit the code so that the bad URL you're trying to erase is in it (as opposed to my bogus evilsite.evl URL) It will generate all the SQL statements you need and then you can run them against your database.

(Of course, you can change the PRINT statement for some other statement that might do the trick...)

An Ounce of Prevention

Of course, the best way to protect yourself is to not allow the SQL Injection attack to occur in the first place. These attacks failed against our client's site because we tested to make sure the variables we were accepting via the URL were numbers. Since there were alphabetic characters in there, the page threw an ugly error and failed to render. (In these cases throwing an ugly error is fine, since I don't think anyone is really is looking at your pages.)

Microsoft Developer Network (MSDN) has these suggestions:

Constrain and sanitize input data. Check for known good data by validating for type, length, format, and range.
Use type-safe SQL parameters for data access. You can use these parameters with stored procedures or dynamically constructed SQL command strings. Parameter collections such as SqlParameterCollection provide type checking and length validation. If you use a parameters collection, input is treated as a literal value, and SQL Server does not treat it as executable code. An additional benefit of using a parameters collection is that you can enforce type and length checks. Values outside of the range trigger an exception. This is a good example of defense in depth.
Use an account that has restricted permissions in the database. Ideally, you should only grant execute permissions to selected stored procedures in the database and provide no direct table access.
Avoid disclosing database error information. In the event of database errors, make sure you do not disclose detailed error messages to the user.

Wikipedia has a good breakdown of what SQL Injection is.

Lastly, Microsoft MVP Harry Waldron put together a good collection of best practices to foil SQL Injection attacks.

Microsoft Patch Breaks Zone Alarm

Jeff Knapp — Wed, 09 Jul 2008 20:20:14 +0000

Got a call from a client today complaining that he could no longer access the Internet. He's running Zone Alarm 7.

Trek out to the site and lo and behold, we can ping IP addresses thru the firewall, but we can't resolve any names. Turns out DNS had a big hole in it, and it's been patched by the major vendors, Microsoft among them.

So, Microsoft rolls out KB951748 yesterday as part of Patch Tuesday, and this morning all the machines set to autoupdate who are also running Zone Alarm find themselves out of luck.

The quick fix is to run ZoneAlarm's Internet Zone Security in "Medium" mode.

Zone Alarm released a knowledge base article suggesting three options: the aforementioned "medium mode" fix; uninstalling the patch or adding your DNS servers to the trusted zone.

Adding the DNS servers to the trusted zone is the most secure solution as it allows you to run in full stealth and still enjoy the "benefits" of the Microsoft path.

Change Your Router Password

Jeff Knapp — Thu, 12 Jun 2008 21:34:12 +0000

There's some new malware floating around -- a variant of Trojan.ZLob --which asks you to install a new codec to see some videos... but what it really does is change your router settings so that all of your internet traffic gets routed thru their servers before going to its final destination.

If there is more than one computer behind the router, each machine will have its traffic redirected.

The malware attempts to use the default username and password of common routers to change its settings.

It's easy to change the default username and/or password of your router. Take a few moments and protect yourself.

Hats off to Brian Krebs of the Washington Post for bringing this to light (with an assist from Sunbelt Software.)

MonaRonaDona – Don’t Get Stung

Jeff Knapp — Tue, 04 Mar 2008 17:59:51 +0000

There's a new bit of malware out there going by the name "MonaRonaDona" and it basicially infects your PC, changes Internet Explorer's title bar to announce itself and does a few other more or less benign things. It's designed so that you Google the name and buy a piece of anti-malware for $40 which disables it.

The anti-malware program does, in fact, disable MonaRonaDona... and that's all it does. Nothing else.

The good folks over at DSL Reports' Security Forum have put together a sure-fre way to clean your system without shelling out the 40 bucks.

Get the details at this link:

MonaRonaDona removal

http://www.dslreports.com/forum/r20088377-

The oddest things so far is no one seems to know how you get infected in the first place... so remain vigilant, don't open emails that you don't recognize, and certainly don't do that with attachments.