從3月2日上午開始,多家知名網站如C|NET Taiwan與ZDNET Taiwan、臺灣MSN(tw.msn.com)等,一進入其網站首頁或網站中的不特定連結,均會被攔截轉址到某特定位於中國大陸主機的網頁。
根據部分使用者表示,透過IE或Firefox瀏覽器開啟特定網站時,原先正常的網頁被轉址到http://www.dachengkeji.com/artical/index.htm網頁(疑有惡意程式碼,請勿隨意開啟),該網頁內容編碼為簡體中文GB碼。
截至3月4日下班前,該問題網頁尚無加入任何惡意程式碼,但隨即在3月4日晚間7點多,該網頁追加一個跳出式網頁訊息,證明該網頁正在演化中,有可能會隨時增加惡意程式碼。果不其然,至3月5日凌晨,該問題網頁開始加入惡意程式碼,正式成為惡意網頁,開始在特定區域肆虐。
案情並不單純
![]() |
| 此為攔截轉址的目的網頁,內有不雅文字,請斟酌開啟。 |
由於遭到綁架轉址的網站均為國內知名網站,因此一時間引起許多使用者的恐慌,以為自己的電腦遭到入侵或是綁架。然而該現象遍及多家網站與多位使用者,顯然並非單一網站遭到入侵或攔截。據國內多位安全專家表示,可能是ISP的DNS伺服器遭到入侵綁架,不定時回報錯誤的IP位址給查詢DNS的使用者。事實上,2007年9月6日,微軟MSN臺灣地區首頁也傳出因微軟DNS設定錯誤而遭到轉址的事件,由於僅僅是技術上的瑕疵,微軟也立即修復該錯誤,因此未傳出災情。
然而,根據編輯部進一步測試,若直接輸入zdnet.com.tw的IP位址(202.176.217.17),不經過DNS查詢,仍然發生連線遭到攔截被轉址到無關的中國網頁去。
另一方面,該網頁轉址攻擊行為並不固定攻擊某些特定網址,而是針對不特定使用者,特定網站不定時發生轉址的現象,使得追蹤查緝的行動更為困難。
初步判斷應為零時差攻擊
趨勢科技資深技術總監戴燊表示,原則上無法防禦DNS綁架攻擊,因為問題點並非出自於用戶端的電腦或系統,而是受到更上層遭到污染的DNS影響所致。但為何該轉址行為會不定時出現,目前尚無定論。某位不願具名的資訊安全專家推估,可能是因為網路骨幹的DNS服務是由多臺DNS伺服器同時運作,某臺DNS伺服器遭到入侵綁架,因此只有當使用者發出DNS查詢要求時,輪詢到該臺被污染的DNS伺服器才會出現轉址現象。
使用者如何自救?
目前為止,根據各論壇網站的討論,傳出災情使用者多數使用HiNET的網際網路服務,但也有少數使用者回報使用3.5G上網也會發生網址綁架,初步判斷使用臺灣的公用DNS主機容易遭到攻擊,使用者可以先將網路連線設定中的DNS位址,改為美國DNS主機如OpenDNS所提供的服務位址(208.67.222.222與208.67.220.220)。企業用戶可先將自家DNS主機的上層DNS位址改為OpenDNS所提供的DNS服務位址。根據本刊編輯部測試,的確不再發生網址綁架的現象。
根據Whois反查網域的資料,可得知該網域登記代表人為xinfazhang,登記在中國河南省,並登記一組中國大陸地區電話號碼,但根據編輯部試撥的結果是空號,顯然該Whois所登記的資料為假資料,但無法證明dachengkeji.com為此次攻擊事件的發起者。
截至目前為止,尚無ISP或其他資訊安全廠商針對該轉址事件的正式說明,據瞭解相關單位已經開始追查攻擊來源與遭污染的DNS主機,若有進一步消息,本刊將繼續追蹤報導。
TCP Hijacking 跟DNS spoofing 不一樣啦
@Keith Lin:
說得是,不過該如何能夠同時對zdnet與msn taiwan同時進行tcp hijacking呢?
現在針對這種新型態攻擊,目前都還在猜測手法的階段。
有沒有人能夠提供可能的手法?
這樣「不特定」的特性,實在很難讓人確切掌握住該攻擊是否已經修復完畢了。
請各位若仍然碰到類似的轉址案件,能到此留下個記錄,協助繼續追蹤這種攻擊手法是否還在蔓延中。
回報:我是連到以下網址就會被轉向
http://merlystreep.5d6d.com/
現在是3月6日上午1:00整,小弟人在大陸,目前只有上pchome網頁會導向http://www.dachengkeji.cn/index.htm
感覺上被轉址的次數有減緩
但仍會不定時被轉址到以下兩個網址
h ttp://www.zhonglie.org/
及h ttp://www.dachengkeji.cn/index.htm
今天连到www.chinatimes.com, 仍然被转址到http://www.dachengkeji.com/artical/index.htm,中时电子报开着等他Refresh时,有时就会被转址过去。
從 DNS Poisioning 、TCP Hijacking、到 Server (malicious script inject) 都有人提
可是怎麼沒人提到 Click Jacking ?
這些網站都有刊廣告,是否有可能是這些廣告出了問題?!
[...] 網路資訊雜誌 老共的企圖心, 不容低估! 小心使用網路! __________________ [...]
感謝大家熱情回報,請大家回報的時候,別忘記附上所使用的ISP是哪一家的資料哦,這樣比較容易統計比較。
感謝大家。
唔~使用的是中華電信光世代10M/2M
目前還是一樣會不定時被轉址到下面兩個網址
h ttp://www.zhonglie.org/
及h ttp://www.dachengkeji.cn/index.htm
[資訊更新]
仔細看了封包, hijacking比較有可能,至於是那邊被 hijack了?
是否可以請各位提供 traceroute 的資訊?看看是否有交集.
有人錄到來自不同ISP的轉址攻擊封包嗎?目前似乎有人錄到來自新加坡電信的轉址攻擊封包。
看來快要追到出問題的那個點了。
目前連到http://www.gogrok.com也是會被轉到12樓所講的
就算用ip address去連也會
使用網路是中華電信的固定IP
nslookup這個domain name是正確的
好像只是http才會有這問題,用putty或psftp去連就不會被轉
如果把DNS改設到其他國家去,就不會有這狀況
哦?這就很有趣了,gogrok.com的位址也在新加坡。
不過我reload gogrok.com好幾次,還沒碰到轉址現象。
vw.com.tw也被綁架了,這個網址是新加坡所註冊。
世界之窗瀏覽器: http://www.ioage.com,同樣被轉址,此外經過交叉測試,以下整理:
****
環境
****
ISP:Hinet FTTB、DNS:168.95.192.1—–>平台:windows(會被轉址)(Firefox、IE7)。—–>平台:Linux(不會被轉址)(Firefox)。
****
環境
****
ISP:學校學術網路、DNS:168.95.192.1—–>平台:windows(不會被轉址)(Firefox、IE7)
結論:以上經過不同區域朋友同步測試,似乎只對使用中華電信光纖網路的
Windows平台有效(會被轉址),用Linux的朋友並不受此影響。
希望以上資訊有助於趕緊破解此謎題!!謝謝
[...] 週四(3/5)報導的網站轉址事件,截至目前為止,各地仍然有災情傳出。根據多方追查的結果,初步排除此案單純為DNS冒用的可能性,極有可能屬於TCP Hijacking的攻擊方法。若果真屬實,儘管目前僅影響到特定網站,但若不徹底解決,那麼該攻擊行動有相當大的潛力足以綁架不計其數的網站。 [...]
[...] 網路資訊雜誌 http://news.networkmagazine.com.tw/secrutiy/2009/03/05/11128/ [...]
dns:208.67.222.222/168.95.192.1
在海南开tw.yahoo.com也会被转到哪里,我还以为中毒了,一直扫
[...] 自3月2日開始發生的不明網站轉址攻擊影響臺灣ZDNET、CNET與MSN以來,各方安全專家無不開始追查問題的根源與來由。先前本刊報導該轉址攻擊起因於DNS遭到攻陷,目前已初步排除此可能性。根據轉址網頁封包分析,惡意轉址指令乃是搶在正常網頁回應之前,便在HTTP Header中安插一段轉址指令。換句話說,在遠端正常的Web伺服器傳回HTTP協定封包資料之前,使用者端便GET到轉址要求,即便輸入IP直接連線,也遭遇到同樣的轉址要求,很可能是遭受到TCP劫持攻擊或是中間人攻擊(Man-in-the-middle attack)。 [...]
[...] 1. 神秘網頁轉址事件 疑為新型態攻擊手法,ZDNet 2009/03/05 2. DNS遭攻陷,多家知名網站慘被攔截轉址,網路資訊 2009/03/05 [教學]遭遇不明網路劫持該如何自救?網路資訊 2009/03/07 [...]
我看過阿碼這篇文章,不過似乎還稱不上真相大白。
還沒辦法解釋攻擊起源與真正的作為。
[...] 疑為新型態攻擊手法,ZDNet 2009/03/05 DNS遭攻陷,多家知名網站慘被攔截轉址,網路資訊 2009/03/05 [教學]遭遇不明網路劫持該如何自救?網路資訊 2009/03/07 [...]
[...] 疑為新型態攻擊手法,ZDNet 2009/03/05 DNS遭攻陷,多家知名網站慘被攔截轉址,網路資訊 2009/03/05 [教學]遭遇不明網路劫持該如何自救?網路資訊 2009/03/07 [...]
[...] 就連本刊報導,也從原先預估為DNS Spoofing攻擊訂正為路由器漏洞,後來也發現並非路由器本身的問題。 [...]
[...] 就連本刊報導,也從原先預估為DNS Spoofing攻擊訂正為路由器漏洞,後來也發現並非路由器本身的問題。 [...]





截至3月5日下午3點,各地仍有傳出綁架轉址的情形,看來該情形尚未修復。
這是否意味著將來即便是正當網站的網址,都很可能被綁架勒贖?