回答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掛馬很流行就最有可能，我們是探討我們錄到的事實，我們做研究一向如此。
