）
從三月初開始，網路上陸續有消息，連往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
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
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。
恩，不是這樣子的，剛好相反，如果攻擊程式在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，但是也可能沒有。這些都需要一些文章解釋，我另外寫一篇跟你回答好了。
張貼留言