While the effect yesterday’s post had was unintentional (I only wanted to complain about the effect those requests have on our and our clients’ server statistics), it seems that a lot more people than I would have anticipated are affected and are looking for answers.

So in this post, I am trying to provide help and some answers.

UPDATE (8-25-08): How to secure your forms and prevent future attacks

For all you guys looking for ways to detect vulnerable servers and code, try these links now:
Microsoft Source Code Analyzer for SQL Injection
or:
Scrawlr

Cleanup:
Replace script tags from your database (absolutely no warranties – check the URL/path of the domain and script – in this case http://www0.douhunqn.cn/csrss/w.js – as well):

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+']=replace(['+@C+'],''"></title><script src="http://www0.douhunqn.cn/csrss/w.js"></script><!--'','''')');
FETCH NEXT FROM Table_Cursor INTO @T,@C ;
END;
CLOSE Table_Cursor;
DEALLOCATE Table_Cursor;

Quick Fixes to prevent more attacks (until you had time to secure every single query):
Check for suspicious Strings in Query Strings via an included function before serving any pages (Chances are nobody is supposed to submit certain statements in a parameter in the first place).

Use the RewriteEngine to check for and react to those strings (e.g. serve a 401 page instead).

These are quick fixes only and should not serve as long-term solutions: If the attacker modifies the SQL statements and you are only checking for e.g. DECLARE you have the same problem all over again.

Prevention:
* Never trust Query Strings.
* Escape them properly.
* Check the TYPE of your variables. If you expect numeric values, check for numeric values.

Demo – Test it:
We’ve created a demo page so you can check how a rewrite rule or an include function might change the way your pages are served:
SQL injection attack attempt demo page: (will open in new window)

You can also use the page to translate the code from your logfiles:
SQL injection attack attempt demo page without Query String

I hope this answers at least some of your questions. If you are still lost, feel free to either leave a comment and I will try to answer your questions ASAP or email me directly.

PS: I agree with everyone who said it’s not a pure SQL injection hack, but it’s also not a pure XSS hack either.

Tags: attack hack injection sql sqlinjection

Date posted: Saturday, August 23rd, 2008 at 7:58 am (16 years, 3 months ago.)
Posted in: business mix, tech mix
Comments RSS Feed
Reply
Ttrackback