阿碼外傳-阿碼科技非官方中文 Blog: 07/01/2009 - 08/01/2009

2009年7月22日

暑假0day掛馬盛期,網友們要小心!

最近接二連三爆出很多 0day 漏洞,讓擅長利用網頁掛馬攻擊手法拓展「業務」的地下經濟,突然又熱絡了起來,也造就新一波的掛馬高峰期。這幾天聽到幾位朋友跟我說作業系統已經更新到最新了還中木馬,於是請他們丟些可疑網址給我看看,略為分析了一下某網站,上面主要是被插入這串: (網址加上*號,防止不小心點到)

http://ok**.org/z.js

,繼續追蹤發現主要的網馬都包含在這網頁裡面:

http://6****.com/aa/a3a.htm

,接著我發現了一件事情 「挖!好牛喔!」 以前看到的網馬裡面還會放一堆老舊的 Exploit,而這隻網馬我分析了一下,看到都是近期爆出的 0day 漏洞,主要攻擊以下的漏洞:

1.DirectShow的DirectX NULL Byte Overwrite Vulnerability 請參考 這裡
2.DirectShow MPEG2TuneRequest Stack Overflow Exploit 請參考 這裡
3.FireFox 3.5 (Font tags) Remote Heap Spray Exploit 請參考 這裡
4.Microsoft Office Web Components (Spreadsheet) ActiveX BOF (注意!微軟尚未更新)

以上網馬都是下載同一隻木馬,路徑在: http://ho****8.com/svchost.exe 。 (註:下載惡意程式的路徑會一直改變)




以下針對每隻網馬做觸發測試 (危險動作,請勿模仿)



1.DirectX NULL Byte Overwrite Vulnerability
2.DirectShow MPEG2TuneRequest Stack Overflow Exploit

可以在 test.htm 裡面看到有兩個 jpg 分別為 go.jpg 與 go1.jpg 就知道這是最近的 DirectShow 漏洞,go.jpg 利用的是 DirectShow 6月份爆出來的第一隻 0day ,可參考這裡 ,而 go1.jpg 利用的則是最近很紅的弱點,不過微軟上禮拜二已經修正了,我們同事之前也有談到相關內容: 3b3.org 在 0 Day 的大復活日記

以上弱點的解決方法:透過微軟更新。

3. FireFox 3.5 (Font tags) Remote Heap Spray Exploit

我在測試環裡面使用了 FF3.5 BETA5 版 成功觸發 Exploit,下面有一系列截圖。

he.htm 就是 FireFox 3.5 (Font tags) Remote Heap Spray Exploit

h.js 就是駭客的呼叫遠端惡意程式的 Shellcode。

此圖為利用 FireFox 3.5 beta4 瀏覽 he.htm 時,在 Process 可以看到在 FireFox 下悄悄的執行了惡意程式。


解決方法: 將 FireFox 更新為3.5.1 就可以了,但現在也有針對3.5.1的漏洞,所以我們自己還是要小心一點,隨時注意更新或使用第三方軟體(如 NoScript)防範!

4.Microsoft Office Web Components (Spreadsheet) ActiveX BOF

測試環境是安裝最新版Office 2003 版,並更新到最新,仍觸發成功。

一開始使用 IE 打開 of.htm 這個網頁,首先他會先判斷你有沒有安裝 Office ,假如有安裝 Office,且瀏覽器的安全性設定裡面的 執行 ActiveX 控制項與外掛程式設定為「啟用」,那瀏覽到惡意網頁時,會不知不覺直接下載一個 Microsoft 元件 owc10.dll,然後執行呼叫遠端的的惡意程式到本機執行,這樣就中木馬了!

假如執行 ActiveX 控制項與外掛程式設為「提示」,則瀏覽惡意網頁的時候,會跳出視窗詢問「你是否同意執行 ActiveX」,只是,一般使用者應該都會閉著眼睛直接按下同意吧!

而我的測試環境是在 IE 上裝了 add-ons 來測試,在瀏覽惡意網頁時一樣會在 IE 跳出一個 ActivX 請求在瀏覽器上安裝 owc10.dll,然後與絕大多數使用者的反應一樣按下 Run ,接著就觸發駭客寫好的 shellcode ,騎著可愛的小馬回家了!

解決方法:目前微軟尚未發佈更新,只能等待,使用者要提高警覺,不要看到對話框就按「是」!






總結:
1.這一次分析的網馬上面所利用的各種 Exploits 都是最近爆發出來的新弱點,雖然有些已經發佈更新了,但是我相信一定還有不少使用者還沒有更新系統,原因可能是盜版或是懶得更新等等,這樣造成了瀏覽網站的風險始終高居不下!

2.這次測試,比較花時間的部份都是在整理測試環境,這些網馬觸發的機率都很高,也不需要很嚴苛的條件,使用者要提高警覺,注意更新或使用第三方軟體(如 NoScript)來保護自己的瀏覽行為。

3.對於瀏覽網站過程中,出現莫名其妙要您的 IE 瀏覽器接受 ActiveX 下載 dll時,請千萬要注意,不要隨便同意 ActiveX 下載,以免遭植入惡意程式,騎著小馬回家!

4.擔心自己網站被掛馬,可以註冊免費HackAlert網站掛馬監控帳號

作者Sun為阿碼科技資安顧問


繼續閱讀全文...

2009年7月20日

誰在看我的噗?第四回:我噗誰在看!



微型部落格」在網路上已經熱鬧好一陣子了。你噗了嗎?噗!是噗浪還是叭噗咧!

誰在看我的噗?前三回已經介紹頗多的「微型部落格」本身經常會遇到的問題,我們部落格上之前也有詳細介紹「twitter」所遭遇到的攻擊問題,可以參考這裡OWASP 排行榜上的第一名看來並非浪的虛名。

這篇文將會從使用者的角度來看「微型部落格」所帶來的衝擊,在說明前還是要回顧一下「網站」發展的過程,回顧歷史才能展望未來。不過,這裡我還是要強調一件事:網站攻擊不是現在才有,它一直存在,只是當今其他問題(如蠕蟲、系統漏洞攻擊)大多獲得控制(如線上更新、入侵防禦設備),而你的網站卻一直沒有進步,當然成為標靶了。

「網站」發展的過程,我大概以兩個時間為分界點:2000年及2005年。在2000年以前談的網站大多是所謂的 ERP(企業資源規畫)、EIP(企業資訊入口)、CRM(客戶關係管理)、KM(知識管理)...等,況且哪時這類系統還有許多並非以網站來呈現的,且那時大多屬於封閉型的系統或網站型態,因此大部分躲過了威脅攻擊。

2000年後網路興起,「E化」是當時相當有名的名詞,也是動詞的哩,而網際網路公司可以說是紅到不行,當時股市衡量股價是否合理的方式是用本益比,但對網際網路公司是用「本夢比」,這樣你應該該可以想像網際網路公司即使虧錢,股價依舊高漲不歇,因為夢想多大、股價就有多高。這個時候大家談論的網站是啥呢?大家回想起來了嗎?B2B、B2C、C2C,還有物流、金流、資料流...,是否回想起來了呢?

B2B:大多是整合企業上下游之間的網站系統,這類網站大多封閉,是比較不容易出事,但不代表比較安全,因為會接觸到這邊的,大多可能屬商業間諜,行動隱密也低調;就算出事,業主本身也會相當低調,外界不會知道發生啥事。如果企業主發現你的對手對你的行銷、企劃...等有瞭若指掌的情況,可能要注意這類資訊系統的入侵可能性了。

B2C:簡單的說就是購物網站了,這點大家就應該很熟悉了吧。發生哪些資安問題呢?大家不會忘了吧...XD!google大神的開示。至於政府單位的 B2C ...XD,參考這篇吧。

C2C:簡單說就是拍賣交易網站了。造成哪些問題呢?簡單說就是「詐騙」、「詐欺」的社會問題。

在這個階段,另外有個神奇的東西,它本身不是網站方式呈現,但卻造就不少「釣魚網站」,對!就是 IM(Instant Messaging) 軟體,且它到現在還是很紅。
你!出賣朋友嗎?
網路上交朋友要小心
騙取MSN帳密的釣魚網站...真多!!

2005年之後,所謂的「網誌」大量出現,也就是所謂的部落格(Blog)、網路日誌、博客...等等。在前一波網路泡沫之後,Web 2.0 的觀念,帶動了許多網站的興起。這時你應該能想到很多網站吧!文字的部落客就像我們阿碼外傳一樣,圖片的無名相簿網站,影音的 YouTube網站。在這個時候產生哪些問題呢?其實機乎不是資安問題,大多是社會問題,文字部分涉及言論自由、圖片部分涉及個人隱私或私密、影音部分多是犯罪實錄...XD。可以發現網路與生活越來越緊密了。

Web 2.0 簡單說,就是有個網站提供一個平台,讓使用者可以自己產生內容,並與其他使用者之間進行互動的一個網站。

2008年後開始出現「微網誌」,讓使用者與其他使用者的互動更加緊密了。所以有 PlurkBuboofacebooktwitter...的出現。而 XSS 漏洞透過這類社群網站獲得重生了,因為社群網站使用者眾多,XSS 蠕蟲可以在一天之內感染數萬個使用者,甚至造成社群網站服務的效能崩潰。這只是資安問題的。我擔心的是另外一個問題。

B2C 的時代,大家已經把個資瘋狂的送到網路上,個資都已經外洩光了,Web 2.0的時代大家又把私密照片、或是犯罪實錄的影片給 Post 到網路上了。現在呢?噗阿噗!!大家把自己的行蹤、心情、喜怒哀樂、觀點...一大堆潛在人格特質給 Post 到網路上了。原來,在網路上要了解一個人好簡單啊。

微型部落格可能造成:陌生人比你媽還了解你,甚至,陌生人比你還了解你自己;而你卻還不認識隔壁老王。小心有心人的,當遇到難纏的對手,如果還涉及感情,哪可就麻煩了。

社交工程術的發展會將會更加極致,一旦詐騙電話更加了解你,不再是你熟悉的詐騙電話?一旦梁上君子熟知你的行蹤,不用在你的信箱、門牌做記號,上網就知道你在做啥?你該如何全身而退...網路真是讓人又愛又恨!!

作者 Crane 為阿碼科技一員
系列第一篇:誰在看我的噗?第一回:DOM沙盒 vs 跨網站腳本漏洞(XSS)
系列第二篇:誰在看我的噗?第二回:IE執行模式 vs 跨網站腳本漏洞(XSS)
系列第三篇:誰在看我的噗?第三回:弔詭的過濾函式
系列第四篇:(本篇)誰在看我的噗?第四回:我噗誰在看!

繼續閱讀全文...

2009年7月17日

誰在看我的噗?第三回:弔詭的過濾函式


(本文感謝 armorize parser 團隊 Chris, Eric, Steven, Wing 與 ASF 團隊 Kuon 的意見)

泡咖啡或茶的藝術,我稍微接觸過一些,很有意思,每一個部分都很講究,從水、豆子或茶葉、到器具、時間等,每一個環節的掌握,決定了最後享受的品質。

有在品嚐的朋友都知道,其中常被忽略但是卻是關鍵者,就是過濾方式。以茶來說,不好的濾網可以直接喝到金屬的味道,所以有些人會把沖泡器的濾網拆除,寧可茶中有些茶葉。以咖啡來說,紙濾網會有味道,另外吸油能力太強,會讓咖啡少了原本的濃郁。很多人因此喜歡用金(或K金)濾網,雖然貴,但是金穩定,比較不會有異味,泡出來的咖啡跟紙濾網喝起來完全不一樣。可是金濾網除了價格高以外,很多廠商的技術不到位,濾得不乾淨,常讓咖啡渣漏到咖啡中,那就大大破壞興致了。就連自己做豆漿,最難的部分還是過濾機制的設計。要做一個好的過濾器,並不容易。

在Web資安中亦是如此。前面我分享了「誰在看我的噗?第一回」與「誰在看我的噗?第二回」兩篇,裡頭提用了噗浪的一些跨站腳本攻擊(XSS)漏洞來做範例。當初噗浪雖然有過濾CSS中的「expression」,但是改其中一個字的大小寫,例如「eXpression」,就繞過噗浪的過濾機制了。

回報給噗浪後,改好了,我這次,恩,的確改好了,現在不論是「Expression」、「eXpression」或「exPression」,都會被阻擋起來。於是我就試了下面這個字串:

「ex/**/pression」

IE的CSS parser,會將「/*」與「*/」當成是註解,將中間的字串都拿掉,於是「ex/**/pression」還是變成了「expression」,會執行javascript。測試發現噗浪並沒有偵測這種形式(pattern),於是又回報他們。以下是一些可能的變形:

「ex/**/pression」、「ex/**/p/**/ression」、「e/**/x/**/p/**/r/**/e/**/s/**/s/**/i/**/o/**/n/**/」

噗浪改好後,我測試,嗯,真的改好了,以上這些形式都會被阻擋起來,確定改好了。接下來我測試「ex/*armorize*/pression」,發現繞過了噗浪的檢查。原來噗浪沒有注意到,「/*」與「*/」中間可以加任何的字串,於是又回報他們。以下是一些可能的變形:

「ex/*armorize*/pression」、「e/*A*/x/*B*/p/*C*/r/*D*/e/*E*/s/*F*/s/*G*/i/*H*/o/*I*/n」、「e/*/*/*****///"hello"*/*/*/xpression」

噗浪改好後,我測試,嗯,真的改好了,以上這些形式都會被阻擋起來,確定改好了。接下來我想,該不會噗浪的過濾機制,是以「行」為單位的吧?於是我測試:


ex/*
*/pression

中間換行,發現又繞過去了。註解中間雖然有換行,IE還是會執行expression後面帶的javascript,可是噗浪是以「行」為單位進行過濾,所以又被我繞過去了。於是我又回報他們。以下是一些可能的變形:

ex/*
armorize
*/pression

ex/*
XSS**/**/*/pression

噗浪改好後,我測試,嗯,真的改好了,以上這些形式都會被阻擋起來,確定改好了。這是我仔細想,噗浪是如何做過濾機制的呢?最直覺的作法,應該是用正規表示法(regular expression)來過去,並採以下步驟:

1. 以整個CSS為單位,移出「/*」與「*/」以及中間的字串(因為是註解)
2. 偵測「expression」的各種大小寫形式

恩,那麼,如果我用以下的一段CSS呢?

X{"/*"} expression() X{"*/"}

上面這樣的CSS,對於IE來說,由於文法是可以接受的,另外「/*」與「*/」被包在雙引號內,所以IE不會視為是註解。可是對於此時噗浪的過濾機制來說,過濾機制的第一步會將「/*」與「*/」以及中間的字串移出,所以經過第一步後,噗浪看到的是:

X{""}

沒有「expression」的存在,故判定是合法沒有惡意的CSS而接受。實際上測試,正是如此,而我這個新的CSS攻擊,又繞過了噗浪此時的過濾機制。於是趕緊回報噗浪,噗浪改好後,我測試,嗯,真的改好了,這種形式都會被阻擋起來,確定改好了。可是我仔細一想,不對,目前最新的過濾機制應該是這樣,那麼如果我寫這樣,應該又可以繞過,結果果然。於是我回報,不過到這次,已經不是那麼容易可以改了,甚至要考慮一下以正規表示法(regular expression)為基礎的CSS過濾機制,到底有沒有辦法做到安全?過了兩星期問題還是沒修好,我這邊就不探討實際的字串了。

算一算到目前為止,攻擊已經變形了七代了。如同Twitter Mikeyy蠕蟲變形了多代一樣,如果今天同樣有駭客要攻擊噗浪,那麼已經變形七代了,可以做七波的攻擊,每一次攻擊都可以是蠕蟲或是偷受害者的cookie(然後以該身份登入噗浪)。另外很有趣的是,噗浪的第二代過濾機制,其實是可以阻擋第六與第七代的變形攻擊的,因為該機制只是單純地檢查有無「expression」的各種大小寫形式存在。可是之後,噗浪為了要應付第三代攻擊形式(「ex/**/pression」),而導致改進後的過濾機制反而會被第六與第七代攻擊形式繞過(X{"/*"} expression() X{"*/"})。

從噗浪的一系列攻守中我們可以獲得以下結論:

1. 設計一個正確的過濾機制是不容易的。找到漏洞不表示可以正確修補。
2. 修補的過程中,很有可能導致新的漏洞產生。


在這邊順便問一下,有沒有網友有興趣寫一個CSS的過濾函式?如果願意與我們一起研究,我們可以一起公開一套針對CSS的開放源碼過濾函式。

CSS的過濾函式,真的可以用單純的正規表示法(regular expression)之字串比對機制來完成嗎?

我們先來研究一下,到底IE是如何處理CSS的。第一,「ex/**/pression」==「expression」到底是否合於CSS2的文法(grammar)與語意(sematics)?我們看一下W3C對於CSS2.1的定義中,註解(comments)這段

Comments begin with the characters "/*" and end with the characters "*/". They may occur anywhere between tokens, and their contents have no influence on the rendering. Comments may not be nested.

「註解以 "/*" 開始,以 "*/" 結束,可以存在於任兩個 token 之間...」既然是任兩個token之間,那麼「ex/**/pression」根本不應該等於「expression」,而要被分成「ex」與「pression」兩個token。實際上W3C對於CSS2.1的文法定義也反映了這點。

如果是單純用標準的lexer與parser來處理CSS的話,ex/**/pression一般來說會被切成兩個token,而要認識「ex/**/pression」為「expression」的話,需要特別花功夫重組token。我認為IE不是這樣做的。我認為IE目前的CSS處理模組,包含了一個或多個的preprocessor,然後才餵給一組lexer與parser。前面的preprocessor可能也是用lexer與parser組成,但更可能只是用正規表示法(regular expression)之字串比對機制來完成。這樣的設計造就了在IE裡,「ex/**/pression」==「expression」的錯誤。

可是說IE錯了,沒有用,因為「ex/**/pression」在IE中就是會執行javascript,攻擊就是會成功。所以我們這篇探討的過濾機制,重點變成了,「如何了解各家瀏覽器對於CSS的處理機制,並實做一個模擬函式,來做資安過濾」。

這個就難了,因為各種歷史因素加上一開始CSS的定義並不明確,各家瀏覽器對於CSS的處理可說各顯神通,怪招一堆。舉個例子,雖然CSS中並無定義,但是以往非IE瀏覽器(FF、Safari、Chrome)對於「//」這個註解掉本行的語法,也是支援的;IE則不支援。可是到了IE8時,突然決定在「IE8標準模式」下時,跟其他非IE瀏覽器一樣,支援「//」。於是以下CSS,用非IE瀏覽器瀏覽,以及用IE8在「IE8標準模式」下瀏覽,背景會是紅色的(支援「//」),但是用IE<8或IE8在「IE7標準模式」瀏覽,背景會是藍色的(不支援「//」):

body {
background-color:red;
// background-color:blue;
}

那麼我們在寫過濾器時,到底要不要把「//」當成行註解呢?

又舉一個例子,以下這個CSS,在IE5/MAC,以及在IE8 beta 1上,中間的「@import」會被執行,但是在其他瀏覽器,包含IE8正式版中,則會被當成註解:

/*\*//*/
@import...
/**/

這主要跟lexer/parser或proprocessor在處理CSS時所採用的優先順序(operator precedence)有關。IE5/MAC與IE8 beta 1 是如此解讀的(資料來源:stopdesign.com

(1)的「/*」被視為是註解的開始,(2)的「\」將(3)的「*」給escape掉了,所以一直到(4)的「*/」才被視為是註解的結束。(5)的@import在註解外,而(6)的「/*」與「*/」被視為一對註解的開始與結束。

其他的瀏覽器則是如此解讀:

(1)的「/*」被視為是註解的開始,(2)的「\」被視為在註解中所以沒有作用,(3)的「*/」被視為註解的結束,(4)的「/*」被視為第二個註解的開始,(5)的「@import」被視為註解內,而最後(6)的「*/」為結束註解,於是「@import」不會被執行。

反過來看,我們的過濾器如果需要正確識別「ex/**/pression」以及類似變形,就必須正確判斷註解的開始與結束,可是各家瀏覽器在CSS處理機制實做上的不同,增加了我們過濾器的困難度。

事實上,這些各家瀏覽器在CSS實做上的不同,不但大家早就熟悉,還早就被當成「功能」來使用--利用這些不同來有效判斷不同的瀏覽器,讓不同瀏覽器讀取不同的CSS檔。這種技巧叫做「CSS Hack」或「CSS Filter」,大家可以參考 Wikipedia 中的定義,這邊就不多著墨。

但是由於這些差異被當成「功能」來使用,讓錯的一方也不能修正,因為如果修正了,反而很多網站的顯示就要變得不正確了。於是目前瀏覽器廠商只能推出新一代瀏覽器(IE5 -> IE6 -> IE7)時,才對這些bug進行修正。

為何瀏覽器的lexer/parser或preprocessor這麼糟糕?事實上,很久以前大家不就發現,資料庫的SQL處理器也是一樣糟嗎?「se/**/lect」這種SQL注入(SQL injection)手法大家應該都很常用。事實上,MS SQL伺服器的T-SQL處理器以及MySQL的SQL處理器,在這方面也都是有名的...說複雜好了。

雖然攻擊手法並不新,但是從噗浪的七代實驗可以知道,老人雖然很熟,新人還是會不斷地重複採地雷,正確地過濾惡意字串,並非易事。

瀏覽器/資料庫的lexer/parser/proprocessor處理器的複雜與不穩定,不但增加了資安的過濾函式的難度,也同時增加了WAF(Web應用程式防火牆、web application firewall)在實做與設定上的難度。

這些也就是為何,在情況允許之下,程式中應盡量避免過濾機制,而採用參數化機制。你的過濾機制,真的安全嗎?

作者Wayne為阿碼科技一員
系列第一篇:誰在看我的噗?第一回:DOM沙盒 vs 跨網站腳本漏洞(XSS)
系列第二篇:誰在看我的噗?第二回:IE執行模式 vs 跨網站腳本漏洞(XSS)
系列第三篇:(本篇)誰在看我的噗?第三回:弔詭的過濾函式
系列第四篇:誰在看我的噗?第四回:我噗誰在看!

繼續閱讀全文...

2009年7月7日

談談 PHP, WordPress 與掛馬



惡意的PDF檔案一點都不是新聞,過去 doc、flash 以及圖片等都已經被大量利用在 PC 的感染中,但前一陣子在日本以及各地頻傳的事件 (1,2) 顯示,才發現一種綜合型的攻擊組合已經出現,也引起我對於了解後面原因的興趣。

我從 client, server 兩個方面來說明:

1. client

這次利用的攻擊瀏覽器方式稱為 JSRedir-R,它其實是一種攻擊方式的通稱,在友廠的分類說明中可以見到它是利用 PDF, Flash/SWF 的漏洞來讓瀏覽器, PDF reader 或 flash player 直接做為下載器 (downloader), 將後續的其他 binary 安裝到執行這個 JSRedir-R 的電腦上,隨後就開始進行自動側錄,這次側錄的通訊協定鎖定 Web hosting 使用者常用的 ftp,為何這麼做呢? 1. 明碼 2. 登入帳號密碼經常1~2個封包就可錄到。

網路上這篇討論描述了這個狀況,節錄如下:

"One of our clients computers was infected with the client-side portion of the virus. It’s a trojan that monitors all FTP traffic, sending the auth details back to the payload server (gumblar.cn).."

2. server: 這次駭客在想甚麼?



約3個月前,就開始有人在WordPress (咱們就簡稱為WP) 論壇上面歇斯底里的求救, "Seriously, I need your help! " ,很明顯的,他遇到了無論登入 wp-admin 後改密碼或是檔案移除,那一段攻擊程式碼都還是會再被自動加回去所有的 index-files,想必夜不成眠吧。

去年,我們監控到 Mass SQL Injection 的大範圍 SQL 注入,分析了原因是攻擊方利用 Google 的強大搜尋找攻擊對象,但這次不一樣,不需要這麼麻煩,這次駭客不辛苦的打 Mass SQL Injection 了,直接從 web 管理員的電腦直接掛馬側錄、傳回 Bot 監控主機、連到目標 ftp server, 接著自動竄改每一個 PHP 網頁,都可以自動化/半自動了, 然後去逛這些 WP, Drupal 網頁的人,都執行了 pdf 與 swf,若沒做自我保護,會繼續受到 JSRedir-R 的感染,然後被側錄,.. 就這樣一直循環下去, oh my goodness!!

慶幸的是,到目前為止,這並還未演變成 server 對 server 的病毒感染事件,否則可以想像機房內的網路、Web主機眾多的virtual host sites 會變成甚麼狀況,不過這跟 Web Hosting 的架構設計有關,這邊就有另外一種狀況。

既然被補上去 WP 與 Drupal 的源碼是 PHP,我開始將注意力轉向 WordPress 的源碼去,開放源碼的壞處就是容易成為下一個目標,事實上我的同事 Wisely 在兩年前就已經用我們內部的工具檢測過 WP 的兩個主要版本了,兩年多下來,我印象中看到針對 WP 本身新弱點的次數並不多,但 WP 畢竟做為全球著名的部落格發行軟體,為了服務廣大的使用者採用了開放式的架構,並有許多對應的外掛被開發出來,然而這些眾多的外掛卻成了另一大隱憂的來源,光在 milw0rm.com 上就至少有數十個 exploit 被公布,我從中取了一個做驗證,ID為 9048 的這個攻擊是利用 DM-albums 這個外掛:



這個弱點是 Remote File Dislosure Vulnerability,在 OWASP 的定義為 Resource Injection ,我們立即將 config.php 原始擋下載回來:



用 IDE 開來看,wow, 真的是 config.php,可以拿來分析設定與系統架構:



接著我用 CodeSecure 掃了兩次,分別是將 register_global 這個設定關閉:



以及開啟:



都找到跟 dm-albums.php 這個進入點有關的 Resource Injection,其中一條弱點問題追蹤列出如下,很明顯的,至少就有 currdir 這個變數沒有被處理好:



看到弱點這樣多,我真的開始覺得任意瀏覽網站的風險太高了。

以前打 client 端是拿個資、打 server 端是拿主機與 DB,做完就各自結束,但從 5月份的 Gumblar 開始,透過在 WP, Drupal 等 Blog 平台插入 PHP 程式碼的新掛馬手法讓感染來源成指數成長,如果你發現你的部落格的程式碼內出現奇怪的新程式碼,建議趕快用一台乾淨的機器上網改掉密碼並回復所有的 PHP 網頁,然後將受感染的電腦做進一步檢查,詳細做法可參考這篇,若剛好你的部落格也用了不少外掛,建議先搜尋一下有沒有已經被公布的弱點 (關鍵字: "exploit" "vulnerability),然後儘早因應,至少被公開的弱點一定得想辦法剔除。

作者: Walter Tsai 為阿碼科技CTO

繼續閱讀全文...

阿碼科技正名運動


昨天看到Yahoo!新聞對我們的報導,心裡高興,謝謝您!可是真的是報導我們嗎?大人啊,我們叫做阿「碼」,源碼檢測的「碼」,幫客戶檢查程式碼漏洞的公司,不是皇阿瑪的「瑪」。

阿碼成立初,差點被強迫改名,Google查「阿碼科技」會問你說你是不是要查「阿瑪科技」,這也就算了,連身邊的朋友都要我們改名。公司旁邊的鄰居,每天看到扛棒總不會錯吧?結果還是「阿瑪」...

我們的裝潢是matt高中同學孫兄開的八寬設計做的,結果得了獎,變成八寬得意作品。大家都這麼熟,扛棒也是你們幫忙做的,總不會錯吧?恩,還是「阿瑪」...

阿碼成立到現在快四年了,Google卻還是不放過強迫改名的意圖:

在這邊阿碼要推行正名運動!我們是源檢測公司,叫做阿,謝謝大家! :-)

作者Wayne為阿碼科技一員

繼續閱讀全文...

2009年7月6日

3b3.org 在 0 Day 的大復活日記

3b3.org 是啥!可以問問 google 大神,這是今年初惡意網頁掛碼所使用的惡意網域,最近復活了。透過 DirectShow MPEG2TuneRequest Stack Overflow 的 0 Day 大復活了...

一般惡意網域在惡意利用後,大多會丟棄不用,會再利用新的惡意網域,但 3b3.org 並沒有,在沉潛一段時日之後復活了。很重要的原因是:有太多網站被植入此惡意連結後,一直沒有移除。換句話說,很多網頁還留有舊的攻擊連結。

先前兩篇文章,你看了嗎?
網站多久沒健檢,是不是該關心一下了
深思網站淪陷背後的意義

先看看 3b3.org/c.js 在做啥...





再看看 HackAlert 發現的一個掛馬網址:


詳細追下去:




是不是發現都是一樣的攻擊碼了。這是 Microsoft DirectShow MPEG2TuneRequest Stack Overflow Exploit,這可是 0 day 的漏洞,可以參考鬼仔's Blog:
Microsoft DirectShow MPEG2TuneRequest Stack Overflow Exploit
DirectShow 0DAY第二波警告

繼續閱讀全文...