2009年3月12日 星期四

網站轉址攻擊-ARP掛馬

從上一篇「網站轉址攻擊事件」發文後,有朋友來信問我,為何能確信是「ARP掛馬」,而不是「IP-Spoofing」。

事實上,此攻擊事件不論是「ARP掛馬」或是「Non-Blind Spoofing」,都能得到類似網站轉址的效果。

看來這回的攻擊事件,爭議點只剩下究竟是「ARP掛馬」還是水落石出的「Non-Blind Spoofing」。


我曾看了 Fyodor Y. 的留言以及他的看法,也和他交換了意見,對於他的技術能力,我毫無懷疑,甚至我覺得他寫的「Non-Blind Spoofing」模擬攻擊程式寫得很好,很值得研究參考。

那為何我不選擇相信是「Non-Blind Spoofing」,難道我有作什麼實驗,或是整天在網路上抓封包測試嗎。我的依據是什麼呢?

這篇,我就來說明一下這兩個攻擊的可能性,以及我的質疑和判斷。

「Non-Blind Spoofing」這個攻擊,事實上是需要封包監聽以及插入封包,並且搶在真正的回應封包前,傳送惡意封包回 Client 端。

那要在那個網路節點上封包監聽作這樣的攻擊呢?任何一點都有可能。
但問題是,有可能監聽到嗎?二話不說,馬上實驗,各位就立刻執行 Wireshark 看看,來監聽看看你老闆的 MSN 吧!若是你聽到了你老闆的的談話,你就選擇相信「Non-Blind Spoofing」,一點問題都沒有。

另外有一種可能。這也是水落石出的可能了:

「某個網路節點的 Router 被入侵,並且改了設定」

這是要逼 ISP 啞巴吃黃蓮嗎?

Router 被入侵的可能性當然是有,然而中華電信 ISP 天天在檢查,完全沒有發現異常的情況。

再說,改了設定是要把封包 Mirror 到那裡? 中華電信機房該 Router 旁的主機嗎?
那來的這台「Router 旁的主機」?中華電信機房可以隨便放機器就是了?
那設定封包 Mirror 到較遠的主機呢?那你怎麼搶送封包回 Client 端?
而且能不能照原路由傳送回假封包都是問題!!
以上問題若不能回答出來,就請別再誤導各位網友了好嗎?

好,那另外一種「ARP掛馬」攻擊的可能性呢?

我在上一篇文章有提到,國內之前早有人揭漏了「ARP掛馬」攻擊。而最近的國外安全研究機構 SANS 的討論,大家可以看一下 Massive ARP spoofing attacks on web sites
這篇。

另外,遠在 2007 年的一篇技術報告 "Studying Malicious Websites and the Underground Economy on the Chinese Web" 中提到「ARP 掛馬」攻擊大陸的 "Norton China" 網站,我擷圖如下,覺得不清楚或想看整篇文章的朋友可以自行閱讀。


此外,這一兩年大陸駭客在各駭客論壇或駭客雜誌裡,早已把「ARP 掛馬」講到爛了,有興趣的朋友,可 Google 「ARP 掛馬」或「ARP-Spoofing」,有一堆的事件資料可參考。
這說明了什麼呢?這說明,利用「ARP-Spoofing」作攻擊是最可行的方式!

也許有人質疑,這回攻擊所側錄的封包和使用「ARP掛馬」攻擊的封包有些差異。但是,就憑網路封包 ID/TTL 的不同,就說和「ARP掛馬」無關,這樣的否定會不會太粗糙了?

要修改封包回應或插入不同的封包內容,這對程式能力高的駭客來說,這是幾分鐘就可以改的,要亂數處理也行,愛怎麼變就怎麼變,唯一不變的是,要達成這樣的攻擊,「ARP Spoofing」是最容易,也最現成,更是大陸駭客流行許多的手法,而且,重要的是

「不會有駭客這麼閒,整天在看部落格後一直改攻擊程式的」


所以,從以上我的觀點,所得到的結論如下:

1. 會作 ARP-Spoofing 掛馬攻擊的原因,絕大部份是因為該網站的防護很強,無法攻破後直接掛馬,所以只好作 「ARP 掛馬」。
2. Sniff 不同網站的封包流量當然有可能得到不同的攻擊方式,而且不用預測下一波,因為「ARP 掛馬」不斷發生,總是會有新聞可以炒作。這點資安專家們可以安心。
3. 和基礎架構和設備無關,這類的攻擊在世界各地都可能常發生。

最後我要說的是:
指控中華電信 ISP 的路由器有異常,是非常嚴重的事,也關係著商譽問題。一般說來,資安專家或廠商發現了異常或漏洞,都會有道德的與出問題的一方作好溝通,釐清真正問題點,再選擇適當時機公佈詳細資訊(Full−disclosure)。

但是,若證據都不足的情況下,貿然的指控,只是會令人懷疑背後的動機。

身為資安廠商,除了技術能力和新聞議題外,更重要的是道德,不是嗎?

14 則留言:

Fyodor Y 提到...

Hey Tim :)
其實我們也沒有說過他們不是用ARP spoofing來intercept哪些packet. 都有可能, 也有可能是router被crack, 也有可能是跟router同意個segment的windows machine被crack. 這個不是其實一個重點. 重點是他們(bad guys)有辦法在哪些7個hop內"聽"我們的TCP session.

HOW: 這個問題, 如果中華電信不給我們跟系的資料, 很難說. 他們說'都是hardware", 那就是router紴控制. 如果有ethernet segment, 也可以用arp來做interception.

不過如果你用arp做interception, 你可以完全控制tcp connection. 我們這邊不會看到spoofed packet 跟 real packet一起出現.
有可能他們欄的做full tcp connection hijacking, 所以決定用spoofing送packet, 然後其他的traffic直接給那個機器處理.
其實我玩過那個zxarps. 哪個tool很強, 她正個tcp session都可以handle. 如果他們會用那種方式來打, 這個問題就會跟難解決..


關於timing:按照我們的預算從interception point到spoofed的機器好要50ms..

關於道德: 我們沒有在disclose漏洞. 而且我們早已天跟中華電信聯絡過, 但是他們都說"沒有問題". 這種situation你覺得應該要怎麼handle?

Security也是一個服務品質的部分. 如果品質不夠好, 我認為我們有權力要求. 不是這樣的嗎?

匿名 提到...

不需要 bad guy,如果TTL=7時有個Transparent IDP或Transparent proxy,仍會幫忙轉送封包,讓遠端機房裏的spoofer收到並送回封包。

匿名 提到...

借這個網頁笑一下某公司,因為該公司非官方總裁不敢面對現實開放這種留言。

當初某公司公然私下明裏暗裏都去把問題怪到中華電信(剛好證據還留在這裏),也誘導網友是中華電信的錯(你們來看TTL=7裏都是中華電信得喔)。結果事實證明不是中華電信的問題,某公司也不見有個正式道歉,只會開始推說「沒有明指」是中華電信,會誤會是網友自己的錯。

某公司又信誓旦旦說是路徑問題,事實證明是國外機房裏被掛馬,再來扯說「早就排除是路由器遭入侵」或「國外機房也包含在TTL=7裏」(這個「早就」是多早?)硬凹就算了,沒事還要在文中酸酸同業。

當然我想,為了賺錢臉皮厚一點,也是無可厚非的啦,這個行事風格在業界裏大家已經知道很久,只是第一次爆到讓業界外都看到而已。

匿名 提到...

To 樓上:
路過看到,這次外界大部分認為是Tim講不對吧。這家公司blog講得很清楚,TTL=7內出問題,後來也實際示範了有可能出問題的地方。我認為你沒看懂他們的文章,他們從來沒說TTL=7是發生國外機房,他們應該是堅持不是發生在Web機房而是發生在路徑中間。這個很合理,我個人認為比ARP掛馬合理。再說,Tim講路由器不可能被感染等等,外面我們看到是覺得不對。路徑上有很多設備,cache,L7 switch,都有可能,雖然TTL=7可能不在國內,但是根據他們公佈的traceroute比對,不可能在Web機房裡。如果中間有如二樓說的設備會在TTL=7時直接送到Web機房,那traceroute就會是如他們圖中那樣,但是tw.msn.com並沒有這樣,所以他們說發生在路徑中,我個人認為極有可能。二樓講的事,就是指他們blog中說的,但是也就如他們說的,tw.msn.com的traceroute長得不一樣,所以應該沒有這種設備,也就是說,TTL=7到不了遠端機房。

無論如何,我一直感覺對方就事論事,都有具體的資料,但是這邊說認為是IDC而非ISP,卻沒有給資料。ARP掛馬雖然多,但是也不能這樣就咬定是IDC。一樓那位不是他們公司的人。

匿名 提到...

以下可以參考:

「事實上,根據某Cisco路由器專家的檢測後發現,此次攻擊發動的源頭,應該是路由器在mirror port上的網路裝置如IPS等Layer 4設備遭到入侵所致。由於高階Layer 4設備本來就具備解析、插入、重組封包的能力,因此能夠輕易實現本次網頁轉址攻擊中,在正常封包前插入轉址指令的特徵。

為求驗證,某位不具名安全專家特地架設實驗室環境,以路由器+IPS成功重現相同的網頁轉址攻擊。 」

http://enjoefox.spaces.live.com/blog/cns!8D7A9337740E192C!14691.entry

匿名 提到...

樓上,你可能要看仔細點,這家公司blog最後已經漏風說出問題點其實在國外。我也可以跟你說,是某個L4以上的設備沒錯,但不是IDS/IPS。某資安專家用「路由器+IPS」測試,和某公司Blog最後寫一大篇老掉牙的路由器攻擊的Demo一樣,都在轉移焦點,跟這次事件完全無關。

要不要猜猜這個神秘的L4設備在哪裏?

如果你知道什麼是Mirror Port,什麼是高階L4設備,然後再想想這個接在Mirror Port上的高階L4設備,要用什麼手法才能「解析、插入、重組封包」。

該公司問題不在技術人員,而是技術沒錯,結論出錯,這是老闆過於好大喜功,三分料要講七份話,總是先想要怎麼利用技術人員的研究結果來炒新聞,預設結果再求解釋,才造成的現象。

匿名 提到...

樓上仁兄,我仔細看過那幾篇,上面我覺得寫得都很中肯,光就技術來說,作者實力很夠,我看不出哪裡寫不對的。路由器這些攻擊很老,文章中也一直有強調。我自己當初看這個事情的時候的想法是,滿多種可能的,但是看兩邊的文章,那邊分析比較多,有實際數據也有解釋為何不是ARP,我覺得分析得不錯。我覺得三樓明顯沒看懂文章,不是TTL=7一定到不了Web,當然也是有可能,譬如cacheflow那一篇就是一個例子,但是比對他們公佈的tw.msn.com traceroute,中間看不出有類似設備,因此我覺得路徑中發生機率比較高,非路徑末端。

如果樓上也說是L4出問題,那是否確定是在路徑中而非Web端?如果是這樣,那麼他們強調在路徑中非Web端就沒有錯。我也是認為機率比較高。另外,如果是L4出問題,那還跟ARP掛馬有關嗎?

Router如果被mirror port,攻擊點在哪裡都無所謂,要達到這種攻擊很容易。如果是可以收到mirror traffic的L4設備,就要看是哪種設備,跑什麼系統。因為我以前某工作關係,我常接網路設備,對於各種mirroring還算蠻熟的。

四樓的 "路由器+IPS成功重現" 我倒是也不知道是什麼方式。

我也倒不覺得對方老闆有什麼好大喜功,我重頭讀一遍,沒找出什麼錯,前幾篇中也沒說一定是hinet或者一定在國內。我感覺分析得蠻好的。那一篇cacheflow我覺得只是點出路徑中間當然有可能有東西出問題,但是也講明了這是很老(好像是講"古早")的攻擊以及當初他們研究完就覺得與轉址事件無關,只是貼出來分享。我也覺得他們的結論沒有錯,他們基本上就是說,發生在TTL=7以下,不在Web server 那邊。依據他們給的資料,我看不出錯在哪裡。

我感覺圈內缺少這種有提出事實,分析資料,以及有技術性的文章分享。另外其實我覺得他們老闆本身實力很夠。這邊四樓說 "事實證明是國外機房裏被掛馬",樓上說 "是某個L4以上的設備沒錯",這兩種說法就差很多。樓上的說法與對方,只差在這個L4設備在國內還是國外,但是我感覺這不是對方的重點,從看幾次文章也找不出他們何時有說一定在國內。但是如果是樓上說的,L4設備,是否就排除了 "ARP掛馬" 與 "發生在web server"可能?那麼四樓說的就不成立了。

匿名 提到...

樓上的發文跟某公司某 CEO 風格頗像,滿有意思的 ;)

匿名 提到...

大家 不知有沒有注意到, 其實一樓的那位是一直偏向發生點在國內的, [那個CEO]blog上沒有這麼說...另外我覺得... 那邊寫技術很多, 看不出有什麼破綻... :P

匿名 提到...

哈哈哈,這兒真有意思,樓上太看得起我了,不是每個不認同你們的人都是那家公司的;)

匿名 提到...

你該不會從頭到尾都搞錯,以為「ARP掛馬」就是指「佔領網站主機本身」吧。

「ARP掛馬」指的是在IDC機房內,網站旁邊有台機器出事了...

匿名 提到...

感覺大家講的應該對arp掛馬定義都很清楚吧
但是這次感覺不像,因為如果中間有box讓封包走捷徑,或cache,那麼tcptrace[port 80]看起來會像:
1-2-3-4-5-6-7-open
類似那個cache-flow就是長那樣
可是他那邊公開的轉址時的tcptrace[80]是
1-2-3-4-5-6-7-8-9-a-b-c-d-e...
如果在這種情況下ttl=7就收到spoofing封包,那不像是web server周邊被arp spoofing
另外如果是網路設備被入侵,如果是跑embedded linux,那可能直接在上面sniff然後做spoofing,如果不是,那可能被mirror封包到其他box,再由這個box發出spoofing
以上這些情況都比較會用簡單的ip spoofing...
如果能arp掛馬(IDC機房內,網站旁邊的機器),應該會直接竄改封包然後才轉送,不會用ip spoofing

匿名 提到...

某公司非官方總裁實在是太有意思了, 在自己的非官方 blog 信誓旦旦寫說攻擊發生在 TTL < 7 的範圍內, 但接受別人訪問時又說攻擊是從新加坡的一台 switch 發動的, 真不知道這是在自打嘴巴還是騙台灣人看不懂英文?訪問內容在此.

匿名 提到...

"然而中華電信 ISP 天天在檢查,完全沒有發現異常的情況" 這blog夠狗腿了...第一次看到有"資安專家"願意這樣狗腿xnet...