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

2009年3月27日

網路藍色藥丸?首支攻擊路由器之蠕蟲出現:再談路徑之安全性

(picture source: http://www.fastforwardblog.com)


自從最近寫了幾篇關於路徑安全的文章後,短短幾天內,世界各地突然冒出了許多關於路由器安全的新聞。美國西岸時間三月22日凌晨,DroneBL首先發表了blog:「Network Bluepill - stealth router-based botnet has been DDoSing dronebl for the last couple of weeks(網路藍色藥丸:隱形路由器僵屍網路過去幾星期以DDoS攻擊DroneBL)」。先離題聊一下「藍色藥丸」吧!在1999年電影駭客任務(The Matrix)中,藍色藥丸(Bluepill)與紅色藥丸分別象徵了「虛幻世界」與「真實世界」。2006年六月,由那時還在COSEINC(與阿碼共同舉辦SySCAN前瞻資安技術年會的新加坡公司)的Joanna Rutkowska,證明了可以在MS系統(包含Vista)上,利用AMD的虛擬化機制,實做極隱密rootkit之可能性,並在她blog上貼了一篇:「Introducing Blue Pill(介紹藍色藥丸)」,並於同年先後在SySCAN 2006與BlackHat 2006(投影片下載)上發表。之後此rootkit程式有公開並可下載。其實當初Joanna取名藍色藥丸,主要是因為該rootkit乃利用了CPU虛擬化(virtualization)的機制來達成極度隱密之目的,故藍色藥丸暗喻「虛擬化(virtualization)」而非「隱密性(stealthiness)」,但是因為大家對於此rootkit之隱密性都有很深的印象,所以從此,「藍色藥丸(Bluepill)」便成了資安研究員形容各種「隱形」技術時喜歡用的代名詞。

這次DoneBL所發的「網路藍色藥丸」,主要描述NetComm NB5 這台 ADSL 路由器,會被蠕蟲「PSYB0T」自動攻擊並感染,成為botnet(irc)的一員,除了會接受指令參加DDoS攻擊外,也會自動掃瞄,攻擊並感染其他同型路由器,來散播該蠕蟲。「網路藍色藥丸」則指管理者不容易發現路由器已經遭受感染。DoneBL估計已經有100,000台路由器遭PSYB0T感染,並認為這是第一隻會自動感染路由器的蠕蟲,且對象可能不限於NetComm NB5這型路由器,而是任何以linux mipsel為平台的路由器都有機會被感染。
(picture source: http://www.teamtelco.com.au)


(picture source: http://www.beyondlogic.org)


隔天(三月23日),ZDNet的Zero Day blog上,Ryan Naraine就貼出了「Stealthy router-based botnet worm squirming(隱形路由器botnet蠕蟲散播)」,並引述了DroneBL的blog。Teamfurry blog上也貼出了一篇:「Botnet running on MIPS CPU devices(Botnet在MIPS CPU設備上散播)」,其中第一句就說:「Finally, something new :)(終於有新鮮事了)」。由於此二blog在資安界皆頗具人氣,又隔天(三月24日),SANS就發出了警告:「PSYB0T: A MIPS-device (mipsel) IRC Bot (PSYB0T:mipsel設備之IRC Bot)」,並引述了以上兩個blog。同時,英國最大IT媒體The Register也報導了:「Worm breeds botnet from home routers, modems--More than 100,000 hosts invaded(蠕蟲透過家用路由器與modem養botnet,超過100,000台遭入侵)」。

以上這些報導,都引述了Terry Baume在一月11日時所公佈的研究報告(PDF):「Netcomm NB5 Botnet–PSYB0T 2.5L」。其實這篇中就已經把該攻擊描述得很完整了,並也開門見山地用紅字點出,PSYB0T應該有能力感染其他機型之路由器(但是僅限於linux mipsel,非CISCO IOS或Juniper freebsd)。Terry也指出,在他兩天的觀察其內,PSYB0T由一天感染兩台路由器,迅速加速到一天感染20台路由器的速度。Terry發現該蠕蟲有利用UPX加殼,解殼後可以利用MIPS的反組譯器(如RecStudio)來進行反組譯及分析。Terry也利用反組譯來分析了該蠕蟲並詳細說明了其行為。

Teamfurry的blog上則指出,經過了三個月,PSYB0T已經有了演進,應該是看到了Terry的blog,所以雖然還是用UPX加殼,但是之後手動做了修改(駭客不看blog?不夠水準的blog當然沒人看)。Teamfurry的解殼法則是先手動將修改復原,然後一樣利用UPX解殼,分析後,發現版本字串已經從當初Terry看到的"2.5L"變成"2.9L"了。Teamfurry指出,該攻擊可怕的是,可以竄改DNS設定,也可以隨意轉址到非法的網站。

Dark Reading也於同日報導了此事件,並說:「Routers traditionally have been considered relatively immune to malware and attacks, and botnets traditionally used PCs and servers.(路由器以往是被視為比較不會遭受惡意程式攻擊的,僵屍網路以往則針對個人電腦跟伺服器)」。Dark「」 Reading並訪問了路由器安全專家FX(Felix FX Lindner,前一篇我們介紹過),FX說:「惡意程式已經開始利用路由器了,但是在這個事件中,目標還只是簡單的linux。」

仔細看一下此事件使用之技術,NB5是用MIPS處理器,跑embedded linux,有Web的管理介面,也可以開啟telnet/ssh。有大量的NB5,出廠時,這些管理介面是對WAN端也開放的,並且不需密碼或密碼為出廠的"admin"/"admin"。PSYB0T之動作步驟如下:

1. 用多種方式設法取得shell(telnet/ssh),包括嘗試出廠設定,以及用暴力法猜帳號密碼等(所以太弱的帳號密碼也會被攻入,如"netcomm"/"netcomm")。
2. 利用http或tftp下載蠕蟲本體並於背景執行。
3. 關閉對外之所有port,避免他人進入或重複感染。
4. 連往某些特定之 IRC server,加入IRC botnet,開始回報並接受指令。
5. IRC 指令包含了攻擊其他NB5散播本體,攻擊MySQL,攻擊phpMyAdmin,各種DDoS攻擊,port scan,監聽流量並偷帳號密碼等。

無獨有偶,雖然兩件事無關,但又隔日(三月25日),Cisco發出了advisory,集合了8篇advisory,一次公佈了8個CISCO IOS的弱點,並提供更新程式下載。由於公佈的弱點頗多(包含了TCP、UDP、無線 IP以及VPN等),SANS也於同天發了一篇關於路由器的diary:「Cisco Releases IOS Bundle of Vulnerabilities(Cisco釋出IOS弱點修正集合)」。Dark Reading則似乎收到消息Cisco會於25日釋出advisory以及更新程式似的,於24日先長篇大論地討論了路由器的安全:「Hacking The Router Patching Conundrum(破解路由器修補之謎)」。

標題下面大大的黑字寫著:「最近的研究已經證實了路由器並不像以前想像的難入侵,企業以後若無法在不影響網路運作下,定期安裝路由器修補程式的話,將倍感壓力」。DearReading介紹了FX最近對路由器安全的研究(我們在前一篇有介紹),FX則表示,問題出在IOS目前沒有修補程式,每次都需要更新整個IOS image。但是更新整個IOS image後,常會導致設定或軟硬體不合等問題。Dark Reading表示,更新路由器軟體常常不被視為是高優先的工作,目前也少有企業有建立對路由器軟體更新之程序與規範。

去年因為在BlackHat / DEFCON 2008上公開DNS漏洞之超級紅人Dan Kaminsky(這裡有我們的報導,另外其實他一直很紅)則表示,他們(IT)從沒去考慮外頭那麼多的路由器。他們缺乏資源,工作量超過負荷,除非有很好的理由,不然不可能再去監控另一種問題(路由器)...但是FX的研究已經給了最好的理由。

FX則說:「所有我認識並談過的企業與電信業者,當有IOS的更新公佈時,沒有一個單位有去做更新,因為更新IOS所帶來的危險比被駭的危險更高。」Cisco的Russ Smoak則表示,部分的客戶會上更新,部分則不會。「我們的客戶廣布於每一個角落;有的遵循嚴謹的規範並勤勞地更新,有的則擁有老舊的平台。」Kaminsky說:「你不用緊張,但是廠商叫你更新時,你就是必須要更新。」

好了,談到這邊,我們來回顧一下,我們於三月8日第一次探討路由之安全,並於三月15日寫的「從大規模轉址事件看IP spoofing、ARP spoofing、ARP掛馬與路徑(route)安全」中有提到,2008年,對於路由器安全的研究突然很多,一個Black Hat 2008竟然有三場相關演講。又提到:


去年九月底,Alexandre Cezar在ISC2(推出CISSP認證的組織)的blog上寫了一篇:The most vulnerable device in the network,他說最近與朋友討論,整個網路(使用者機器不算)上,最脆弱的機器是什麼。「The answer of almost everyone in the table was: Routers...(所有人一致的回答都是:路由器)」。文章中他列舉了router上可能有的威脅,另外我很喜歡他回Tim Bass的留言(泰國OWASP分會會長,上次OWASP有來與大家見面)時說的:「And you're right when you said that there aren't many exploits for routers but my main point is that you don't need exploits to compromise a router, you just need to found a misconfigured one and the Internet in plenty of them(你說路由器的攻擊程式不多,我同意,但是重點是,入侵路由器並不需要用弱點攻擊程式,你只需要找到一個沒有設定好的路由器,而網路上多的是)」這根FX在演講中說的一樣,其實現在掃瞄路由器還是可以發現很多設定上的錯誤,弱的密碼等等,攻擊路由器不一定需要用到他們研究的這些新技術。


其實掌握資安威脅趨勢並不困難,許多事件的發生都有跡可尋。此事路由器蠕蟲事件,其實在一月時,Terry Baume公佈的研究報告(PDF):「Netcomm NB5 Botnet–PSYB0T 2.5L」就已經分析得很完整了,可惜當時並未引起大家的高度關注,才會讓感染的機器不斷攀升。另外,這台NetComm NB5有蠕蟲出現,其實也不意外。這台很多人喜歡玩,早在2005年4月左右,如何編譯適合這台執行的程式之方法,就已經被公開得很詳細了。「Exploring the Netcomm NB5 - ADSL / ADSL-2/2+ Modem Router」一文中,將步驟一步一步地描述得很完整。

三月21日,活了三個月之久的路由器蠕蟲終於受到媒體與SANS重視,三月24日,媒體與SANS也因為Cisco即將發佈的安全更新而大幅探討路由器安全問題。三月初我們探討路由安全問題時,許多資安專家抱持懷疑的態度,質疑「何謂路由器被感染,什麼鬼東西,從沒聽過」,或「感染路由器後要做什麼」等。這顯示大家對於此類威脅比較陌生,可能是之前國內類似案例並不多(或公開的不多)。其實比較早進入資安研究的朋友,應該對這些network層的威脅都不陌生;在沒有Web的年代,這些很多都是駭客很熟的技術。加上這幾年路由器上之威脅不斷被公布,實際的案例也一一出現,負責的資安研究人員,應該要能隨時掌握最新的威脅趨勢,提早警告客戶與大眾,做好事前的預防,才是減少資安成本的關鍵。我們在做事件處理時,常覺得,事前與事後,在成本上真是天差地遠,只要充分掌握威脅趨勢,事前的預防其實不難,但是如果沒做好準備而讓事件發生了,真是客戶累,我們也累,雙方所花的時間,很多用於善後,而非提升資安水平,可說事倍功半。

作者 Wayne 為 阿碼科技CEO

相關系列文章:
2009/03/08 「大規模網頁綁架轉址:威脅未解除,但專家都猜錯了
2009/03/12 「大規模網頁綁架轉址之水落石出篇
2009/03/13 「回答IP Spoofing 的問題
2009/03/15 「從大規模轉址事件看IP spoofing、ARP spoofing、ARP掛馬與路徑(route)安全
2009/03/27 「網路藍色藥丸?首支攻擊路由器之蠕蟲出現:再談路徑之安全性

繼續閱讀全文...

2009年3月15日

從大規模轉址事件看IP spoofing、ARP spoofing、ARP掛馬與路徑(route)安全


「優秀的鑒識人員除了要懂得物證的處理外,還要用科學的頭腦來思考。物證雖然能夠提供重要的線索與證據,但是要能解開整個迷局,就需要用頭腦串連所有的物證。在我處理過的六千多個案件中,就遇到單憑一件物證破案的案件」--李昌鈺

這次的大規模轉址事件,受到各界關注,我們也寫了兩篇(這裡這裡)我們對事件的研究。大家這麼注意這次事件當然是有道理的,因為這麼大規模的轉址,持續時間又久--到底發生了什麼事?我們寫出我們的看法後,收到很多網友的問題,於是我們又寫了一篇回答,但是大家還是有很多問題,我們持續收到email與留言。我們在這邊將所有的問題與我們的回答整理成一篇,並也藉此機會,討論一下什麼是IP spoofing、none-blind IP spoofing、ARP spoofing、ARP掛馬 等,供大家參考。另外,我們收到很多網友寫信來或留言的鼓勵,我們真的非常的高興,也非常的感謝,各位的鼓勵是我們最大的動力,我們會繼續努力,謝謝各位對我們研究的肯定,也請不吝批評指教。

[事件最新發展]
1. Cisco於三月12日更新了alert報告,提及「可能是non-blind TCP spoofing或其他種類攻擊」,整個報告第一句:「Reports indicate that some TCP traffic that is passed through certain Taiwanese networks is being redirected to malicious websites.」(TCP流量經過台灣的某些網段時遭攻擊,部分使用台灣的使用者可能受影響)。這跟我們的研究結果是一致的,攻擊者位於route上。另外,我們沒有說攻擊程式位於route"r"(路由器)上,我們一直的說法都是,攻擊程式位於route上,差一個字差很多。

2. Juniper也同意我們的研究:「Juniper先進科技部資深技術經理林佶駿於今(12)日受訪時表示,從阿碼科技等提供的證據來看,神秘網頁轉址攻擊確實有可能發生在210.65.255.241到211.22.33.225這個路徑(route)上,但就此斷定中華電信的路由器(router)被動手腳或遭入侵的可能性並不高。」我們本來就沒有說一定是路由器的問題,我們一直強調攻擊程式在route上,並透過研究證明,有攻擊程式位於距離我們TTL=7以內。這個跟許多人分析說是DNS攻擊,Man-in-the-middle攻擊,網站遭攻擊或遭ARP掛馬,是很不同的,但是我們透過實際的資料與數據證實了我們的看法,也得到了CISCO與Juniper的認同。

3. 這次研究的重點不在於「究竟是否是路由器出問題」。結論重點在於,第一,確定有none-blind IP spoofing,而非DNS攻擊,也看不出有ARP掛馬,這跟其他人的看法很不同。第二,從錄到的封包以及攻擊內容(插入iframe方式)來看,推測攻擊者無法竄改原封包,無法避免原真封包還是抵達受害者,也無法避免真封包比假封包早到。第三,有攻擊程式存在於TTL<=7路徑當中。我們一直說 route 上出問題而沒有說一定是 route"r" 上出問題,大家看文章時麻煩要注意到。

[何謂 Man-in-the-middle (MITM)?]

首先我們定義文中何謂「Man-in-the-middle」(MITM),我們採wikipedia的定義:「In cryptography, the man-in-the-middle attack or bucket-brigade attack (often abbreviated MITM), sometimes Janus attack, is a form of active eavesdropping in which the attacker makes independent connections with the victims and relays messages between them, making them believe that they are talking directly to each other over a private connection when in fact the entire conversation is controlled by the attacker. The attacker must be able to intercept all messages going between the two victims and inject new ones, which is straightforward in many circumstances (for example, the owner of a public wireless access point can in principle conduct MITM attacks on the users).」

根據這個定義,MITM需要達成以下:攻擊程式負責在兩受害者中間「轉送」流量,並可以控制整個流量。

[何謂 ARP spoofing?]

我們採wikipedia的定義,ARP spoofing是在類乙太網路上,利用發假的ARP封包,達到把自己當成MITM的目的。在這邊要注意的是,要達到監聽封包,ARP不是唯一的作法,也並非最簡單之作法。第一,ARP spoofing只能用於類乙太網路上,第二,達成了ARP spoofing,就必須擔起「中間人」的責任,必須在中間轉送所有的流量,不然可能造成網路癱瘓,這需要一定的運算能力。

[何謂 ARP 掛馬?]

ARP 掛馬並沒有很明確的定義,因為這一個攻擊手法,一個手法會用到一個以上的攻擊技術,我們在這邊定義如下:攻擊者使用類似zxarps這種工具,先在類乙太網路(ethernet-like)上,用ARP spoofing讓自己成為MITM,然後(選擇性地)在HTTP response中插入惡意的iframe,達到攻擊的效果。根據這個定義,這樣的手法包含了兩個攻擊技術:

1. ARP spoofing攻擊,以取得MITM地位。
2. TCP session hijacking,以便修改TCP封包並插入iframe。這其實是zxarps值得注意的功能之一。zxarps的TCP session hijacking做得蠻完整的,因為他會處理到TCP層,修改TCP封包中的SEQ/ACK號碼等。由於其TCP session hijacking實做很完整,在大部分的情況下,看不出異常的流量,除了在同一個乙太網路的broadcast domain(或vlan)下,偵測流量之異常並不容易。

[何謂 None-blind IP spoofing?]

None-blind IP spoofing是指攻擊者可以監聽到TCP/IP流量,並發出TCP s/n對的假封包,並成功讓受害者以為是真封包。然而不同於做得好的TCP session hijacking,none-blind spoofing中真假封包都會同時送到受害者,故在路徑中或在受害者端,都可以利用監控流量之異常來偵測出none-blind IP spoofing。不同於因為監聽不到流量而必須發出大量封包的blind IP spoofing,none-blind IP spoofing通常可以很準確的發幾個甚至一個封包,就能達到效果--這是攻擊者喜愛它的重要原因之一。在無法達成好的TCP session hijacking情況時,或沒有需要(懶得做)時,攻擊者常退(改)而採用none-blind IP spoofing。由於None-blind IP spoofing需要能夠監聽到流量,故需配合其他監聽技巧。ARP spoofing是其中一種方式,但並非唯一方式,也並非最簡單之方式。

[為何你們判斷此次是 none-blind IP spoofing而非其他人說的,DNS攻擊或ARP掛馬?]

如果是DNS攻擊,使用者不會注意到被轉址了,瀏覽器的網址列會顯示對的網址,故排除是DNS攻擊。另外根據我們前兩篇(這裡這裡)所公布我們錄到的資料,依據錄到的封包,確定有non-blind IP spoofing。至於是否伴隨ARP掛馬,目前看不出來有,沒有直接證據,故我們沒有說有,但也沒有說一定沒有。non-blind IP spoofing是錄到的事實,故我們會說一定有。

那麼為何我們沒有說是 ARP 掛馬呢?因為基於以下幾點:

1. 因為如果照上面的定義,利用類似zxarps這種工具做ARP掛馬時,第一,除非我們在同一個vlan下,不然很難偵測出流量的異常,也不會有真假封包同時被我們看到。

2. 由攻擊者的假封包內容來看,明顯地無法竄改原封包,沒有辦法避免真封包的到達,甚至沒有辦法避免假的封包比真的慢到達,所以對方試了很多種方式。如果能夠用ARP掛馬,這些都可免了--可是事實並不是這樣。以下是這次常見的一個假封包的內容:

<html><body><meta http-equiv="refresh" content="4;url=http://www.zhonglie.org"></body></html>

為何要用這種似乎很笨拙的iframe插入方式?原因就是,無法有效達到MITM地位,竄改原封包。我們再來想一想,根據我們收到的封包,確定:1.攻擊者在route中間,2. 攻擊者可以監聽到封包,3. 攻擊者可以發spoofed IP封包到受害者。那麼既然這些都可以做得到,為何不直接使用類似zxarps這種完整的TCP session hijacking呢 (ARP掛馬)?因為如果使用zxarps(ARP掛馬)的話,我們在家裡根本不會收到真假封包,這個攻擊就更隱密了,fyodor與wayne可能也就抓不到攻擊程式在TTL=7之內了。原因是,我們已經證明了攻擊程式位於TTL=7之下,表示位於route中段,而zxarps的使用,需要很多環境的配合,譬如要在類乙太網路上,要有足夠運算能力處理流量並修改TCP的seq/ack等等。如果你對一台路由器做ARP spoofing而自己沒有運算能力處理好所有的封包,那麼你就不是在做TCP session hijacking攻擊而是在做DOS攻擊了--網路有可能會癱瘓。另一方面,很多路由器周邊並沒有接ethernet,ARP spoofing派不上用場。

所以依我們的經驗,在以上三個條件都滿足下,還是有很多攻擊者會選擇用none-blind IP spoofing而不用ARP掛馬,因為後者需更多條件,也因此後者比較常見於使用者端或Web伺服器端,而非route中間。那有沒有同時伴隨ARP掛馬呢?我們只能說,我們沒能力監控整個台灣的網路,就我們自己的流量來說,我們沒有看到有ARP掛馬,再說,即使有發生,要在我們所在的route末端判定是ARP掛馬,也會有相當的難度,因為如果是用zxarps,大部分情況下並不會有流量異常(真假封包)產生。

[好,那麼ARP spoofing呢?]

要達成none-blind IP spoofing,必須要監控流量,而ARP spoofing是達成流量監控的手段之一。但是由於我們證明了攻擊程式位於route中間,在此位置要監控流量,有很多其他常用的方式(見下文),ARP spoofing並非最常用的,因為需要的條件比較多。

[那為何認定是none-blind IP spoofing呢?]

因為從錄到的封包來看,就是none-blind IP spoofing,這是事實,是否有伴隨其他攻擊,就我們錄到、網友錄到並公布於網路上,還有網友私底下傳給我們的部分,都可清楚看到none-blind IP spoofing,但是都沒有ARP掛馬的現象。

Route(路徑)上的安全性

其實雖然我們沒有直接斷定是route"r"被動手腳(我們都說攻擊程式在route上),我們蠻驚訝有些專家認為router或router附近被動手腳的機率很低。有些人提出這樣的問題:

「ROUTER 被感染??「感染」ROUTER??你是說「感染」路由器嗎?」

「如果是在路徑中間發生spoofing,流量要mirror到哪裡?」

「ROUTER被入侵?改設定?」

WOW,哈哈,似乎專家們覺得在router附近做這次的攻擊,幾乎沒有可能似的,真是讓我們很驚訝。我想這跟個人經驗有關吧...說實在的,雖然對外我們都說route上有攻擊程式,並證明在TTL=7之內,但是從一開始我們自己被攻擊並做初步封包分析後,我們肚子裡都有把「router被動手腳了」當作有可能的原因之一。大家不要又失焦去討論那是否就是ISP的責任,這不是重點,況且我們兩人都用同一家ISP,別的ISP有沒有被攻擊,我們也沒有測,另外有些設備的問題,非ISP責任所屬。追究責任,我們沒有興趣,我們只對弄清楚威脅有興趣。為何說與個人經驗有關?因為 hacking in router land,當初是蠻主流的。國小時我從我的300 baud modem開始碰網路,也記得大二時有幸參與資策會的Winking計畫,將一套Waterloo的TCP/IP實做(C寫的)porting到Windows 3.1,並在上面實做一個剛時剛定義出來的WinSock 1.0介面。Fyodor是snort最早的programmer之一。那時都還沒 有什麼SQL injection、Web掛馬這些。但是router一直是攻擊的目標--想想,如果控制了router,能做多少事?我們也經歷許許多多案件,都是router被動手腳,被建tunnel監聽流量(非用ARP spoofing)...我想這是為何我們肚子裡會把router被動過視為很可能的原因之一吧!可能近幾年,攻擊router的相關研究比較少,攻擊都在Web上,大家就把router land遺忘了吧...所以我們想在這邊探討一下路徑上的安全性,但是千萬大家別失焦,我們不是要說問題出在誰,我們只是想就技術方面來討論。

大家記得去年美國駭客年會BlackHat時我們有去並寫一些報導嗎?其實那時就注意到,哈,今年關於router的題目又回來啦!也記得那時IDG(全球最大IT媒體)也有報導(好友Robert寫的):Cisco routers again take hacker spotlight(Cisco路由器又在駭客聚光燈下)(大陸:全球黑客聚会黑帽大会 Cisco路由器再成热点话题)。(當然因為是IDG報的,大部分主流媒體(world-系列)都會刊:PCWorldInfoWorldTechWorld)。談到Cisco要先說明一下,為何大家都鎖定Cisco絕對不是Cisco漏洞比其他家多,而是很簡單的理由--市佔率最高(我們家就有用Cisco三年了一直很滿意)。好了,言歸正傳,其實故事要回到又三年前,在2005年,當時在ISS工作的Michael Lynn,準備在BlackHat 2005上公布他找到的Cisco IOS弱點。他的演講題目為:The Holy Grail: Cisco IOS shellcode And Exploitation Techniques(聖杯:CISCO IOS shellcode 以及攻擊技巧)(這裡這裡有人公布投影片)。原本ISS同意了Michael的演講,但是後來因為Cisco覺得不妥,ISS便與Michael以及大會商量,改講其他內容。由於原本的演講內容,投影片已經壓在大會給每個人的CD片中,講義也已經印了,大會只好同意CISCO小組在前一天進入大會,將已經裝入每人一個的背包內的CD片取出,並一本一本地將大會講義中Micheal的部分撕除(這裡有人公開當初撕書與沒收CD的錄影)。
在英文中,Holy Grail聖杯的意思就是終極境界,是所有人想達到而達不到的。在2002年四月18日的WinHec 2002開場演講上,比爾蓋茲曾說,靜態分析(源碼檢測)一直是是計算機科學的聖杯("Software verification has been the Holy Grail of computer science for many decades"),但是我想對Michael來說,Cisco IOS shellcode,才是真正的聖杯吧!

演講當天,Micheal Lynn上台,原本要講另一個備胎題目voIP security,結果一開始講,觀眾馬上開始噓聲連連。他就問,OK,那你們要聽我原本的演講嗎?觀眾開始歡呼,於是他就講下去了!當然這最後結果是,Micheal被起訴,大會主席Jeff花了二十萬美金的律師費,而Cisco與ISS各花了上百萬的律師費。2007年美國駭客年會DEFCON 15,主席Jeff特別用了一個小時講了這整段事件(影片在這裡,重點約14分鐘後開始),而這邊要提到的是,他在48分30秒的時候說,當時Michael的研究,卡在跟FX(Phenoelit的leader Felix)同一個地方(可能是heap overflow為version-或configuration-dependent,無法做到universal)。結果猜猜Mike如何突破的?他在「一個中文的論壇上找到了答案,已經有中國人先研究出來了,於是他翻譯了內容,並有了突破」--所以你說,亞洲區對路由器的攻擊不熟嗎?

2007年,大會主席Jeff Moss特別在DEFCON上花了一小時講當初之事件

講到FX,他在Cisco IOS上的研究比Michael Lynn可能更為出名。除了更早期的研究以外,他在BlackHat Federal 2003(BlackHat DC的前身)上,有一篇「Cisco Vulnerabilities - Yesterday, Today and Tomorrow(Cisco弱點--過去,今天與未來)」與同年在BlackHat USA 2003上的一篇「More vulnerable embedded systems(更多有弱點之嵌入式系統)」中,已經把Cisco IOS當時被發現的許多弱點,做了很完整的分析,奠定了他在這方面權威的地位。其實不論是FX或Micheal Lynn的研究,都是在討論Cisco IOS的binary exploitation,也就是如何遠端的可以送shellcode給Cisco,讓這些shellcode執行起來並植入後門。在這個領域很重要的研究,是FX在去年年底,於25c3大會上(很棒的資安會議,推)發表的「Cisco IOS--Attack & Defence, the State of the Art(Cisco IOS--攻擊與防禦,當今最高水平)」(投影片在這)(錄影在這裡)

在這個演講中,FX先聲明為何他都針對Cisco IOS而非其他廠牌的路由器做弱點研究:1. 因為在超過一千五百元美金的路由器市場中,Cisco的市佔率大於92%,2. Juniper其實就是FreeBSD所以他沒興趣,3. 其他家用router基本上都是embedded linux。接下來FX提到了入侵路由器的動機,而我覺得特別的是他在動機中所提的三點:1. Windows / Linux 系統現在比較難攻,2. 很多Cisco IOS攻擊程式(exploit)現在反而比Windows攻擊程式便宜,而且生命比較長。Windows的漏洞現在不容易活長,但是很貴,以及3. 如果可以選擇的話,當然是要入侵border路由器而非底層的路由器。接下來FX介紹了Cisco IOS的架構,如何做鑑識,以及他開發的鑑識工具CIR(Cisco Incidence Response)。然後,FX開始解釋如何達成穩定的緩衝區溢位攻擊並執行shellcode。他解釋,之前公布的攻擊方式,最大的問題都還是跟IOS的版本有關係,沒有辦法做到在多數版本都可穩定的將shellcode執行起來。在這方面,FX用了很類似去年加州UC Sandiego大學Shacham等人在美國駭客年會BlackHat USA 2008發表的「Return-Oriented Programming」技巧,並找到可穩定執行shellcode的記憶體區間ROMMON,成功實做出了穩定且跨IOS版本的緩衝區溢位攻擊。精彩的部分是,FX並當場用他帶來的Cisco路由器做了demo。他利用了該路由器IOS在解碼IP options欄位時的緩衝區溢位錯誤,利用一個單一的ICMP封包(等於一次ping),就達成了溢位成功並執行shellcode的目的。

接下來是如何撰寫可穩定執行且跨版本的shellcode。FX提及了早些日子,Andy Davis提出的「Version-independent IOS shellcode(跨版本IOS shellcode)」並不夠stable,然後提出了他自己的作法,並說明為何該方法可使shellcode穩定並跨平台的執行。接下來他提出了,一旦可以穩定並跨版本的溢位攻擊Cisco IOS並執行shellcode,可以做的事情有哪些。最後他說,如果我說我是Cisco IOS的第一人,那就太自大了。其實外面有很多人都跑得比我前面,所以這些攻擊在外面應該都有出現了。

好,回到去年IDG在BlackHat USA 2008前的報導:Cisco routers again take hacker spotlight(Cisco路由器又在駭客聚光燈下)。報導中說,在Michael Lynn之後,路由器的弱點研究似乎就不太被公開了,一直到去年,BlackHat USA 2008大會竟然同時出現三場有關路由器弱點的演講。這時的Cisco對2005年Lynn的事件已經持很開放的態度了。Cisco的CSO John Stewart非常誠實的說,當時Cisco有理由,但是做得太過了。「那時我們做了一些愚蠢的事情,這是為何我親自決定今年當白金贊助商,因為我覺得我們應該做些補償。」主席Jeff則認為這幾年沒有研究員再公開Cisco漏洞,跟Lynn事件並無關係。他認為這是因為地下經濟成熟了:「Lynn那個弱點直二十五萬美金。」BlackHat USA 2008中,Core的研究員Ariel Futoransky給了一場「Viral Infections in Cisco IOS(病毒式感染Cisco IOS)(投影片)。對,你沒看錯,他用了「Viral(病毒式)」與「infection(感染)」這兩個字。用在路由器上很奇怪嗎?其實也還好啦!這個研究是他與同事Gerardo Richarte與Sebastián Muñiz共同完成的,而他們其實在稍早的EUSecWest上,就已經先發表了一篇:Killing the myth of Cisco IOS rootkits:DIK Ios rootKit(Cisco IOS rootkit解密:正宗IOS Rootkit)(PDF paper 下載),並宣稱他們的方法可達到高度的隱密性--這個應該是第一個被公開的Cisco IOS rootkit。Cisco隨後發表了「Cisco Guide to Harden Cisco IOS Devices(Cisco官方強化IOS設備手冊)」;媒體報導可見:英文:The Register, Rootkits on routers threat to be demoed--Networks own3d台灣:Digitimes,可入侵思科路由器的Rootkit軟體近期內將公開亮相大陸:1. Rootkit兵临城下 思科忙为路由器打补丁2. 思科发布路由器补丁程序,但忧虑仍在

Gyan Chawdhary與Varun Uppal,則發表了:Cisco IOS Shellcodes/Backdoors(講義下載),他們認為Cisco並沒有真正把Lynn發現的漏洞修補好,並提供了三段shellcode來證明他們還是可以繞過Check Heap防禦機制並執行shellcode。不像FX的shellcode,當時這三段都還有寫死的記憶體位置,故應該無法很穩定及跨版本的執行。最後,FX也在會上給了一場演講:Developments in Cisco IOS Forensics(Cisco IOS鑑識的近期發展)(講義下載)。這裡他發表了先前介紹的Cisco IOS鑑識工具CIR(Cisco Incidence Response)

至於控制了路由器後如何監聽流量呢?既然已經可以控制路由器,當然就不需要用到ARP spoofing了--tunnel或mirror都可以。2000年的Phack 56中gauis寫得蠻簡單清楚的:Things to do in Ciscoland when you're dead這裡有大陸的翻譯)。另外要攻擊路由器也不一定要植入shellcode這麼複雜--外面這麼多SNMP bruteforcer不是沒有原因的。Wolfgang 2003:Exploiting Cisco Routers,Hidalgo 2005:Cisco SNMP configuration with a GRE tunnel都可以參考。

去年九月底,Alexandre Cezar在ISC2(推出CISSP認證的組織)的blog上寫了一篇:The most vulnerable device in the network,他說最近與朋友討論,整個網路(使用者機器不算)上,最脆弱的機器是什麼。「The answer of almost everyone in the table was: Routers...」。文章中他列舉了router上可能有的威脅,另外我很喜歡他回Tim Bass的留言(泰國OWASP分會會長,上次OWASP有來與大家見面)時說的:「And you're right when you said that there aren't many exploits for routers but my main point is that you don't need exploits to compromise a router, you just need to found a misconfigured one and the Internet in plenty of them。」這根FX在演講中說的一樣,其實現在掃瞄路由器還是可以發現很多設定上的錯誤,弱的密碼等等,攻擊路由器不一定需要用到他們研究的這些新技術。

寫了這些最近有關路由器的研究,我們希望表達的是,這次大家研究台灣大規模轉址事件時,應該要先研究收集到的事實,例如錄到的攻擊封包等,而非說:因為這兩年大陸很多人研究ARP掛馬,ARP掛馬工具很成熟,ARP掛馬網路上資料很多,最近很多ARP掛馬事件,就斷定是ARP掛馬,然後說但是IDC一定不會承認,大家忍一忍事情就過去了等等。如果要這樣想,那麼去年突然迸出許多關於路由器弱點的研究,媒體也開始報導路由器攻擊重成焦點,穩定且跨版本的的溢位與shellcode執行也被公開,第一支公開的rootkit也出現了,那是否就斷定這次是路由器的問題?當然不是。我們可以根據事實來研究,到底是什麼樣子的攻擊?可能出現在哪裡?這樣才知道要怎麼預防,才可以避免下次可能的損失。我們公布的研究結論,都是先根據我們錄到的封包,不是先根據最近這些新聞與研究。最後,我們一直說"route"(路徑)上出問題,但是沒有說判斷一定是route"r"(路由器)出問題,因為我們沒有任何證據,另外路徑上還有很多其他可能。Futoransky去年在BlackHat 2008發表的Viral Infections in Cisco IOS(病毒式感染Cisco IOS),是他自己取的名字。

[收集的一些問題]
「回答IP Spoofing 的問題」中已經有收錄部分問題與我們的回答)

問:IP spoofing和 arp spoofing你好像搞錯了。IP Spoofing指的只是單純偽冒IP。而你單就route尾巴的封包是不可能判斷出IP spoofing的,要做session hijacking,ARP spoofing是要用到的,而不是IP Spoofing。

ARP Spoofing,是現今網路環境作snffing的第一步,藉由了解受害網站與其gateway間的訊號傳送,來控制受害網站間傳輸的資料流,包含偽裝同一來源IP發出相似的封包(是的,這叫ARP spoofing不叫IP spoofing)。不過相對來講,傳統ARP spoofing會製造出大量的ACK/DATA封包。但配合MITM/ARP掛馬,還可以再降低無效的封包量。

只有在同機房有人被佔領,就可以對所有機器進行ARP Spoofing。

答:恩,不是這樣子的,剛好相反,如果攻擊程式在route中間,我們在end端只能看到IP spoofing而看不到arp spoofing。另外arp spoofing不能說是監聽封包的唯一方法,有很多其他方法(見上文)。有些路由器兩兩之間根本沒有ethernet,如何做ARP spoofing?但是還是有其發方法可監聽流量。依我們自己事件處理的經驗,當攻擊程式為於route中間時,使用ARP spoofing來監聽的並不常見,其他方把反而比較常。最後,ARP spoofing不會製造出大量ACK/DATA封包。ACK/DATA是TCP層(OSI第二層)的,而ARP spoofing是第二層的,大量ACK/DATA在TCP session hijacking時可能會出現,但是不是在ARP spoofing時。ARP spoofing會看到很多重複的ARP frames。zxarps這種工具做得遠不只ARP spoofing,他的man-in-the-middle實做了完整的TCP session hijacking,並且有去改seq/ack number,故降低了無效的封包量。所以zxarps這種攻擊並不只包含了ARP spoofing--你講的這些都是TCP session hijacking非ARP spoofing。這些技巧都用了十年以上了,完整的TCP session hijacking的實做以前就很多了。要做session hijacking,ARP spoofing只是其中可能用到的一步,但並不一定會用到。另外,如果真的做了session hijacking,我們在route尾巴就看不到假的IP packet了--但是我們有看到,所以我們說是none-blind IP spoofing,可能有伴隨ARP spoofing,但是也可能沒有。

問:那個.241的推論其實看不太懂,該不會因為兩者匯流於.225,所以直接推斷前一個hop,或TTL=7以下的hop必定是問題點吧?

這樣的推論好像太武斷了,因為B支會收到spoofed封包,只代表B支符合被spoofed條件,而非一定是發生在A支與B支不同的子路徑上。

例如,攻擊條件可能是以來源地區作判別條件,或針對機房中數台分流主機的其中一台作arp spoofed,都會有B支被 spoofed但A支沒事的情況。

另,如果不是man-in-the-middle,則應該會收到大量失效的真封包,包含真正的首頁內容,亦即GET / 後會收到兩個頁面,一個為spoofed host回的,一個為real server回的。但是似乎後者的封包量在測試時出現太少了些。

答:恩,不是這樣子。推論攻擊在TTL=7或以下,是因為TTL=7時,出現IP spoofing,回來的TCP s/n也對,故判定攻擊點一定在TTL=7或以下的route上(請注意我們當初是寫「route」上而非「route"r"」上),這跟另一個route有被攻擊或沒被攻擊,沒有關係。另一個route只是畫出我們實際上的測試環境--兩條route,一條一直有spoofed封包,一條則沒有。這個測試的方法(原本不想講太明,因為攻擊者很容易破解),是我們修改traceroute程式,變成發出不同TTL的HTTP GET封包,而封包跟IE發出的GET封包長得一樣。因為在TTL=6時,不會收到假封包,但是在TTL=7時會,故判斷有攻擊點位於從我到TTL=6的這段route上。不論另一條有沒有被攻擊,都不會影響我們的判定--攻擊的方式是none-blind IP spoofing,而攻擊程式位於離我TTL=7以下的route上。如果如你所說的,攻擊程式在更上方,而利用來源地區選擇攻擊與否,那麼就不會TTL只等於7時,我們就收到了假封包(s/n正確)--因為TTL只等於7,封包不會再往上走。

最後關於您說,「如果不是man-in-the-middle...」這段,簡單回應如下。如果是像zxarps這種把TCP session hijacking實做得很完整,會改TCP seq/ack,那麼網路上幾乎看不到異常的封包,也不會有現在我們看到的spoofed IP packet。那麼如果不是MITM,就一定會有大量的假封包嗎?不一定,看攻擊程式想如何做。一開始,我們看到只有一個封包,並帶FIN把連線中斷。這樣優點是乾淨俐落,比較不會被監控程式發現,但是缺點是,因為沒有含原內容,故使用者很容易發現。

我們來想一想,根據我們收到的封包,確定:1.攻擊者在route中間,2. 攻擊者可以監聽到封包,3. 攻擊者可以發spoofed IP封包到受害者。那麼既然這些都可以做得到,為何不直接使用類似zxarps這種完整的TCP session hijacking呢?因為如果使用zxarps的話,我們在家裡根本不會收到真假封包,這個攻擊就更隱密了。

原因是,zxarps的使用,需要很多環境的配合,譬如要在ethernet上(ARP spoofing只能在ethernet類的網路上用),要有足夠運算能力處理流量並修改TCP的seq/ack等等。如果你對一台路由器做ARP spoofing而自己沒有運算能力處理好所有的封包,那麼你就不是在做TCP session hijacking攻擊而是在做DOS攻擊了--網路會癱瘓。另一方面,很多路由器周邊並沒有接ethernet,ARP spoofing派不上用場。

所以依我們的經驗,在以上三個條件都滿足下,還是有很多攻擊者會選擇用none-blind IP spoofing而不用zxarps這種ARP spoofing+TCP session hijacking,因為後者需更多條件,也因此後者比較常見於使用者端或Web伺服器端,而非route中間。

None-blind IP spoofing被攻擊者喜愛的另一個原因,就是因為他需要的封包少。例如在一開始的案例中,只用一個封包就可以達到轉址的目的了,而不用實做整個複雜的TCP session hijacking。

問:我錄到了ARP spoofing攻擊!這是否代表就是伺服器端有ARP spoofing或甚至ARP掛馬?
答:方便把錄到的流量寄一份給我們嗎?ARP是在layer 2,一般不會跨出vlan,您不太可能錄到伺服器端的ARP封包。如果真的有錄到ARP spoofing,那建議先檢查您vlan內的設備。

問:看這次錄到的封包,假的就只有一個封包,這怎麼會是none-blind spoofing?
答:None-blind spoofing被攻擊者所喜歡的原因,就是因為需要的封包很少。Blind spoofing則需要很多封包。

問:據說TTL可以造假,那你們的實驗有意義嗎?
答:就跟其他的IP封包欄位一樣,在IPv4下,IP封包整個本來就是誰都可以發,欄位怎麼填都可以。但是除非路由器特別被改過,不然每轉送一次會將TTL減去一,所以當TTL=7時就已經有假封包回來,可以讓我們大略知道攻擊程式所在區域。例如這個例子中我們可以知道,這個被我們測到的攻擊程式,不太可能位於Web伺服器附近(Web伺服器附近有沒有其他攻擊程式,不知)。

問:據說TTL不論等於幾,都可以傳到Web伺服器那邊?
答:你聽誰說?:)

作者 Fyodor Yarochkin 為 o0o.nu 成員
作者 Wayne 為 阿碼科技CEO

下一篇系列文章:
2009/03/27 「網路藍色藥丸?首支攻擊路由器之蠕蟲出現:再談路徑之安全性

相關系列文章:
2009/03/08 「大規模網頁綁架轉址:威脅未解除,但專家都猜錯了
2009/03/12 「大規模網頁綁架轉址之水落石出篇
2009/03/13 「回答IP Spoofing 的問題
2009/03/15 「從大規模轉址事件看IP spoofing、ARP spoofing、ARP掛馬與路徑(route)安全
2009/03/27 「網路藍色藥丸?首支攻擊路由器之蠕蟲出現:再談路徑之安全性

繼續閱讀全文...

2009年3月13日

回答IP Spoofing 的問題

最近的大規模轉址事件,由於影響範圍廣大,引起了各方的討論,我們也做了研究與分析。針對這些研究,網友有一些問題與看法,我們在這邊簡單回復。

問1:Non-Blind Spoofing這個攻擊,需要監聽封包並搶在真正封包回應前,傳送惡意封包至client端。這真的有可能嗎?

答1:第一,這是錯誤觀念,non-blind spoofing,尤其是用在HTTP協定上時,並非一定要搶在真封包前,才能達到目的。即使在之後才到達,只要連線還沒有斷,並在sliding window以內到達,要插入iframe還是有可能的。這關係大部分作業系統的TCP/IP實做,這邊不多著墨,但是後來幾天我們已經錄到攻擊者做這方面的嘗試了--如何設計封包,即使在真封包之後到,還是能插入iframe。第二,我們確實錄到的就是這樣,既然已經有錄到的封包,IP spoofing有發生以經是事實(而且還成功達到轉向效果),況且也還有其他網友錄到並放上網路。這是典型的IP spoofing,應該沒有疑問才是。第三,我們也錄到很多spoofed的封包是在真封包到達後才到達的,這次的攻擊並不是每次都能成功。第四,可能您不常見到IP spoofing,或不常處理相關事件,但是我們遇見很多次了,IP spoofing要在route中間達成,並不困難。zxarps有很多很強的技巧,但是並不是有了zxarps才有spoofing,spoofing自90年代至今已經歷史悠久了。我還記得2006年二月時讀Dancho Danchev的blog,他將spoofing的問題嚴重性描述得很好,並從ANA Spoofer Project中拿了一張表來秀,大致上,網路有四分之一是可以被spoof的:

source:Dancho Danchev's blog, taken from ANA Spoofer Project


問2: Non-blind spoofing必須能夠聽到封包。那麼spoofing點會在哪裡呢?有可能是在route中間嗎?在伺服器端使用arp spoofing來監聽封包不是比較容易嗎?
答2:恩,好問題。在伺服器端用arp spoofing來達到監聽封包並發送假封包,比起在路徑中利用入侵路由器或其他網路設備來達成,誰難誰易,要看路徑的網路架構與伺服器端的網路架構而定。這就像是問,ISP/電信業者的資安做得比較好,還是msn.com/cnet.com的資安做得比較好?今天大量民眾被上網被轉址已是事實,問題有可能發生在每個各別的使用者,或中間的線路業者,或網路的設備,或伺服器端的網站farm。這次被轉址的網站都很大,中間的電信業者也都很大,大家都是很專業的公司,我們沒有否定任何一方的專業能力,我們只是就我們所研究出的事實,進行分析。就我們的分析,TTL=7時,就已經有spoof封包,而且每個封包的s/n都很準,故我們推論:1.攻擊程式可以看到封包,2.攻擊程式在路徑TTL=7以內。

問3:某ISP是天天檢查網路的,都沒有發現異常,你覺得有可能中間有spoofing程式嗎?
答3:這次被轉址的都是大型網站,msn.com、cnet.com等等,而ISP也都是很大,很專業的。我們相信不論是網站,或是ISP,一定都是每天檢查網路,我們也很相信這些單位的專業度。然而世界上最高機密的單位/組織,幾乎都曾被入侵過,資安就是這樣,在先天不安全的架構上,與駭客的戰爭是不對等的:防守難而攻擊易(IPv6會好些但是不知等到何時),而在台灣,大規模轉址的事件也還是發生了。既然已經發生了,重點不是討論責任歸屬:有可能是這些網站,也有可能是ISP,也有可能是某個設備,也有可能是使用者本身。但是我們要用科學的方式去研究這個事件,才能在未來避免重複的事件發生。這次沒有大規模轉址到攻擊力強的惡意網址,但是下次呢?難道要等大家都被轉址到惡意網址,被感染了,才來討論誰的責任?為何不事先研究,預防,來減少損失?我們只不過將我們所錄到的,加上我們的經驗,公布出來,並表達我們的看法。這對大家都有幫助。什麼是科學的方式?就是根據事實的研究。根據錄到的封包,IP spoofing發生了,這是事實。

問4:如果是在route中間發生spoofing,流量要mirror到哪裡?
答4:有很多方式,我們自己就有碰過tunnel到第三方的。在大部分的路由器上,設tunnel並不難。其實這樣子的攻擊,以前還蠻常見的。有些網管會把switch/router設mirror到IDS,此時如果該IDS失守,流量也就可以監聽了。如果路由器有與其他設備或電腦在同一個collision domain的話,那就可以利用如ARP spoofing的方式來達到監聽,也就不需要mirror流量。依據架構的不同,有很多不同的可能性。然而在路徑中使用ARP spoofing,對象是路由器,這跟在伺服器端使用ARP,對象是web server並不一樣--對路由器使用arp spoofing比較難(不造成混亂比較難)。

問5:你們這次有依循responsible disclosure嗎?
答5:有的,在公開前,我們已經用電話與網路與相關單位聯絡,並有討論如何公開。另外,responsible disclosure一般是針對對於弱點的揭露,尤其針對0day的揭露。Responsible disclosure遠在沒有網路時,在鎖匠的社群中就廣為被討論了,現在大家也有了很明確的共識。揭露弱點需要依循負責的揭露程序,因為一旦弱點揭露後,會讓更多惡意人士了解此弱點並加以利用,造成更大的損失。但是我們今天談論的是一個事件,非一個弱點。這就像大砲開講Roger會討論某某網站被植入惡意程式一樣。大家是否注意到,Roger從不針對某某網站如何被掛馬進行討論?因為這就變成是討論弱點而非事件了。事件已經發生,我們可以就事實討論。針對此大規模轉址事件,我們是很後期才加入討論與研究的,之前已經很多網友與專家發表看法,並錄下封包公布。針對此事件,大家都在討論,到底是msn/cnet網站出問題?還是ISP出問題?還是設備商?這是一個選擇題,但是我們也沒有直接選了答案。我們覺得,至少我們自己的監控中,大規模轉址時並沒有轉到具有高度攻擊性惡意程式的網址(小規模測試時則有,前一篇有說),故此事件除了造成大家不便與猜測外,並未有太大實質的損失(想一想如果轉址的網站是具有高攻擊性的惡意程式或甚至0day,現在會是什麼局面?)。重點應該是討論出事件的手法,把時間花在找出問題,避免往後更大的損失才是。另外,如果問此問題者本身過去有不負責的揭露0day,或甚至販賣0day獲利的話,這個道德性的問題,應該自己多想想,不是來問我們。

問6:那這次到底是non-blind IP spoofing還是ARP spoofing還是ARP掛馬?
答6:依據錄到的封包,確定有non-blind IP spoofing。至於是否伴隨ARP spoofing,沒有直接證據,故我們沒有說有,但也沒有說一定沒有。non-blind IP spoofing是錄到的事實,故我們會說一定有。Non-blind IP spoofing需要能監聽流量,其中ARP spoofing是可以達到監聽流量的方式之一,但不是唯一方式,且在路徑中使用困難度高。ARP掛馬的定義則還沒有那麼嚴謹。我們只能說,依據封包的特性分析,這次並不太像是大家手上的zxarps這個工具所發出的封包。另一方面,如果能夠ARP spoofing,攻擊會漂亮得多,因為可以直接man-in-the-middle,可以直接竄改封包,植入想植入的東西(例如iframe),不會有真假封包之分,也不會需要搶先真封包來提高成功的機率,我們在偵測與研究上也會更困難。可是這次的攻擊,就我們錄到的內容,很明顯的,攻擊程式無法直接man-in-the-middle修改封包,才會試了很多麻煩又不漂亮的技巧。這些上一篇都有提了這邊就不重複贅述了。(見上篇圖五--多麼辛苦的iframe插入方式啊!)

問7:這一兩年大陸的駭客充分探討研究了ARP掛馬,工具也成熟,有很多資料可以參考,是最有可能的方式,為何你不認同?
答7:我們當然了解這兩年ARP spoofing或ARP掛馬,在大陸很流行,工具也很成熟。但我們並沒有假設攻擊者一定來自大陸!另一方面,IP spoofing是從90年代就很常被用的手法,太多人會了,也太多很成熟工具了,ARP spoofing亦然,這些都不是這一兩年的知識。我們做研究,看得是事實,這次看到的,攻擊者沒有辦法竄改封包,沒有辦法避免真封包的到達,甚至沒有辦法避免假的封包比真的慢到達,所以對方試了很多種方式。如果能夠用ARP掛馬,這些都可免了--可是事實並不是這樣。我們在講的並非什麼最有可能,不是說ARP掛馬很流行就最有可能,我們是探討我們錄到的事實,我們做研究一向如此。

作者 Fyodor Yarochkin 為 o0o.nu 成員
作者 Wayne 為 阿碼科技CEO

下一篇系列文章:
2009/03/15 「從大規模轉址事件看IP spoofing、ARP spoofing、ARP掛馬與路徑(route)安全

相關文章:
2009/03/08 「大規模網頁綁架轉址:威脅未解除,但專家都猜錯了
2009/03/12 「大規模網頁綁架轉址之水落石出篇
2009/03/13 「回答IP Spoofing 的問題
2009/03/15 「從大規模轉址事件看IP spoofing、ARP spoofing、ARP掛馬與路徑(route)安全
2009/03/27 「網路藍色藥丸?首支攻擊路由器之蠕蟲出現:再談路徑之安全性

繼續閱讀全文...

2009年3月12日

大規模網頁綁架轉址之水落石出篇



山高月小,水落石出、清風徐來,水波不興!

最近的大規模轉址事件,由於影響範圍廣大,引起了各方的討論,o0o.nu的fyodor yarochkin(聯絡方式:fygrave 鼠 o0o 點 nu)與阿碼科技的Wayne,之前針對此事鍵做了一些研究,並在前一篇post「大規模網頁綁架轉址:威脅未解除,但專家都猜錯了」中,依據我們錄到的封包,詳述了我們對事件的看法。我們不覺得此事與DNS有關係,也沒有證據顯示此次與zxarps工具的ARP掛馬手法有關。從我們錄到的封包來看,這是典型的,從90年代一直用到現在的IP spoofing。

這兩天,經過一些研究與測試,我們可以在route上準確的指出攻擊程式的所在位子,昨天也已經充分通知相關單位,今天在這裡把結果與各位分享,另外也謝謝Peter Yen與其他朋友提供的寶貴資訊。

最近攻擊有轉緩的趨勢,大部分大型網站的流量已經不再被轉址,但是我們這幾天觀察下來,一直到昨天(今天尚未測試),攻擊程式都還存在,只是不再針對大型網站spoofing,而針對某些特定網站做spoofing,並且不斷更改行為,故我們認為對方正在做許多測試與校調,試圖盡量讓spoofed封包看起來與正常流量類似,以便下次發動攻擊。我們的測試方法是利用一個小程式發送TCP封包,封包裡是HTTP GET request,而再透過TTL的設計,就可以知道當封包經過哪一個節點時,有spoofed IP packet發送回來。當然我們這種測試方法是可以被偵測到的,所以現在公開之後,預計也將增加往後類似測試的困難度。

[攻擊所在位置]
我們從兩個端點進行測試,其中一個端點A是會被攻擊的,而另一個端點B是不會被攻擊的。這兩個端點的匯集處是211.22.33.225這個路由器,而我們同時在兩端點跑測試程式,對目前仍會遭受攻擊的網域送GET封包。測試結果,端點B不會收到spoofed封包,而端點A則每當封包經過第六個節點210.65.255.241(也就是連到211.22.33.225的前一個節點)時,我們就會收到spoofed封包。我們因此可以肯定,在210.65.255.241這個分支中,有攻擊程式。由於資源有限,我們只測試了A與B兩個分支。


(圖一)


(圖二)


[攻擊手法改變]
在我們貼出了「大規模網頁綁架轉址:威脅未解除,但專家都猜錯了」一篇後,立刻觀察到對方在攻擊手法上不斷調整,我們做紀錄於下:

1. id已經不像之前我們觀察到的,固定在0x0100,開始隨機了。其實我們之前沒有明講,但是相信許多網管人員一看到我們的post,就了解到了,裡頭的資訊可以直接用來設定IDS/IPS/Firewall,有效阻擋攻擊吧?像是id固定是0x0100、或FIN與payload同時存在等,可惜我們每次一公開,對方也會跟著改變。下圖錄於三月11日10:30am,第五個封包是spoofed,第六個是正牌的封包:

(圖三)

2. 已經不再是一個封包完成攻擊了。一個封包同時設FIN與帶payload,是很大的特徵,很容易被IDS/IPS/firewall抓到,故這幾天錄到的流量中,對方不斷改變方式,已經不再採此手法了。但是也並不是一次發兩個封包,一個payload一個FIN,而是還是只發一個,而讓正牌的FIN來結束連線。這樣的作法,每個攻擊仍然只有一個spoofed封包(payload),比較俐落,但是由於沒有立刻結束連線(不帶FIN),故根據各作業系統TCP/IP stack實做之不同,可能造成假封包與正封包內容被系統合而為一,因此payload需要特別設計,以免轉址失敗而瀏覽器出現亂碼。我們測試時,對方正不斷調整payload的設計。上圖中,第五個封包的FIN沒有設了,第六個是正牌repy,第七個則是正牌網站送出的FIN。

3. 開始轉向確定有惡意程式的網址。之前雖然轉址網域過去都有許多不良紀錄,但是就這次攻擊事件的範圍,之前沒有看到確實具有攻擊力的惡意程式存在於這些網址中。然而如上圖又下方所示,最新的攻擊中,所轉址的其中一個網址:hxxp://61.218.245.190/_vti_access/index.htm,確定含有四支具有攻擊性,可觸發之攻擊程式(以下為免費網站惡意程式監控服務HackAlert畫面):

(圖四)

4. 開始想辦法隱藏攻擊。見下圖,錄於三月11日10:30am。下圖中,第51封包是spoofed,我們看右下角的payload,這會讓瀏覽器載入一個隱形的iframe(目前是google),而過了四秒後,瀏覽器會reload。由於沒有轉向,這會讓受害者只覺得等了比較久,但是正確網頁最後還是會載入,故不容易發現蹊蹺,而到時候把iframe改成指向惡意網頁而非google,這四秒足夠惡意程式攻擊受害者電腦成功,植入木馬了。

(圖五)

5. 同一個被感染的網段,可能有不只一個的攻擊程式。圖五中,第51封包是spoofed,id=0x0100,ttl=115,payload是隱藏的google iframe,並在四秒後重新載入原網站的內容。第54個封包也是spoofed,id=0xccbb,ttl=113,內容是直接轉向到惡意網址。正牌的回應封包則是第56與58。這很可能是兩組不同人馬所植入之不同攻擊程式,也有可能是同一組人在測試不同版本時忘記把其中一個版本關閉。

(圖六)

6. 攻擊之工具是否是zxarps的改版延伸?這我們一開始就測試過了,然zarpx可實際做man-in-the-middle竄改封包而這次並沒有,另外封包特徵差異非常大(ttl/id/service filed/行為等),故我們覺得應該使用了其他的攻擊程式。

[結論]
針對我們錄到的資料,我們可以做出以下結論:
1. 至少可以測出攻擊程式仍位於210.65.255.241這個節點。另外可以確定並非網站本身受感染。
2. 對方目前不斷測試不同攻擊方式並使得此攻擊完美化,明顯為下一波攻擊鋪路。
3. 在初次很粗糙的測試中,對方可以造成大量轉址,但行為明顯,使用者很容易察覺。在新一波觀察到的手法中,對方一直致力調整成使用者無法察覺之方式。
4. 對方針對我們公布的特徵進行改良,欲使IDS/IPS/firewall無法輕易認出假造的封包。
5. 在小量的測試中,已經含有具有攻擊性並能攻擊成功的惡意網頁。
6. 由於是基礎架構問題,一般使用者無能為力,只能盡量使用https,等待基礎架構修復。
7. 有問題的網段可以檢查路由器與路由器相通的他機器是否遭侵入或竄改設定。

作者 Fyodor Yarochkin 為 o0o.nu 成員
作者 Wayne 為 阿碼科技CEO

下一篇系列文章:
2009/03/13 「回答IP Spoofing 的問題

相關系列文章:
2009/03/08 「大規模網頁綁架轉址:威脅未解除,但專家都猜錯了
2009/03/12 「大規模網頁綁架轉址之水落石出篇
2009/03/13 「回答IP Spoofing 的問題
2009/03/15 「從大規模轉址事件看IP spoofing、ARP spoofing、ARP掛馬與路徑(route)安全
2009/03/27 「網路藍色藥丸?首支攻擊路由器之蠕蟲出現:再談路徑之安全性

繼續閱讀全文...

2009年3月8日

大規模網頁綁架轉址:威脅未解除,但專家都猜錯了

(續集見:「大規模網頁綁架轉址之水落石出篇」


從三月初開始,網路上陸續有消息,連往tw.msn.com、taiwan.cnet.com等網站時,會被自動轉址到www.dachengkeji.com。一開始心裡想,大概又有誰的DNS沒有上patch吧,要不然就是又有DNS 0-day或又有人玩BGP了。過了幾天,威脅還是沒有解除,媒體也都紛紛報導了:

神秘網頁轉址事件 疑為新型態攻擊手法,ZDNet 2009/03/05
DNS遭攻陷,多家知名網站慘被攔截轉址,網路資訊 2009/03/05
[教學]遭遇不明網路劫持該如何自救?網路資訊 2009/03/07
追蹤:轉址攻擊仍持續且惡意碼手法日趨成熟,網路資訊 2009/03/08
微軟MSN首頁遭轉址 疑上層DNS被入侵,IThome 2009/03/06

恩,這麼多的專家都說是DNS被綁架了,跟我的直覺一樣...我那時這麼想。

三月七日中午,我用一台電腦上網,剛好這台的IE首頁沒有改,設的是MSN,結果一開就真的被綁架到dachengkeji了。這個dachengkeji.com,真是厲害,我心裡想,過了這麼多天,威脅都還沒解除。就在這個時候,o0o.nu的fyodor yarochkin(聯絡方式:fygrave 鼠 o0o 點 nu)從MSN上傳訊息來,跟我說最近號稱「DNS綁架」造成網頁轉址的事件,根本跟DNS無關,引起了我的好奇,於是我用WireShark看了一下封包,赫然發現這絕對不是一般的DNS綁架,駭客所有的手法犀利,影響的範圍應該非常大!我在這邊將fyodor與我的研究與各位分享,希望各位如果有想法,也可以讓我們知道。

這一個攻擊利用了兩個技巧:

(1) None-blind spoofing,而這也表示攻擊程式位於從受害者到受害網站之間的路徑上,可以監聽流量。

(2) 有些 TCP/IP stack 在實做上的缺失(bug),目前測試結果微軟的系統有此缺失,但是預計還有其他作業系統會有此缺失。

我用我借WireShark錄下來的封包來解釋這個攻擊手法,當時我正試圖連往http://www.gogrok.com(因為網友說這個網站也會被鎖定轉址)。我當時的IP是192.168.1.129,而gogrok的是202.157.128.202。
以下我們看frame 15--我的機器對gorok送SYN。




Frame 16中,對方送SYN/ACK,注意對方的TTL是56。



Frame 17,我送ACK,three way handshake完成,連線成功。Frame 18,我送http request,request(get)不會特別長,所以都在一個封包裡。注意TCP s/n=752:



Frame 19,對方回應,s/n是對的(752),可是id=0x0100,太巧了吧?TTL也突然變成=115。重點是這個封包設了FIN,另外http response內容--meta refresh轉向。FIN表示對方要中斷連線,而meta refresh則會導致我的瀏覽器轉向到www.zhonglie.org。這個這個封包其實沒有符合RFC 793:SYN/FIN封包不能帶其他payload;所有的payload應該在three way handshake完,FIN之前交換。



Frame 20-21,我方確定中斷連線。Frame 23是正牌網站送來的ACK,s/n是對的(752),TTL也是56,id=0x2087不是0x0100。但是比較晚到,我機器已經認為此連線中斷了,瀏覽器也被轉向了。



這個攻擊的特色是,第一,有正確的s/n號碼,表示攻擊程式位於route上,可以看到封包。第二,利用了有些作業系統(例如微軟)在TCP/IP stack實做上的缺失,使得整個攻擊,一個封包就搞定,乾淨俐落。

很多網友都有在網路上討論:
「連tw.msn.com就被導向http://www.dachengkeji.com/article/index.htm」
「連MSN首頁會轉址到www.dachengkeji.com/article/index.htm」
「進入 iThome Blog網址自動跳轉廣告網址」
「[求助] 連tw.msn.com就被導向http://www.dachengkeji.com/article/index.htm 」
「有辦法檢查本站是否 DNS 有被駭嗎?」(此網域本身被鎖定,點選要小心!)
「tw.msn.com被攻陷了嗎?」
「胡亂轉址」
「封鎖惱人的"www.dachengkeji.com"大乘科技」
「網站新聞 : 關於tw.msn.com被導向到dachengkeji網站的反應已經漫延到我們客戶了」
「[重要]連MSN首頁會轉址到www.dachengkeji.com/article/index.htm」
「[求教] 台服官方网站是不是被别人内链了,看图说话」
「電腦警報:非中毒的網頁自動轉址(3/10更新)」
「連tw.msn.com就被導向http://www.dachengkeji.com/article/index.htm」
網頁劫持

這些討論與報導,但部分訪問專家說的,都不正確。這次的攻擊跟DNS沒有任何關係。另外,目前為止,威脅並沒有結束或降低!三月七日兩點到三點,我用那時的電腦做了些測試,發現每一次我連tw.msn.com都被轉向。但是下午約四點開始,突然不轉向了,我想大概威脅解除了,被感染的路由器修好了。可是三月八日中午,我發現威脅依然存在,但是對於每一個被鎖定轉向的網址,都只轉一次!也就是說,假設你在家裡,那麼只有在你第一次連往被鎖定之網站時,會被轉址,第二次就完全不會了。這是為何我錄的是gogrok.com而非tw.msn.com,因為轉了一次以後就不轉了。我試了很多被鎖定的網址,都是一樣,只有第一次會轉。

網路上判斷比較接近我們的,有Blue在資安之眼所貼的「關於這兩天的轉址攻擊事件」,還有richliu所blog的「某些 ISP 疑似被 hijacking攻擊」。另外,在mobile01上,powerpcer有貼出他的pcap dump,我們看過手法跟我們錄的是一樣的。

Cisco也在三月六號貼出了alert:
CISCO:TCP Traffic on Chinese Networks Redirected to Malicious Websites

我們在這邊整理整個事件相關資料,如果有網友有可以補充的,歡迎留言或email(wayne鼠armorize點com)提供我們!

[攻擊技巧]
(1) None-blind spoofing,而這也表示攻擊程式位於從受害者到受害網站之間的路徑上,可以監聽流量。
(2) 有些 TCP/IP stack 在實做上的缺失(bug),目前測試結果微軟的系統有此缺失,但是預計還有其他作業系統會有此缺失。

[攻擊特色]
(1) 攻擊程式位於route中,很可能在backbone上,故影響範圍廣大。
(2) 一個封包就可以攔截session。
(3) 改版後,一個網址只會轉址一次,造成追蹤困難。
(4) 手法並非目前很多專家說的「DNS感染」。

[遭鎖定轉址的網域]
根據網友的回報,目前已知遭鎖定轉址的網域有:
tw.msn.com (我們自己有測試成功)
www.msn.com.tw
www.gogrok.com (我們自己有測試成功)
taiwan.cnet.com (我們自己有測試成功)
www.orzteam.com
www.92an.com
www.wowtaiwan.com.tw
www.ioage.com
www.ithome.com.tw

[轉址到的網域]
轉址到的網域有:
www.dachengkeji.com
www.zhonglie.org
www.yyge.com
www.ganji.com

[pcap封包下載]
我們有msn.com、cnet.com以及gogrok等三份被spoof時錄下來的封包,可以聯絡我們索取(wayne鼠armorize點com)。

[如何防護]
由於為路徑中有節點遭控制,使用者不容易自保,建議利用https而非http連結網站(如果網站有提供https的話)。如果擔心機器已經因為被轉向而遭受攻擊,被植入惡意程式,可以來信索取阿碼科技的免費Archon Scanner:info鼠armorize點com。

[資安廠商alert]
CISCO:TCP Traffic on Chinese Networks Redirected to Malicious Websites

[相關新聞]
1. 神秘網頁轉址事件 疑為新型態攻擊手法,ZDNet 2009/03/05
2. DNS遭攻陷,多家知名網站慘被攔截轉址,網路資訊 2009/03/05
[教學]遭遇不明網路劫持該如何自救?網路資訊 2009/03/07
追蹤:轉址攻擊仍持續且惡意碼手法日趨成熟,網路資訊 2009/03/08
微軟MSN首頁遭轉址 疑上層DNS被入侵,IThome 2009/03/06

[相關網路討論]
「連tw.msn.com就被導向http://www.dachengkeji.com/article/index.htm」
「連MSN首頁會轉址到www.dachengkeji.com/article/index.htm」
「進入 iThome Blog網址自動跳轉廣告網址」
「[求助] 連tw.msn.com就被導向http://www.dachengkeji.com/article/index.htm 」
「有辦法檢查本站是否 DNS 有被駭嗎?」(此網域本身被鎖定,點選要小心!)
「tw.msn.com被攻陷了嗎?」
「胡亂轉址」
「封鎖惱人的"www.dachengkeji.com"大乘科技」
「網站新聞 : 關於tw.msn.com被導向到dachengkeji網站的反應已經漫延到我們客戶了」
「[重要]連MSN首頁會轉址到www.dachengkeji.com/article/index.htm」
「[求教] 台服官方网站是不是被别人内链了,看图说话」
「電腦警報:非中毒的網頁自動轉址(3/10更新)」
「連tw.msn.com就被導向http://www.dachengkeji.com/article/index.htm」
網頁劫持

作者 Wayne 為 阿碼科技CEO
作者 Fyodor Yarochkin 為 o0o.nu 成員

下一篇系列文章:
2009/03/12 「大規模網頁綁架轉址之水落石出篇

相關系列文章:
2009/03/08 「大規模網頁綁架轉址:威脅未解除,但專家都猜錯了
2009/03/12 「大規模網頁綁架轉址之水落石出篇
2009/03/13 「回答IP Spoofing 的問題
2009/03/15 「從大規模轉址事件看IP spoofing、ARP spoofing、ARP掛馬與路徑(route)安全
2009/03/27 「網路藍色藥丸?首支攻擊路由器之蠕蟲出現:再談路徑之安全性


繼續閱讀全文...