| The attack is targeting Microsoft IIS web servers. Is it exploiting a Microsoft vulnerability?
Yes and no. Web developers (or their employers who did not mandate proper security education) are to blame for each single infection, because the SQL injection exploited to infect the web sites is possible thanks to trivial coding errors. That said, the attackers are targeting IIS web servers which run ASP for a reason. Crackers put together a clever SQL procedure capable of polluting any Microsoft SQL Server database in a generic way, with no need of knowing 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 '])) ''''' ); FETCH NEXT FROM Table_Cursor INTO @T, @C; END; CLOSE Table_Cursor; DEALLOCATE Table_Cursor; This is the “secret sauce” which is allowing the attack to reach its impressive numbers, and it works exclusively against Microsoft database technology — but it’s a feature, not a bug (no irony intended this time). Anyway, the chances for such “powerful” DB technology of being used in conjunction with web servers different than IIS are very low. So, to recap: There’s no Microsoft-specific vulnerability involved: SQL injections can happpen (and do happen) on LAMP and other web application stacks as well. SQL injections, and therefore these infections, are caused by poor coding practices during web site development. Nonetheless, this mass automated epidemic is due to specific features of Microsoft databases, allowing the exploit code to be generic, rather than tailored for each single web site. Update: more details in this comment. In my previous coverage of similar incidents I also assumed a statistical/demographic reason for targeting IIS, since many ASP developers having a desktop Visual Basic background underwent a pretty traumatic migration to the web in the late 90s, and often didn’t really grow enough security awareness to develop safe internet-facing applications. What should I do if I’m the administrator of an infected site? First of all, you should call your web developers (or even better, someone who specializes in web application security) and require a full code review to find and fix the SQL injection bugs. In the meanwhile you should either put your database offline or recover clean data from a backup, but until the code review is done be prepared to get compromised again. Deploying a web application firewall may mitigate the emergency, but you must understood it’s a merely temporary work-around — the solution is fixing the code (learn from the United Nations tale). If you’ve got no clean database backup, you could try to recover by brutally reversing 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 - patindex(''%tpircs<%'', reverse(convert(varchar(8000), [' @C ']))) ) where [' @C '] like ''% ); 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 appending the malicious JavaScript with EXEC( 'update [' @T '] set [' @C '] = rtrim(convert(varchar,[' @C '])) ''''' ); it locates and removes it with EXEC( 'update [' @T '] set [' @C '] = left( convert(varchar(8000), [' @C ']), len(convert(varchar(8000), [' @C '])) - 6 - patindex(''%tpircs<%'', reverse(convert(varchar(8000), [' @C ']))) ) where [' @C '] like ''% ); Notice that I’ve not tested my code above, and I’m just providing it as a courtesy: use it at your own risk, after doing 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. |
免责声明：本站部分文章和图片均来自用户投稿和网络收集，旨在传播知识，文章和图片版权归原作者及原出处所有，仅供学习与参考，请勿用于商业用途，如果损害了您的权利，请联系我们及时修正或删除。谢谢！
始终以前瞻性的眼光聚焦站长、创业、互联网等领域，为您提供最新最全的互联网资讯，帮助站长转型升级，为互联网创业者提供更加优质的创业信息和品牌营销服务，与站长一起进步！让互联网创业者不再孤独！
扫一扫，关注站长网微信
大家都在看
