阿碼外傳-阿碼科技非官方中文 Blog: 大規模網頁綁架轉址之水落石出篇

2009年3月12日

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



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

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

9 篇回應 :

匿名 提到...

那個210.65.255.241的推論其實看不太懂,該不會因為兩者匯流於211.22.33.225,所以直接推斷前一個hop,或TTL=6以下的hop必定是問題點吧?

這樣的推論好像太武斷了,因為B支會收到spoofed封包,只代表B支符合被spoofed條件,而非一定是發生在A支與B支不同的子路徑上。

例如,攻擊條件可能是以來源地區作判別條件,或針對機房中數台分流主機的其中一台作arp spoofed,都會有B支被 spoofed但A支沒事的情況。

另,如果不是man-in-the-middle,則應該會收到大量失效的真封包,包含真正的首頁內容,亦即GET / 後會收到兩個頁面,一個為spoofed host回的,一個為real server回的。但是似乎後者的封包量在測試時出現太少了些。

匿名 提到...

Hi! Wayne,

很高興看到國內有你們這樣的專家,全力地追蹤這個事件!對於您追蹤的方法,個人有以下幾點建議:
(1) 是否能公佈您在做 tcptraceroute 時的 tcpdump?
(2) 您最後收到的 FIN 封包內容或過程中有看到轉址封包嗎?
謝謝!!

Wayne Huang 提到...

恩,不是這樣子。推論攻擊在TTL=6或以下,是因為TTL=6時,出現IP spoofing,回來的TCP s/n也對,故判定攻擊點一定在TTL=6或以下的route上,這跟另一個route有被攻擊或沒被攻擊,沒有關係。另一個route只是畫出我們實際上的測試環境--兩條route,一條一直有spoofed封包,一條則沒有。這個測試的方法(原本不想講太明,因為攻擊者很容易破解),是我們修改traceroute程式,變成發出不同TTL的HTTP GET封包,而封包跟IE發出的GET封包長得一樣。因為在TTL=5時,不會收到假封包,但是在TTL=6時會,故判斷有攻擊點位於從我到TTL=6的這段route上。不論另一條有沒有被攻擊,都不會影響我們的判定--攻擊的方式是none-blind IP spoofing,而攻擊程式位於離我TTL=6以下的route上。如果如你所說的,攻擊程式在更上方,而利用來源地區選擇攻擊與否,那麼就不會TTL只等於6時,我們就收到了假封包(s/n正確)--因為TTL只等於6,封包根本不會再往上走。

最後關於您說,「如果不是man-in-the-middle...」這段,簡單回應如下,等等另寫一篇回您好了。如果是像zxarps這種把TCP session hijacking實做得很完整,會改TCP seq/ack,那麼網路上幾乎看不到異常的封包,也不會有現在我們看到的spoofed IP packet。那麼如果不是MITM,就一定會有大量的假封包嗎?不一定,看攻擊程式想如何做。一開始,我們看到只有一個封包,並帶FIN把連線中斷。這樣優點是乾淨俐落,比較不會被監控程式發現,但是缺點是,因為沒有含原內容,故使用者很容易發現。

我們來想一想,根據我們收到的封包,確定:1.攻擊者在route中間(你要說這是MITM也可以),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。

Wayne Huang 提到...

恩,謝謝!
(1) 是否能公佈您在做 tcptraceroute 時的 tcpdump?
可以,請寄信來,我們寄給您:wayne鼠armorize點c-o-m,不想讓這種偵測方法一下子就失效。另外這個traceroute是我們改過的,發的是跟IE一樣的HTTP GET封包。攻擊程式很挑封包。
(2) 您最後收到的 FIN 封包內容或過程中有看到轉址封包嗎?FIN的封包內容就是meta refresh轉址到那個惡意網站,當這個假封包先到時,轉址會成功。您寄信給我我把dump寄給您。

匿名 提到...

Wayne 這邊有可能省略了測試的一些步驟
這邊之所以能確定 TTL=7 的節點下出問題 是因為測試用的 tcptraceroute 上可以設定 TCP payload 的 TTL

簡單的說可以控制這條魚線可以跑多遠
而當 TTL=7 的時候 開始發現有回傳的封包
這代表七個網路節點內有設備作怪
如果不是 ISP 佈署了特殊的設備 就是駭客的程式放在這

更詳細的作法是可以大量的產生這樣的流量定錨
如果駭客是玩骰子決定要不要丟回應的 可以用大量的流量去找出有問題的節點到底是哪一個

匿名 提到...

如果這個結論是由改TTL去測試來判斷的,仍然太武斷。像是L4 Switch, Transparent proxy, 某些 AntiVirus/AntiSPAM gateway, 或某些IDP都是用session hijacking來實作過濾。亦即,只要在TTL=6的地方有這些設備,仍然會將遠端機房的資料抓給你。因此問題點並不是絕對在TTL=6底下。

而以受害端地域分布這麼廣的狀況,以及中華電信的性質,問題點在TTL=6底下的機率,遠比在TTL=6有這類設備的可能性來的低。

當然,這些設備被打進去的可能性也不是沒有,但跟在遠端機房內其他任一機器被打再作ARP spoofing的可能性還比,顯然又低更多。

Wayne Huang 提到...

恩,你講的沒錯,這就是我們用的方法:1. 設定 TCP payload TTL,然後產生定期的流量。謝謝你幫我們說清初,當初本來不想講太清楚,怕之後測不出來了,因為這樣的測試是可以被破解的。

匿名 提到...

回答前一位匿名關於 TTL 的問題

的確有可能會有一些設備去作流量攔截 - 但是在 ISP 的環境內我沒有見過有人擺 Inline 的 AV/AntiSpam Gateway, 在 backbone 擺這樣的設備一則容易造成 single point of failure, 二則沒有幫 ISP 賺錢 (撐 backbone 的設備很貴的) 這種吃力不討好的事中華電信應該不會幹才是

實際上也沒有看 ISP 會在這邊放 inline IPS (理由同上)
Inline IPS 也不應該回 TCP session - 基本上 IPS 檢查封包沒問題後只會放行封包 並不實際攔截這樣的 session

至於是什麼設備攔截封包 是不是駭客攻擊
這邊的人大概都沒辦法存取實體設備 只有中華電信能說明了

-W4y

Wayne Huang 提到...

[TTL] 恩,很謝謝兩位的留言!所以我們整篇沒有提是誰的問題。這邊順便抱歉一點,有人問為何有時說TTL=6有時說TTL=7,因為fyodor那裡tunnel經過我這邊,所以他跟我差1,以後通通以他那裡為基準。我們一直是說 route 中出問題,沒有說 route"r" 出問題。至於 route 中哪裡出問題,route中環境我們沒有資料,故我們只能說,TTL=7以下出問題--這個對我們重要,但是哪一個單位出問題,我們沒有興趣研究,整篇 blog也從未提及哪個單位出問題。況且我們也都只是某家ISP用戶,其他家我們也沒錄過,怎能說是誰的問題?。至於TTL=7範圍有多大,我們不清楚,所以我們沒有說「幾個node以下」或甚至「幾個hop以下」,避免混淆,而是說「TTL=7以下」,故並沒有錯(經過某些設備TTL不會減少的話,那都算TTL=7以下)。

雖然誰出問題我們沒有興趣,但是TTL=7對我們的研究來說是有意義的,因為這表示不論server farm是否同時也有問題,至少在路徑中就已經有攻擊程式。這資訊對我們研究究竟是何種攻擊也很有用。而錄到的封包對我們也很有意義,因為這表示,不是DNS的問題,也不是ARP掛馬(至少錄到的部分不是),而確定有none-blind IP spoofing。

最後,真的很感謝大家的留言,但我們別一直討論是哪家的問題了,wayne與fyodor剛好都是某家的用戶,所以只有錄了這家的流量,這樣對他們不公平...我們多focus在技術方面就好 :)

張貼留言