「優秀的鑒識人員除了要懂得物證的處理外，還要用科學的頭腦來思考。物證雖然能夠提供重要的線索與證據，但是要能解開整個迷局，就需要用頭腦串連所有的物證。在我處理過的六千多個案件中，就遇到單憑一件物證破案的案件」--李昌鈺
這次的大規模轉址事件，受到各界關注，我們也寫了兩篇（這裡、這裡）我們對事件的研究。大家這麼注意這次事件當然是有道理的，因為這麼大規模的轉址，持續時間又久--到底發生了什麼事？我們寫出我們的看法後，收到很多網友的問題，於是我們又寫了一篇回答，但是大家還是有很多問題，我們持續收到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如何突破的？他在「一個中文的論壇上找到了答案，已經有中國人先研究出來了，於是他翻譯了內容，並有了突破」--所以你說，亞洲區對路由器的攻擊不熟嗎？
講到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 「網路藍色藥丸？首支攻擊路由器之蠕蟲出現：再談路徑之安全性」
訂閱文章
訂閱意見
訂閱文章
11 篇回應 :
推!!!台灣因為有你們,資安知識更進一步
我頂
所以本篇要表達的重點是：作者或是阿碼沒說是某廠牌路由器的問題 但是 讀者應該要知道 作者或是阿碼可以舉出非常多 某公司路由器以前出現過安全漏洞 也還沒被解決
是這樣嗎?? 因為我真的想知道重點是.....??
小弟有個想法....這個問題可能沒有想像的複雜？
該route的ISP業者不是有提供"防毒防駭"、"色情守門員"等服務嗎？這種東西大多是利用監聽封包跟HTTP session hijacking來做的(像是WebSense，去reset你的HTTP request再回應一個他的政策頁面給你，只要把防護目的改成各大網站，回應頁面改成有病毒的網頁...）
從route"R" 監聽流量應該是經常在做的，假設他的mirror沒有把客戶的封包在router上做區隔(IP網段、VLAN、802.1x...)而是全部的客戶都進入了過濾器，而用過濾器內部的政策來區分使用者有否利用此服務，那麼假如這個過濾器被入侵遭修改政策的話，不就很有可能變成現在這種情形？而且他的過濾機器還很可能放在骨幹上，因此可能不分ISP都有可能經過他....
關於重點，這裡主要還是探討技術問題，攻擊手法與技術的問題為重。
有些是歷史的故事，「經驗必須記取，歷史不能遺忘」，攻擊手法持續演變，探討現狀也得回顧以往，其差異才叫演變，這次攻擊手法是否有變？是否為新的攻擊手法呢？這才是我們真正關心的。
我也覺得網友"重重"講的情形有可能，因為有些URL/content filter產品就是使用TCP session hijacking、或是Wayne一直強調的non-blind IP spoofing 技術(兩種技術的產品我都看過)，去介入user及目標網站間的TCP session，並插入HTTP redirect(例如HTTP 302 Moved)將user IE導到政策說明網頁或網址。
如果懷疑這種過濾器，那這裏全部的推論就都無效了。這類設備原理的存在，不但說明了「據說TTL不論等於幾，都可以傳到Web伺服器那邊」，也讓「攻擊者一定在Route」上的推理失去立足點。
畢竟不是每個資安專家都知道現在網路設備的原理，或進過ISP機房。這點錯誤蠻常見的。
To 樓上匿名：錯了，剛好相反。謝謝重重與佑文的看法，事實上，重重講的情形是非常有可能的。我們之前跟相關單位與媒體也都說了，如果中間有為了讓IDS或流量統計系統等看到流量，而有mirror，那麼這就是要高度懷疑的地方。我們一直強調，不一定是 route"r"出問題，那麼route中還有哪些可能？當然就是這些被mirror出去的流量--尤其很多監控系統都是軟體式的，讓攻擊更容易。
之前就已經有網友在真相大白篇中問了：『像是L4 Switch, Transparent proxy, 某些 AntiVirus/AntiSPAM gateway, 或某些IDP都是用session hijacking來實作過濾。亦即，只要在TTL=6的地方有這些設備，仍然會將遠端機房的資料抓給你。因此問題點並不是絕對在TTL=6底下。』我們的回答：『至於TTL=7範圍有多大，我們不清楚，所以我們沒有說「幾個node以下」或甚至「幾個hop以下」，避免混淆，而是說「TTL=7以下」，故並沒有錯（經過某些設備TTL不會減少的話，那都算TTL=7以下）。』
我同意有些資安專家可能真的沒進過機房，像是這次是ARP掛馬，我們就不同意，太多理由不合理。但是我們很熟networking的 ;) Cisco tunnel 我們也打過好些。
至於這段route是否真的有mirror traffic出去？據我們的了解，其實是沒有，所以在blog中也沒多著墨。在真相大白篇也有網友W4y說：『的確有可能會有一些設備去作流量攔截 - 但是在 ISP 的環境內我沒有見過有人擺 Inline 的 AV/AntiSpam Gateway, 在 backbone 擺這樣的設備一則容易造成 single point of failure, 二則沒有幫 ISP 賺錢 (撐 backbone 的設備很貴的) 這種吃力不討好的事中華電信應該不會幹才是。實際上也沒有看 ISP 會在這邊放 inline IPS (理由同上)
Inline IPS 也不應該回 TCP session - 基本上 IPS 檢查封包沒問題後只會放行封包 並不實際攔截這樣的 session』
恩，有或沒有，跟據我們了解：沒有。
不過這都不是重點。重點是，攻擊在TTL=7範圍內，包含任何mirror或relay的範圍。為何這是重點？因為依照我們的研究，一些專家說是ARP掛馬，還有說發生在Web IDC端，我們都認為不是。這是TTL=7最大的意義。TTL=7封包跑不到Web IDC端。
最後，這種過濾器無法說明為何TTL=7還能跑到Web IDC端--TTL=7內不論怎麼被mirror或relay都是跑不到的，還差很遠。
錯了，你們真的沒看過現在的設備。不是mirror或relay。這類設備卡在線路中間直接作透通，你的TCP session看起來透過去，實際上它換掉MAC後幫你作類似proxy的功能。所以你的TCP實際上已經end在設備上了。想想transparnet proxy、syn proxy、某些牌DDoS減量設備，網路加速設備的原理還有某ISP買了一堆的(P2P)限流設備都有這些機制。
你提出來的網段剛好是大陸之前有人抱怨過到臺灣會塞住的瓶頸。中華電信當然不能公布這個節點有什麼設備，但是有這類設備在那裏並不意外。
一旦在你的 route上有一個這種設備，你的TTL=7封包當然不會真的到Web IDC，但是 request仍然會跑到Web IDC裏。
恩，謝謝您的留言，但是不對。我們雖然不像一般管大機房的網管對這些設備那麼熟，但是我們了解您說的設備，這種設備其實我們自己產品也快有類似的了；traffic shaping或相關設備也常常是資安公司在提供的。不過您說的『你提出來的網段剛好是大陸之前有人抱怨過到臺灣會塞住的瓶頸。中華電信當然不能公布這個節點有什麼設備，但是有這類設備在那裏並不意外。』我們完全同意。TTL=6以及7那兩個節點很可能是border router。這些早想過。
關鍵在於，a)我們用的是TCP的traceroute不是ICMP，b)tcptraceroute與ICMP traceroute比對，除了多假封包外其他的結果是一樣的，c)tcp/icmp的traceroute都顯示，web server距離node 7中間還有很多hop不是兩三個hop而已。可能大家沒有注意我們貼出的screenshot，另外因為這個測試方法很好破解，為了讓它活久一點我們當初也不願以太強調。我們文中有說，我們的tcptraceroute發是GET的，不是一般tcptraceroute發的SYN，我們收的則是RST而非SYN/ACK。我們也沒有完成交握，直接發單一的GET。
我們來假設一下，假設msn與cnet都在singtel某IDC，而之前台灣的使用者一直抱怨平寬不夠。於是業者在TTL=7之前加了一個特別的layer 7 switch。這個switch會filter目的=msn/cnet，port=80的封包然後在layer 2利用另外的專線直接傳到msn/cnet所在機房。
如果是這樣，那麼我們traceroute時，TTL=7似乎到不了IDC但是實際上TTL=7的TCP封包卻直接到了。問題是，在我們的實驗中，tcptraceroute與traceroute的結果是一樣的hops。這表示業者並沒有這樣做。如果有，我們就會做其他實驗，不會就因為TTL=7而說，發生點不像其他人說的，於IDC機房，而是在路徑中（或旁，反正不是末端就是了，別鑽文字）。
那再來想，如果ISP在node 7前放的是加速設備（也就是caching設備）呢？那有可能我們的TTL=7封包沒有實際上走到IDC但是我們得到的假封包是cache中的。有兩個原因讓我們覺得機率很低。1)我們沒有完成3-way handshake，而是直接送一個TCP GET，在沒有session的情況下，通常加速器不會cache並回應，因為不知該如何回，2)我們的實驗室重複跑的，跑完一次立刻跑第二次，但是每次假封包出現後，無論立刻再跑幾次，都不會再出現。這個我們有我們的假設，目前不想公開，但是如果真的有cache，為何只回一次？
最後，我們認為此事件是ARP掛馬並發生在Web IDC端的機率很低，故我們有做了實驗並強調在route"中"。這個TTL=7之前有哪些設備，或屬於誰管，我們都不清楚，所以也從來沒有說一定是哪一家ISP有問題，我們只是公布實驗數據。像以上多種情況如果有那很可能這些設備屬不同ISP管。我們的重點在於說，這不像ARP掛馬也不像發生在IDC端發生，不是在說是誰的問題。還有，如果駭客要拿下route中這種設備，最希望的當然是拿下border device，因為流量大，而事件處理又常牽扯兩邊的人。但是拿下border device也有壞處，因為如果有大流量的網站離大部分使用者都很近，如tw.yahoo.com，那變成不會經過border device。所以要鎖定一個地方流量大，但是路徑長，有經過border device的網站，像cnet/msn就是。
張貼留言