阿碼外傳-阿碼科技非官方中文 Blog: 大規模網頁綁架轉址:威脅未解除,但專家都猜錯了

2009年3月8日

大規模網頁綁架轉址:威脅未解除,但專家都猜錯了

(續集見:「大規模網頁綁架轉址之水落石出篇」


從三月初開始,網路上陸續有消息,連往tw.msn.com、taiwan.cnet.com等網站時,會被自動轉址到www.dachengkeji.com。一開始心裡想,大概又有誰的DNS沒有上patch吧,要不然就是又有DNS 0-day或又有人玩BGP了。過了幾天,威脅還是沒有解除,媒體也都紛紛報導了:

神秘網頁轉址事件 疑為新型態攻擊手法,ZDNet 2009/03/05
DNS遭攻陷,多家知名網站慘被攔截轉址,網路資訊 2009/03/05
[教學]遭遇不明網路劫持該如何自救?網路資訊 2009/03/07
追蹤:轉址攻擊仍持續且惡意碼手法日趨成熟,網路資訊 2009/03/08
微軟MSN首頁遭轉址 疑上層DNS被入侵,IThome 2009/03/06

恩,這麼多的專家都說是DNS被綁架了,跟我的直覺一樣...我那時這麼想。

三月七日中午,我用一台電腦上網,剛好這台的IE首頁沒有改,設的是MSN,結果一開就真的被綁架到dachengkeji了。這個dachengkeji.com,真是厲害,我心裡想,過了這麼多天,威脅都還沒解除。就在這個時候,o0o.nu的fyodor yarochkin(聯絡方式:fygrave 鼠 o0o 點 nu)從MSN上傳訊息來,跟我說最近號稱「DNS綁架」造成網頁轉址的事件,根本跟DNS無關,引起了我的好奇,於是我用WireShark看了一下封包,赫然發現這絕對不是一般的DNS綁架,駭客所有的手法犀利,影響的範圍應該非常大!我在這邊將fyodor與我的研究與各位分享,希望各位如果有想法,也可以讓我們知道。

這一個攻擊利用了兩個技巧:

(1) None-blind spoofing,而這也表示攻擊程式位於從受害者到受害網站之間的路徑上,可以監聽流量。

(2) 有些 TCP/IP stack 在實做上的缺失(bug),目前測試結果微軟的系統有此缺失,但是預計還有其他作業系統會有此缺失。

我用我借WireShark錄下來的封包來解釋這個攻擊手法,當時我正試圖連往http://www.gogrok.com(因為網友說這個網站也會被鎖定轉址)。我當時的IP是192.168.1.129,而gogrok的是202.157.128.202。
以下我們看frame 15--我的機器對gorok送SYN。




Frame 16中,對方送SYN/ACK,注意對方的TTL是56。



Frame 17,我送ACK,three way handshake完成,連線成功。Frame 18,我送http request,request(get)不會特別長,所以都在一個封包裡。注意TCP s/n=752:



Frame 19,對方回應,s/n是對的(752),可是id=0x0100,太巧了吧?TTL也突然變成=115。重點是這個封包設了FIN,另外http response內容--meta refresh轉向。FIN表示對方要中斷連線,而meta refresh則會導致我的瀏覽器轉向到www.zhonglie.org。這個這個封包其實沒有符合RFC 793:SYN/FIN封包不能帶其他payload;所有的payload應該在three way handshake完,FIN之前交換。



Frame 20-21,我方確定中斷連線。Frame 23是正牌網站送來的ACK,s/n是對的(752),TTL也是56,id=0x2087不是0x0100。但是比較晚到,我機器已經認為此連線中斷了,瀏覽器也被轉向了。



這個攻擊的特色是,第一,有正確的s/n號碼,表示攻擊程式位於route上,可以看到封包。第二,利用了有些作業系統(例如微軟)在TCP/IP stack實做上的缺失,使得整個攻擊,一個封包就搞定,乾淨俐落。

很多網友都有在網路上討論:
「連tw.msn.com就被導向http://www.dachengkeji.com/article/index.htm」
「連MSN首頁會轉址到www.dachengkeji.com/article/index.htm」
「進入 iThome Blog網址自動跳轉廣告網址」
「[求助] 連tw.msn.com就被導向http://www.dachengkeji.com/article/index.htm 」
「有辦法檢查本站是否 DNS 有被駭嗎?」(此網域本身被鎖定,點選要小心!)
「tw.msn.com被攻陷了嗎?」
「胡亂轉址」
「封鎖惱人的"www.dachengkeji.com"大乘科技」
「網站新聞 : 關於tw.msn.com被導向到dachengkeji網站的反應已經漫延到我們客戶了」
「[重要]連MSN首頁會轉址到www.dachengkeji.com/article/index.htm」
「[求教] 台服官方网站是不是被别人内链了,看图说话」
「電腦警報:非中毒的網頁自動轉址(3/10更新)」
「連tw.msn.com就被導向http://www.dachengkeji.com/article/index.htm」
網頁劫持

這些討論與報導,但部分訪問專家說的,都不正確。這次的攻擊跟DNS沒有任何關係。另外,目前為止,威脅並沒有結束或降低!三月七日兩點到三點,我用那時的電腦做了些測試,發現每一次我連tw.msn.com都被轉向。但是下午約四點開始,突然不轉向了,我想大概威脅解除了,被感染的路由器修好了。可是三月八日中午,我發現威脅依然存在,但是對於每一個被鎖定轉向的網址,都只轉一次!也就是說,假設你在家裡,那麼只有在你第一次連往被鎖定之網站時,會被轉址,第二次就完全不會了。這是為何我錄的是gogrok.com而非tw.msn.com,因為轉了一次以後就不轉了。我試了很多被鎖定的網址,都是一樣,只有第一次會轉。

網路上判斷比較接近我們的,有Blue在資安之眼所貼的「關於這兩天的轉址攻擊事件」,還有richliu所blog的「某些 ISP 疑似被 hijacking攻擊」。另外,在mobile01上,powerpcer有貼出他的pcap dump,我們看過手法跟我們錄的是一樣的。

Cisco也在三月六號貼出了alert:
CISCO:TCP Traffic on Chinese Networks Redirected to Malicious Websites

我們在這邊整理整個事件相關資料,如果有網友有可以補充的,歡迎留言或email(wayne鼠armorize點com)提供我們!

[攻擊技巧]
(1) None-blind spoofing,而這也表示攻擊程式位於從受害者到受害網站之間的路徑上,可以監聽流量。
(2) 有些 TCP/IP stack 在實做上的缺失(bug),目前測試結果微軟的系統有此缺失,但是預計還有其他作業系統會有此缺失。

[攻擊特色]
(1) 攻擊程式位於route中,很可能在backbone上,故影響範圍廣大。
(2) 一個封包就可以攔截session。
(3) 改版後,一個網址只會轉址一次,造成追蹤困難。
(4) 手法並非目前很多專家說的「DNS感染」。

[遭鎖定轉址的網域]
根據網友的回報,目前已知遭鎖定轉址的網域有:
tw.msn.com (我們自己有測試成功)
www.msn.com.tw
www.gogrok.com (我們自己有測試成功)
taiwan.cnet.com (我們自己有測試成功)
www.orzteam.com
www.92an.com
www.wowtaiwan.com.tw
www.ioage.com
www.ithome.com.tw

[轉址到的網域]
轉址到的網域有:
www.dachengkeji.com
www.zhonglie.org
www.yyge.com
www.ganji.com

[pcap封包下載]
我們有msn.com、cnet.com以及gogrok等三份被spoof時錄下來的封包,可以聯絡我們索取(wayne鼠armorize點com)。

[如何防護]
由於為路徑中有節點遭控制,使用者不容易自保,建議利用https而非http連結網站(如果網站有提供https的話)。如果擔心機器已經因為被轉向而遭受攻擊,被植入惡意程式,可以來信索取阿碼科技的免費Archon Scanner:info鼠armorize點com。

[資安廠商alert]
CISCO:TCP Traffic on Chinese Networks Redirected to Malicious Websites

[相關新聞]
1. 神秘網頁轉址事件 疑為新型態攻擊手法,ZDNet 2009/03/05
2. DNS遭攻陷,多家知名網站慘被攔截轉址,網路資訊 2009/03/05
[教學]遭遇不明網路劫持該如何自救?網路資訊 2009/03/07
追蹤:轉址攻擊仍持續且惡意碼手法日趨成熟,網路資訊 2009/03/08
微軟MSN首頁遭轉址 疑上層DNS被入侵,IThome 2009/03/06

[相關網路討論]
「連tw.msn.com就被導向http://www.dachengkeji.com/article/index.htm」
「連MSN首頁會轉址到www.dachengkeji.com/article/index.htm」
「進入 iThome Blog網址自動跳轉廣告網址」
「[求助] 連tw.msn.com就被導向http://www.dachengkeji.com/article/index.htm 」
「有辦法檢查本站是否 DNS 有被駭嗎?」(此網域本身被鎖定,點選要小心!)
「tw.msn.com被攻陷了嗎?」
「胡亂轉址」
「封鎖惱人的"www.dachengkeji.com"大乘科技」
「網站新聞 : 關於tw.msn.com被導向到dachengkeji網站的反應已經漫延到我們客戶了」
「[重要]連MSN首頁會轉址到www.dachengkeji.com/article/index.htm」
「[求教] 台服官方网站是不是被别人内链了,看图说话」
「電腦警報:非中毒的網頁自動轉址(3/10更新)」
「連tw.msn.com就被導向http://www.dachengkeji.com/article/index.htm」
網頁劫持

作者 Wayne 為 阿碼科技CEO
作者 Fyodor Yarochkin 為 o0o.nu 成員

下一篇系列文章:
2009/03/12 「大規模網頁綁架轉址之水落石出篇

相關系列文章:
2009/03/08 「大規模網頁綁架轉址:威脅未解除,但專家都猜錯了
2009/03/12 「大規模網頁綁架轉址之水落石出篇
2009/03/13 「回答IP Spoofing 的問題
2009/03/15 「從大規模轉址事件看IP spoofing、ARP spoofing、ARP掛馬與路徑(route)安全
2009/03/27 「網路藍色藥丸?首支攻擊路由器之蠕蟲出現:再談路徑之安全性

7 篇回應 :

匿名 提到...

去年 2007/06 左右,就已經有遇到過類似的狀況。

當時是在一個系所 lan 的環境內,機器混雜插在 switch/hub 上面,外面的人用 http 連到 lan 裡面的 web server,傳回的內容在最下面就會被插了 iframe 掛馬,當時徹底檢查這台 freebsd 是不是被破進來,結果沒有任何發現,交叉測試其他的 server,發現只要是用 http 聯道 lan 裡面的任何網頁,會有不一定的機率出現 iframe 掛馬,而這些機器後來也確認過沒被破台,簡單避開的方法就是不要用 port 80 就不會莫名其妙出現 iframe,最後是學弟們用拔線法一台台追出有毛病的 windows 機器,當時也掃不出是什麼髒東西在裡面,全部砍掉重練,花了將近半個月才清乾淨。

過沒多久某野狗大學某宿舍宿網也發生類似的情況,因為機器太多(超過四百台)徹查困難,後來也是千辛萬苦用拔線法踹出有問題的機器才恢復正常,而這大概花了至少兩個月。

看到這次的狀況,我在猜是不是骨幹上有 windows 機器中到類似的標了....

匿名 提到...

看看這種案例吧! 不要把事情想得太複雜了!
http://wiselysong.blogspot.com/2008/12/msn-shell-serverarp.html

Wayne Huang 提到...

No,這次攻擊事件是否有伴隨ARP掛馬攻擊,我們不清楚,但是單就我們錄到的攻擊,以及我們以上公開的手法來看,跟ARP spoofing或ARP掛馬沒有任何關係,這是標準的IP spoofing。雖然spoofing手法大概都大同小異,但是ARP是在layer 2而IP在layer 3,故以上公布手法稱做"IP spoofing"而非"ARP spoofing"或"ARP掛馬"。另外由於原封包並未遭到竄改,稱"main-in-the-middle"也並不合適。這是最典型的IP spoofing。

匿名 提到...

是 "Man-In-The-Middle" 而非 "Main-In-The-Middle" 吧....

另外 MITM 攻擊並不一定是竄改封包而已吧?
第三者偽裝成 Server 來發送也是 MITM Attack。

詳見:http://en.wikipedia.org/wiki/Man-in-the-middle_attack

Wayne Huang 提到...

1. 是的,打太快,謝謝!2. 恩,看怎麼定義了,是也可以說成是"MITM"。但是我們的意思是,這一看就是典型的 IP spoofing,可是我看了很多報導都沒直接說是 IP spoofing,蠻怪的。有人說是上層DNS,有人說是ARP掛馬(說成"MITM"會模擬兩可,因為ARP掛馬就是標準MITM,所以我自己覺得這樣說比較模糊),但是就我們公布的這些封包來看,直接可以斷定,用到了IP spoofing。至於是否伴隨DNS攻擊或ARP掛馬,目前沒有直接證據,所以我們不會斷言有。

另外"通常"講MITM時,都是攻擊程式可以充分控制來回的資料時(ARP掛馬就是)。但是在這個case,不確定是否這樣,因為原伺服器的回復封包並沒有被拿掉。有可能是故意不拿,也有可能是拿不掉。沒有證據。這也是為何我們說「攻擊程式位於route上」而沒說「route"r"上」,差一個字母差很多。

最後,不論是IP spoofing or ARP spoofing,都是90年代就常用的攻擊了(年紀真大啊)...

匿名 提到...

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。

Wayne Huang 提到...

恩,不是這樣子的,剛好相反,如果攻擊程式在route中間,我們在end端只能看到IP spoofing而看不到arp 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,但是也可能沒有。這些都需要一些文章解釋,我另外寫一篇跟你回答好了。

張貼留言