阿碼外傳-阿碼科技非官方中文 Blog: 2009年3月13日

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

繼續閱讀全文...