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

(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 「網路藍色藥丸？首支攻擊路由器之蠕蟲出現：再談路徑之安全性」

繼續閱讀全文...

從大規模轉址事件看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-系列)都會刊：PCWorld、InfoWorld、TechWorld）。談到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 「網路藍色藥丸？首支攻擊路由器之蠕蟲出現：再談路徑之安全性」

繼續閱讀全文...

回答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 「網路藍色藥丸？首支攻擊路由器之蠕蟲出現：再談路徑之安全性」

繼續閱讀全文...

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

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

最近的大規模轉址事件，由於影響範圍廣大，引起了各方的討論，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 「網路藍色藥丸？首支攻擊路由器之蠕蟲出現：再談路徑之安全性」

繼續閱讀全文...

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

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

從三月初開始，網路上陸續有消息，連往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 「網路藍色藥丸？首支攻擊路由器之蠕蟲出現：再談路徑之安全性」


繼續閱讀全文...

破解點閱綁架手法(Crack Clickjacking)

看完「模擬實戰點閱綁架手法」一文，是否有心得感想呢？沒...挖勒！！

這裡寫些我的心得囉。既然整個「點閱綁架(Clickjacking)」的關鍵在"點選(Click)"動作，如果要靠防護設備或工具，可以選擇如 NoScript 或 WRS ...等，來提升瀏覽環境的安全性，但是都有萬一擋不住的問題，靠別人實在不可靠的。

所以在這裡提供靠自己的解決方案：
1.善用「複製連結」方式
　別忘了滑鼠的右鍵(對慣用右手的人)，如後面數個瀏覽器的附圖可參考。然後貼到瀏覽器的網址列上，這樣還可以檢查及確定要連往的網站。
2.還有「標記(Mark)->複製(Copy)->貼上(Paste)」一式
與前項有異曲同工之妙。
總之，「關鍵時刻」讓食指離滑鼠左鍵遠一點。






也許有人說這樣瀏覽網站會很累人。的確，我不否認。我也絕對不會這樣幹的。
方便與安全總是在天秤的兩端，但也不能因噎廢食，所以這也取決你身處風險，來決定使否該使出絕招的。當發現身處危險環境時，該如何自處？該有何因應呢？至少，在不可信任的網頁或環境(IM or E-Mail...)中，該用這招的。

另外，值得一提的是：對付釣魚手法的觀念與技巧
1.若「我的最愛」中有的連結網址，決不使用其他超連結。
如果「我的最愛」中的連結網址有釣魚網站，這我就不知該說啥了...XD。常見的郵件或網站中連結、IM 送來的連結...等，都是常見會被利用的釣魚網站連結，所以都要特別注意。
2.若是連結不熟悉的網站，一定要選用防護強化的瀏覽環境
你一定要有安全的瀏覽環境，例如 Firefox 3 + NoScript 是個不錯的選擇，當然還有其他強化瀏覽安全的軟體或元件，這是你上網的一個課題，一定得去了解的，透過了解的過程也能熟悉威脅所在。
3.輸入帳密前要先想一想
無論何時，要在網站上輸入帳密時，都要想想是否被騙了？是否連上釣魚網站？很多地方在騙帳密資料的，可以參考這裡，還有這裡。
4.騙術終究是騙術
畢竟騙術中一定有它的梗、釣魚得有它的餌，前面一定都會有很多鋪陳，看多了自然能識破，所以要強化個人敏感度。如果上當了，第一線交由防護設備查覺，對於防禦工事的任何警訊都要加以注意的。第二線也是最後的個人警覺性了，看是否能在最後踩住剎車或進行應變處理。
5.事後補救措施
總是有上當的時候，我也曾經上當的，常常都是因為心急、貪快，現在就知道「戒急用忍」，你呢？你的原因是啥？你一定得去分析、了解，才能知道弱點在哪。所以，查覺上當之後，當然要有因應措施，例如進行密碼變更、系統檢查...等。

現在有很多「虛擬機器」如 VMWare、VirtualPC...等，或許在虛擬環境中上網或進行一般操作，不失為一選擇，即使出問題也可以即時復原，當然在虛擬環境中也應該與重要資料做切割，必要時進行帳密修正，達到一定的安全性。

繼續閱讀全文...

模擬實戰點閱綁架手法(Challenge to Clickjacking)

啥是點閱綁架(Clickjacking)呢？
用講的太慢啦...直接來親身體驗最快。
這裡有我們實作的體驗網站 （IE 已經可被利用）。畫面如下：


實戰點閱綁架，這網頁並無惡意攻擊，只是導向到另外一個 Blog 網頁，請放心。主要在於讓大家了解何謂「點閱綁架(Clickjacking)」，將滑鼠移到超連結處，檢查左下角落的連結網址，發現哪有不一樣嗎？明明是應該要連結到 google 網站的不是嗎？你連到哪了呢？目前已知可以成功的瀏覽器：
1.Firefox 3.0.5
2.Chrome 1.0.154.43
3.Safari 3.2.1 (for windows)
4.IE 7.0.6001

手法剖析：
1.如果瀏覽器有問題(上述瀏覽器)，該連結將不會連結至 google 網站，而是其他網站。
2.如果正常連結至 google 網站，表示不受影響。
3.有心人士可以利用此手法將惡意連結夾帶其中，偽裝成銀行或一般正常連結(URL)。

之前還有一篇文「模擬實戰釣魚網站」，都是希望大家能有些防禦觀念，了解攻擊、詐騙手法，自然就會多一分小心的。

本文同步張貼於「資安之我見」。

繼續閱讀全文...

阿碼團隊跟各位拜年，祝各位牛年大吉、牛運亨通！（另含2008年阿碼大事記）

今年是牛年，對阿碼來說，會是很好的一年，因為牛代表了台灣人努力耕耘的那股勤勞，那股韌性，那股一步一腳印的踏實，那股辛勞耕耘後，牛背飄來一陣涼風都是無比的快樂，很符合阿碼的文化，所以今年，會是阿碼的好年。

去年對阿碼來說，是指標性的一年，也是我們蓄勢待發的一年。回首去年，我們心中除了感謝，還是感謝，感謝產業、學術、政府各界的長官與前輩，給我們在各方面的支持與鼓勵，讓我們這麼一個年輕的團隊，能夠順利地突破許多難關，乘風破浪，創出了連我們自己也驚訝的成績。

我們的 R&D 全部都在台灣，連所有的外籍同事，領的也是台灣的薪水，付的是台灣的稅，看的是台灣的健保。可是台灣的軟體業並不像硬體業那麼發達，台灣的軟體公司，能夠做出產品，在國際上有好成績的，屈指可數。三年前公司成立時，雖然投資人不常提，但是我們知道他們都暗自憂心著，這樣一個高科技的軟體公司，是否真的能在台灣生根？這樣一個年輕的團隊，是否真的能做出成績？是否能支援全系列的 Web 語言？做出的產品，使否真的能讓美國、歐洲、印度、日本的大客戶買單？

去年九月，碰上了百年難見的金融危機，那時我們剛好去紐約參加 OWASP 美國年會，直接感受到了紐約的人心惶惶，我們也不禁憂心，我們的募資是否會受到影響？市場是否會突然萎縮？但是就是這個金融風暴，讓我看到了阿碼的團結與韌性。我想當時大家不說，但是心裡一定緊張，但是沒有人退縮，沒有人埋怨，大家只是更團結，拼了命的往前衝。業務團隊說，可能金融與製造業會受影響，但是沒有關係，我們會拼命從其他地方做業績來補。R&D 說，我們再想辦法讓 SDL 變得更 agile，一定即時滿足客戶的需求，只要客戶還有需求，還有預算，我們就能滿足他們。

就這樣到了年底，一方面我們產品目標：PHP、ASP、J2EE(Java)、.NET(ASP.NET、VB.NET、C#)等支援全部達成，一方面我們業務也竟然超過 forcast，在惡劣的環境中逆勢成長，不只投資人驚訝，說實在我們自己也很驚訝。今年放年假前，我們一算，光一月的業績，就達成了今年第一季 forcast 的九成！這麼好的成績，一方面感謝每一位阿碼同事的努力，一方面感謝台灣與全球行銷伙伴對我們的支持與信心，然後最重要的，就是我們的客戶--我們很榮幸成為各位選擇的 Web 資安廠商，各位對阿碼的支持，讓我們有用不完的精力，我們一定會更加努力，不論在我們的服務、產品的改進或技術的研發上，我們會精益求精，不斷努力，也會珍惜各位給我們的寶貴意見，讓阿碼一天比一天更好！

去年的尾牙上，團隊成員接二連三的上台說了你們的感想，讓我很欣慰，阿碼真的建立了非常不一樣，非常優良的文化，每一個人都這麼在意自己的進步，自己的學習，自己在團隊中的貢獻。很多同事過年前打電話跟我再三的說，真的很高興有機會加入阿碼，阿碼的文化真的很好，這幾年下來學了好多。我聽了當然也很高興，我能說的尾牙上都說了，對我來說，很榮幸能夠跟各位共事，阿碼是大家共同建立起來的，我很高興，也很榮幸我是其中的一份子，跟各位工作，真的非常愉快，也從各位身上，學了很多，真的很謝謝各位。

阿碼準備了很久，從 2001 年我在中研院跟 Walter 開始研究黑箱技術 WAVES，到 2002 年 Chris 從德國加入，到後來我們一起投論文... 到後來 Matt 加入，我們募資，在董事長沙正治先生的領軍下我們成立了公司，後來 R&D 的各位加入，為我們的產品開發注入了能量。去年，產品日趨成熟，Jordan 率領的老外國際業務團隊日有斬獲，在各國都拿下了指標性的客戶，也一步一步把經銷代理伙伴訓練了起來。實力堅強的 X-Solve 團隊的加入，為我們帶來了新的產品線：HackAlert，也為我們帶來了專業的業務團隊。多位資安界的資深朋友的加入，讓我們得以成立了 ASF (Armorize Special Forces) 資安團隊。國內資深的業務前輩，Vincent、Sunrise、Eric 等人願意放棄原本的好工作，加入阿碼跟我們一起打拼，帶來了他們寶貴的經驗，讓我們更有信心，我們一定能提供好的服務給客戶，把支持我們的客戶照顧好。在這邊我也特別感謝阿碼的另外三位創辦人--技術長 Walter、研發總監 Chris、營運長兼財務長 Matt。Walter 還在唸書時就跟我一起做研究寫論文了，是整個團隊跟我最久的一位，能力非常好，但是一路上配合我，在後面當我隱形的伙伴，讓我在前面衝，自己則在後面支援。Chris 是德國人，願意為了阿碼放棄微軟的好工作，不但搬來台北，也把好朋友一起從歐洲挖過來，離鄉背井，幫我們帶著 R&D 打拼；新年期間，看到他們都在線上，知道他們沒地方去，心裡很過意不去。Matt 是我弟弟，能力不比我差，擁有 Stanford 企管系的MBA，待過麥肯錫顧問公司，擁有各種的好履歷，但是一樣，總是站在我後面，給我一切的支援，這次金融風暴，Matt一個人胸膛一挺，一面扛起整個募資的責任，一面繼續擔任營運長，打點公司大小事物與跑國外的大客戶，沒有一點怨言。三位，我想如果沒有來阿碼，三位現在成就可能都超過我，但是每當掌聲響起，我從沒有忘記三位為阿碼的犧牲；其實我從沒忘記阿碼任何一位同事的努力，阿碼是大家一起做出來的，謝謝你們，謝謝大家！

年後將有更多新同事加入阿碼，去年是阿碼蓄勢待發的一年--經過了這麼多年的努力，今年我們將要起飛，我們會讓世界看到，在 Web 資安界，台灣有頂尖的技術能量，有來自各國的菁英團隊，台灣不是只有硬體製造代工業，我們能夠做出符合潮流的的頂尖軟體技術，我們有自己的品牌，我們有一流的軟體人才，我們有國際化的行銷團隊。

最後我們要感謝阿碼的個人與法人投資人，特別是董事長沙正治先生。當初我們一無所有，只有幾篇得獎的論文，是你們給了我們機會，並一路給我們建議、輔導與幫助，我們才能有今天的成績。在金融風暴周遭公司裁員倒閉的情況下，你們繼續支持我們，並以實質股價的成長來肯定我們的成果，給了整個團隊無比的信心，今年我們氣勢如虹，我們一定做出好成績，對於支持我們的投資人，各界前輩，經銷伙伴，還有我們的客戶，我們不會讓各位失望的！我們希望成長，但是我們不想做搶錢的公司，我們想一步一腳印做出我們的成績來，做出我們的價值給客戶，並賺取我們該得的。我們去年不就是這個精神嗎？結果證明我們業績超乎預期的成長。現在資訊發達，客戶都很聰明，懷有僥倖想法的業務團隊，很快會被客戶唾棄。我們慶祝去年的好成績，但是我們絕對不會因此而驕傲，是否是台灣第一，亞洲第一，並不重要，重要的是我們每個人都會虛心學習，不斷提升。我深切體會過自視第一的同行的那種傲氣，那種把同業當笨蛋，把客戶當凱子的不成熟的文化，阿碼絕對不容許有那種文化。我們的策略很簡單，就是我在尾牙上說的，我們很清楚，我們必須謹守我們最有價值的兩項：技術與服務，我們的研發團隊會馬不停蹄地提昇技術與產品的功能，ASF 資安團隊會不斷研究、分析新的攻擊趨勢，充分掌握新的威脅與各種解決方法，業務團隊會無時無刻想著我們還能如何為客戶提供更好的服務，更低的價錢，與更節省成本的產品。技術與服務是阿碼這個年輕團隊僅有的，我們很清楚，我們會盡一切努力提升。謝謝大家一直以來對我們的支持，也希望大家能繼續支持我們，給我們意見，讓阿碼能夠陪伴各位一起耕耘，一起前進！

阿碼全體在這邊跟各位拜年，祝各位新年快樂，牛年大吉，翠柳迎春千里綠，黃牛耕地萬山金！

黃耀文 代表阿碼科技團隊 敬賀

阿碼去年大事記：

1. 完成 CodeSecure 源碼檢測系統於 J2EE 語言支援，ASP支援與全 .NET 系列語言支援（ASP.NET、VB.NET、C#）


2. 推出能與源碼檢測整合之 SmartWAF Web 防火牆


3. 完成 HackAlert 產品開發，並推出含網頁爬行與竄改監控等功能之企業版


4. 獲選新創公司最大獎，Red Herring Global 2008 Innovator's Pit，並於西雅圖發表演講


5. 獲選道瓊 Dow Jones VentureWire 2008 Technology Showcase 技術大展，並於 Redwood City 發表演講


6. 於全球贏得超過五十個指標性大客戶，包含：
   
   
   
   • PriceGrabber（美），全球最大比價網站
   
   
   • MyYearBook（美），全球前三大社群網站
   
   
   • GMO（日），日本最大上市之 hosting 集團
   
   
   • HDB（新），東南亞在資安界最具指標性之客戶
   
   
   • POSCO（韓），韓國最大鋼鐵集團
   
   
   • Innotronic（德），歐洲領先之 ISP
   
   
   • Bank of India（印），印度最大公有銀行
   
   
   • 台灣大哥大，台灣電信業重要指標客戶
   
   


7. 在全球挑選並訓練起超過十家之專業 Web 資安經銷伙伴


8. 參展世貿資安展（台北）、OWASP US（紐約）、OWASP Asia（台北），OWASP India（印度），RSA Conference（美國）


9. 與 COSEINC 共同舉辦 SySCAN Taipei


10. 被 Forrester 與 Aberdeen 等重要分析集團報導為重要 Web 資安廠商

（台灣世貿資安展 2008）

（美國 RSA 2008）

（美國 OWASP AppSec US 2008）

（台灣 SySCAN 2008）

（印度 OWASP AppSec India 2008）

繼續閱讀全文...

雅虎搜尋引擎遭掛馬利用

平常用 Yahoo 搜尋引擎的人要特別注意了。搜尋結果會出現帶有 XSS 攻擊的連結，若是連結目標網站存在 XSS 漏洞，會導致網頁掛馬的攻擊手法，瀏覽者的瀏覽器軟體會遭受攻擊，系統有被植入惡意程式的風險。這可能是網頁掛馬手法的翻新利用，或者是 Mass SQL Injection 攻擊的後遺症。該惡意連結與先前<駭客集團於新年假期展開罕見之大規模SQL Injection攻擊>一文的惡意連結相同。
下圖可以看到"84."的搜尋連結明顯夾帶異常字串。


詳細分析"36."的搜尋連結：


直接搜尋"inurl:daxia123"，可以找到很多有問題的連結：

可以看到很多搜尋連結夾帶攻擊碼，如果點選連結，配合 XSS 漏洞，會導致瀏覽者遭受攻擊。

直接搜尋"inurl:jxmmtv"的連結也是：

手法跟 daxia123 幾乎是一樣的，當然，因為是一夥的。

研判可能原因有兩個：
1.大量掛馬的網頁，造成雅虎搜尋引擎抓到網頁連結時，就是已經被掛馬的連結，導致搜尋連結帶有惡意網址。
2.有人大量餵給雅虎搜尋引擎掛馬連結，導致搜尋結果的連結，帶有惡意網址。

先前 google 也有遭利用，被用來進行掛馬攻擊，可以參考鳥毅-<Googlt Bot會找漏洞>一文。

繼續閱讀全文...

SmartWAF v3 的釋出與新功能介紹

產品前進的腳步是不停歇的，三個月前還在 SmartWAF v2.5 的階段，轉眼間 SmartWAF 已經釋出第3版啦！

如果說 SmartWAF v2.5 是 SmartWAF 2 的強化版，不如說是 SmartWAF v3 的嘗鮮版。 SmartWAF v3 可以說是總合 SmartWAF v2 時代許多客戶的需求以及 SmartWAF v2.5 上的一些實驗性新功能，所推出來的新版本。 SmartWAF v3 整體介面風格並沒有多少改變(預計3.5版會改頭換面)，但是有幾項主要改變與新增功能特色：

1.集中更新派送
其實 SmartWAF 的更新已經很簡單了，有安裝過的人都知道，只是 Web Server 一多，一台台連進去更新總是不夠方便。集中更新派送的功能主要提供給大量使用 SmartWAF 的客戶，透過管理介面就可以遠端更新各台 Web Server 上的 SmartWAF ，就像是企業防毒軟體的中控台一樣，這樣一來，無需一台一台 Web Server 遠端登入然後手動進行更新，版本更新也變得更加方便，另外也可以遠端停止 SmartWAF 運行或是重新啟動。
之前總是會有人會把 SmartWAF 與免費產品拿來比較，這個功能應該在免費的 WAF 產品上找不到吧。

2.支援多處理器
支援多處理器是 SmartWAF3 的一個重要里程碑。過去 SmartWAF 啟動時會同時生出多個 process ，但是並不支援多處理器模式，在多處理器環境下只能為每個 process 分配處理器來利用 CPU 資源。現在 SmartWAF v3 已經支援多處理器模式，甚至還可以指定要使用幾個處理器，一些比較繁重的工作如統計、過濾 response body 等就可以分散給多個處理器同時處理，不再只是佔用特定的處理器，其他處理器卻是閒得發慌。
相較之下，許多免費產品使用單一 process ，也不能充分利用 CPU 資源， process 一旦異常就整組報銷，而流量大一忙碌時，也沒辦法有效運用系統資源。

3.偵測模式與保護模式
在 SmartWAF v3 以前，如果想先觀察規則的嚴密程度，是否有誤擋情形，都必須使用 SHADOW Rules 。許多客戶在試用階段僅需要使用 SHADOW Rules ，另外有些客戶則是把 SmartWAF 當成 WebIDS 來用，一般用戶則在上線前都需要觀察一陣子，因此從 SmartWAF3 開始，提供了兩種模式，分別為偵測模式(Detection Mode)與保護模式(Protection Mode)，用以提供使用者更直觀的操作體驗。
細部的實際操作與過去的 SHADOW Rules 與 ACTIVE Rules 相差不大，只是現在預設都處於偵測模式，相關規則設定、學習、匯入完成並觀察運行一陣子並微調完畢後，只需要切換到保護模式即可上線提供保護，攔阻違規的網頁存取行為。

4.異常警示
異常警示功能在 SmartWAF v2.5 就有了，到了 SmartWAF v3 又有了強化。過去僅能做到系統級別的警示，例如 SmartWAF 總存取量異常增加等，現在可以進一步到 Application 級別的警示，也就是說當某個 Application 內所保護網站的總存取量異常增加時，一樣可以發出示警。另外，現在示警的方式也增加了 SNMPTrap 這種方法，許多有使用用網管系統，或是有 NOC 或 SOC 的單位都可以接收 SNMP Trap。
目前系統層級的警示類型包含：
a. Cluster State - 例如叢集成員斷線或是系統異常無法回應
b. Requests Per Minute - 例如 DoS 或是弱點掃描
c. Denied Requests Per Minute - 例如弱點掃描
而 Application 級別的警示類型包含：
a. Requests Per Minute Per Application
b. Denied Requests Per Minute Per Application
c. New Sessions Per Minute Per Application - 例如弱點掃描或是 Session 猜測

目前發出警示的方法則包括：
a. Mail - 寄送警示至相關信箱
b. Post - 傳送警示至特定網頁
c. LogFile - 儲存警示至特定紀錄檔
d. SNMPTrap - 透過 SNMP Trap 送出警示

預計下個版本還會增加更多的警示類型與方式。

另外還有許多改進如新增的 Preconditions 、新增的 Handlers 、許多 Handlers 內的新增參數、每週及每月 PDF 統計報告、叢集成員系統狀態統計與特定 Handler 狀態統計等，功能強化不少，我就不一一列出了，有興趣試試看的，歡迎進一步連繫囉。

作者 Wisely 為 阿碼科技 產品經理

繼續閱讀全文...

駭客集團於新年假期展開罕見之大規模SQL Injection攻擊

阿碼科技新聞稿 2009年1月5日

此次罕見之大規模資料隱碼(SQL Injection) 掛馬攻擊，於2008年12月24日開始展開，許多知名企業網站均受其害。犯罪集團趁著民眾休假時上網時間增加，以及網管人員可能無法立即處理，本次攻擊從12月24日持續至今，根據本公司SmartWAF所攔截的記錄顯示，此波攻擊中單一網站就遭受來自179個不同攻擊來源，高達500多次的攻擊記錄。相較於先前2008年五月之大規模掛馬攻擊，只有不到 20 個攻擊來源相比，此次規模相對龐大。

此外，此波攻擊之網站掛馬已經含有先前本團隊公布之微軟 IE 7 0-day 漏洞 (微軟已經緊急修補)，故不排出此次大規模攻擊，目的之一為散播此一新 IE 7 掛馬。本次攻擊手法仍然針對後端資料庫使用微軟 SQL Server 的網站為主，透過Google抓出 ”id”、”msgid” 或 “classid” 等關鍵字做為攻擊點，再進行資料隱碼攻擊。本公司估計此波攻擊至少造成百萬以上網頁受害。



攻擊特徵：
(1) 罕見之大規模 SQL Injection 攻擊，單一網站遭受來自179個不同攻擊來源，高達500多次的攻擊記錄。
(2) 掛馬中含有最新的 IE7 0-day 攻擊碼。
(3) 標準假日型攻擊，於2008年12月24日持續至今。
(4) 目標以大中華區的網站為主。
(5) 攻擊來源5筆來自台灣IP，137筆來自於南韓，31筆來自於中國大陸。

攻擊碼：
樣本一：

解碼後為：



樣本二：


解碼後為：



建議處理方式：
A、網站網管人員：
(1)是否遭受攻擊？以攻擊字串中的關鍵字 (例如 “dEcLaRe” 或 “0x4445434C”) 搜尋 Web 伺服器的 log記錄，看看是否遭受類似攻擊。

(2) 是否遭受攻擊成功？以惡意網址中的關鍵字 (例如 “daxia123” 或 “jxmmtv”) 搜尋網頁內容以及資料庫。

(3) 如何預防攻擊？網站遭受攻擊，是因為有 SQL Injection 漏洞。採用CodeSecure源碼檢測，找出漏洞並修補之。如果沒有資源或時間修補，可以使用SmartWAF網站防火牆來阻擋攻擊。

(4) 如何監控網站是否被掛馬？可以使用免費 HackAlert 24小時網頁掛馬監控服務，網址：http://hackalert.armorize.com

B、ISP 網管人員：
(1) 保護一般民眾 – 對於 outbound HTTP 流量，封鎖目標為此次掛馬之惡意網域之流量。本次攻擊所使用的相關網域名稱如下：daxia123、jxmmtv.com、lhaham.cn、daxia123.cn、ghahah.cn、dayoo.com、hhahai.cn、 ihahaj.cn。
(2) 保護網站遭受攻擊 – 對於 inbound HTTP 流量，封鎖來源為此次179個攻擊來源 (IP) 之流量。可來信向本公司索取此次惡意 IP 清單：pr小老鼠armorize.com。


繼續閱讀全文...

開放源碼 World Recipe 2.11 存在多個 XSS 弱點

阿碼科技的資安團隊於本月 12 號發現一套叫作 World Recipe 〈世界食譜〉的開放源碼〈註一〉套件存在有多個跨站腳本攻擊〈Cross-site Scripting, XSS〉問題. 此套件是以 ASP.NET 2.0 C# 所撰寫的, 其具備快速建置, 完整的網站功能頁面與 SQL 資料庫等特色, 獲得不少的口耳相傳與採用.

我們在發現之初即通知原始作者, 並在本月 15 號通知全球弱點公開揭露平台 SecurityFocus, 刊載為 BugTraq 499217: Multiple XSS Vulnerabilities in World Recipe 2.11, 唯目前官方仍沒有針對 2.11 版本的修補程式.

此次揭露的弱點類型都是可利用於跨站腳本攻擊〈XSS〉, 分別是位在建置後網站第一層根目錄

1. emailrecipe.aspx 的參數 n
(譬如http://xxx-website/emailrecipe.aspx?n=XSS)

2. recipedetail.aspx 的參數 id
(譬如http://xxx-website/recipedetail.aspx?id=XSS)

3. validatefieldlength.aspx 的參數 catid
(譬如http://xxx-website/validatefieldlength.aspx?catid=XSS)

等三支的 ASP.NET 網頁. 我們的工具所計算出來的受駭風險指數高達滿分 5 分 (在實務上 3 分以下的攻擊成功機會就非常之低).

validatefieldlength.aspx 這支程式使用到參數 catid, 但沒有正確地驗證與過濾, 因此攻擊方可利用於誤導受駭方執行任意的腳本程式, 請見下圖的概念證明〈Proof of Concept〉:





當然, ASP.NET Framework 不是省油的燈, 在 emailrecipe.aspx 與 recipedetail.aspx 可看到其基本保護, 當嘗試輸入可疑的字串時, 會被 ValidateRequest 攔下. 請見下圖的概念證明:



不過因為 ValidateRequest 是採用黑名單的方式, 多少會有規避的空間. 一旦當攻擊方發現繞過的方式, 剩下的最後一道防線就是瀏覽器本身了. 目前各家的瀏覽器對不同的跨站腳本攻擊〈XSS〉語法有不同的表現, 我們採用了一個對微軟 IE 有效的攻擊語法, 並成功地繞過 ValidateRequest 的攔阻, 目前僅有最新的 IE8 Beta 2 能夠偵測到此跨站腳本攻擊〈XSS〉.
請見下圖的概念證明:



註一: 開放源碼套件以可自由下載, 散佈, 使用, 且多半是免費提供等特色受廣大使用者所喜愛.但開放源碼這種草根性的社群開發模式, 通常沒有強制要求嚴謹的軟體測試或壓力測試, 其軟體品質, 尤其是資安品質, 是否符合使用者的期待, 是有待商榷的. 有一些使用者會認為開放源碼的原始碼是攤在陽光之下, 有比較多的機會被程式高手或資安專家看到錯誤或安全漏洞, 因此其軟體品質或資安風險應該有一定程度的"保證". 很明顯地, 光有這樣的期待是無法有效地量化資安風險, 除非有效地利用源碼檢測等白箱工具來驗證其資安品質, 否則即使諸多使用者或企業樂見開放源碼的多樣化選擇, 也不敢貿然採用.

作者 Dr. Benson Wu 為 阿碼科技 產品經理


繼續閱讀全文...

IE 7 零時差攻擊(Zero Day Attack) 重大威脅警訊

重大威脅警訊: 針對IE瀏覽器的零時差攻擊大量出現
12月9日下午，針對微軟IE 7.0的零時差(Zero Day Attack)攻擊程式碼由"知道安全(Knownsec Team)" 團隊成員貼上網，據 Knownsec 團隊表示在最近的網站掛馬案件中開始有此攻擊碼的出現，針對 Internet Explorer 7.0最新版(7.0.5730.13)進行零時差攻擊。目前已經發現針對Windows XP與Windows 2003 環境的攻擊碼，即使用戶已經更新到最新版(微軟本週更新12月9日IE7，版本7.0.5730.13)還是不能倖免，這就是零時差攻擊之所以危險的原因。阿碼科技ASF團隊立即對此一現象進行分析後，執行長黃耀文在接受 IDG 專訪 時表示，此攻擊方式已經出現大量生產的工具，可能會快速地散播再掛馬網站，而造成嚴重的災情。

1. 此 Exploit 的技術摘要
利用JavaScript產生包含攻擊碼的資料陣列，足以讓IE處理XML內嵌img src的資料時產生跳脫原執行路徑，而執行駭客的Downloader Shellcode，進而安裝木馬後門。

2. 修補程式
微軟定期於每月之第二個星期二，發布修補程式，用戶可透過 Windows Update 更新。雖然昨天(12月9日)之更新，各界已知將更新許多嚴重漏洞(包含 IE 7 漏洞)，然此更新並不會修復本新聞稿提及之 IE 7 零時差漏洞。此次更新之 IE 7 漏洞請見 MS08-073。

3. HackAlert 檢測畫面


4. 被成功攻擊的 demo畫面
https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjt_lOncfRAIpv-LkwATzm1VourQ4M-QFIeuDOFYGG4B6ipoVePzM23VqBozClRUrfbiK-DiIiY01tHOOPCEvaKgF2m7-rrLk_APXWtJB63TwvZwtHj_b_PjLs2_2dMdIfLK9YieP8IfBzT/s1600/TESTBED-2008-12-09-21-26-43.png

5. 相關新聞:
IDG: New Web attack exploits unpatched IE flaw

<防範建議>
1. 暫停使用IE 7.0，改用其他瀏覽器上網，如FireFox或 Opera等。
2. 檢查用戶端之惡意程式掃描記錄是否有異常現象。
3. 可採用阿碼科技所提供之Archon Scanner以行為模式檢查電腦中是否入侵且安裝惡意程式。申請信箱: info__at__armorize.com
4. 使用 HackAlert™ 針對企業網站進行安全監控，避免被掛馬植入零時差攻擊碼，損害客戶電腦與資料安全。申請網址: hackalert.armorize.com

繼續閱讀全文...

阿碼科技受邀至道瓊年度科技創業論壇發表源碼檢測與網站應用系統防火牆整合技術

阿碼科技受邀在11月18、19日兩天所舉辦的道瓊年度科技創業論壇（Dow Jones VentureWire Technology Showcase）中發表演講，該論壇於美國加州Redwood市舉辦，是美國年度科技新創企業最盛大的發表交流論壇，參與對象由VentureWire讀者與編輯群嚴格篩選最有創新與名聲的企業，總計今年全球有75家科技新創公司受邀，到場對潛在投資人、併購企業與合作夥伴發表其營運模式與科技創新。

阿碼科技將由創辦人暨營運長(COO)黃耀明出席並發表阿碼科技獨步全球之源碼檢測（CodeSecure™）與網站應用系統防火牆（SmartWAF™）之整合技術。此項整合技術可以利用最低的成本，確保網站應用程式不被駭客所攻陷，提供可信賴的線上安全營運平台。阿碼科技專精於網站應用系統之安全管理，透過靜態源碼檢測科技提供企業級的旗艦解決方案- CodeSecure™。CodeSecure™是一個網頁式隨插即用的系統，透過靜態原始碼分析與驗證(Static Source Code Analysis and Verification)辨識出網站原始碼中存在的弱點，提供不同風險等級的矯正建議，以取代繁重且高成本的人工程式碼審查(Code Review)，在系統開發生命週期中提供一個有效率、高成本效益，可轉移系統風險的解決方案。

網站應用系統安全是一個相當新的領域，尤其透過靜態源碼分析與驗證更是走在科技尖端的領導方案，再加上阿碼科技獨家研發成功之靜態源碼檢測與網站應用系統防火牆整合技術，此次發表將提供企業經營者一個主動防禦與持續經營商業網站安全的最佳選擇。阿碼科技將在11月18日14:35至15:20於商業營運科技議題中發表，亦歡迎參加者於19日07:00的亞洲區早餐會中蒞臨阿碼科技攤位交流指教。

阿碼科技全方位網站安全解決方案

除了CodeSecure™源碼檢測與分析之外，阿碼科技提供與CodeSecure™密切整合之動態網站應用系統防火牆(SmartWAF™)與持續的網站安全監控與惡意程式偵測服務(HackAlert™)，先掃描後立即阻擋尚未修補之網站安全弱點，提供客戶”立即”的網站安全防護。

關於Dow Jones VentureWire Technology Showcase 2008

Dow Jones VentureWire科技論壇針對最新、最深入的商業科技發展，邀集產業領導企業發表尖端的商業應用科技與營運模式，將全球最知名的投顧與新創企業匯集一堂，讓潛在投資人、併購企業與合作夥伴獲得最有效的投資合作機會。

道瓊年度科技創業論壇地點
Sofitel San Francisco Bay
223 Twin Dolphin Drive
Redwood City
CA 94065
Phone: 650-598-9000
Fax: 650-598-9383

阿碼科技演說發表時段
-11月18日14:35至15:20於Business Technologies Track(Salon 3)
-11月19日07:00 至08:30亞洲區早餐會(Asia Breakfast )

更多資訊請參考 Dow Jones VentureWire Technology Showcase 網站

關於阿碼科技

阿碼科技(Armorize Technologies)是全球領先的全方位軟體安全與網站安全服務供應商，致力於從根源解決Web資訊安全問題。公司總部設於北美矽谷Santa Clara市，全球研發中心於南港軟體園區。阿碼科技產品線包涵蓋完整Web資訊安全解決方案，包含CodeSecure™源碼檢測、HackAlert™網頁監控、SmartWAF™應用程式防火牆等。ASF™（Armorize Special Forces）資安團隊除提供專業服務外，並參與全球重要Web資安年會，發表領導性技術研究。阿碼科技成立以來獲榮獲多科技大獎，包含Red Herring 亞洲科技百強（Red Herring Asia 100）、Red Herring全球創意百強企業（Red Herring Global Innovator’s Pit）、經濟部傑出產品獎、新創事業獎、金根獎科技產業傑出貢獻獎及卓越SBIR研發成果獎項等多方肯定，並於2007年併購艾克索夫(X-Solve)為獨立資安研究實驗室，提供更完整的網站安全與惡意程式檢測服務。阿碼科技的客戶遍布全球金融、電信、政府與科技行業領域。 更多資訊請至阿碼科技網站： www.armorize.com。

新聞聯絡人
John Linehan
02-6616-0100 Ext 401
pr_at_armorize.com



繼續閱讀全文...