首頁 > 資安知識庫 > 資安管理政策與教育訓練  > ISMS(ISO 27001)與顧問服務

更具破壞力的DNS攻擊:中國最大搜尋網百度遭駭事件

作者:黃繼民 -2010 / 03 / 15 列印 加入我的最愛 分享 將這篇文章分享到 Plurk 噗浪

2010年1月,當大夥兒正在議論著Google準備出走中國市場的同時,中國境內最大的搜尋網-百度(baidu.com)發生了最大規模的DNS駭客攻擊事件。網域名稱服務(DNS, Domain Name Service),其工作是將一連串人類不容易記憶的網路IP位址轉換成容易辨識的網域名稱(例如:220.181.6.175 = www.baidu.com);我們每天工作及生活中所使用各項網路服務,例如網際網路、電子郵件、線上遊戲、股市交易、企業對外的服務網站及內部的應用服務,甚至是目前最夯的3G服務、雲端應用等等,都必須透過DNS來完成。

此次百度網站所發生的DNS攻擊事件,不僅對於百度網站的商業營運造成極大的傷害跟損失,在一天之內造成股價下跌14.08美元(跌幅3.51%),商務損失折合台幣約3,700多萬,也間接促使其他搜尋網站(如Google、Yahoo等)使用率提升20%~30%。

百度DNS駭客攻擊事件
百度DNS遭受駭客攻擊事件發生於2010年1月12日,最初由澳洲的網友們察覺百度網站無法連結,使用者並曾一度發現百度原本的首頁被置換成「伊朗網路大軍(IranianCyberArmy)」的抗議網頁以及Yahoo和其他不同的網頁。百度人員確認問題並非網站伺服器遭受攻擊,而是百度註冊baidu.com網域名稱所在的美國網域註冊單位,遭受駭客透過DNS系統漏洞入侵,並非法竄改DNS記錄所致,DNS服務癱瘓也造成了中國境內及全球的百度網站使用者,無法正常查詢baidu.com所屬的網路服務。在長達近7個小時的網域控制權爭奪戰,並啟用備援的網域名稱baidu.com.cn提供服務後,百度在大部分國家和地區才陸續恢復正常服務。這次的攻擊造成百度網站服務癱瘓時間約11個小時,百度公司的商務及商譽都受到很大的傷害,百度已針對該美國網域註冊商提出告訴並求償損失,認為註冊商違反服務協定以及重大疏失

百度事件並非首例,就在2009年,相同的攻擊方式也曾經發生在全球知名的微型部落格Twitter身上,事件雖然很快的在1個小時內修復,但仍造成數百萬名Twitter用戶無法存取服務,同樣的事件也發生在其他的網站。此次的駭客攻擊手法被歸類為網路嫁接(Pharming)或稱作中間人攻擊(Man-in-the-middle attack)。《O''reilly DNS & BIND》一書作者Cricket Liu提到,網路嫁接的攻擊方式不同於以往駭客直接針對企業的網站伺服器發動入侵破壞,一旦受害單位的DNS記錄遭到竄改,「正確的網址」便能夠在不知不覺的情況下被導引到「有問題的網址」(見圖1);趨勢科技資深安全分析師Rik Ferguson也曾提過,藉由網路嫁接的攻擊方式,駭客可以製造偽冒網站,誘騙到訪的使用者登入帳號憑證,或施放病毒惡意程式,得手後再將使用者重新導引回真實的網址,我們很難透過傳統的安全防禦設備作準確的檢驗,事件的察覺非常困難。網路嫁接的攻擊方式多半是透過區域網路的Botnet惡意軟體修改個人電腦,但此次百度及Twitter事件已經驗證DNS攻擊方式來達成網路嫁接的可行性,新的網路犯罪方式正在悄悄醞釀著。



DNS系統風險威脅
從上述的情況我們可以瞭解到,DNS服務是維持網路營運服務的重要齒輪樞鈕,在2009年,位於泰國的某T大車廠內網的Windows系統漏洞遭受蠕蟲攻擊,更波及該系統上的DNS服務,由於DNS服務癱瘓而影響內部ERP系統、電子郵件等重要服務停擺;此類事件往往是骨牌效應的現象,也因此,管理者對於整體資訊維運服務設計上,也必須謹慎檢驗各重要系統的服務關係鏈。

DNS的攻擊方式不僅止透過入侵竄改DNS記錄,在2008年的Black Hat黑帽大會中,IOActive安全研究人員Dan Kaminsky所公布的DNS安全漏洞問題,即是向全世界宣告DNS安全的重要性。Kaminsky所發現的DNS漏洞主要會被用來進行快取下毒攻擊(DNS Cache Poisoning),將合法流量導向惡意網站;但Kaminsky在黑帽大會上更指出,該些漏洞甚至可能讓駭客攻擊VPN、SSL認證、軟體自動更新系統、垃圾郵件過濾工具以及VoIP系統等,針對此一DNS漏洞,最少有15種的攻擊可能性。

DNS服務可說是各系統網路服務的起始點,針對DNS的安全風險我們可以概分三個層面。

1. 系統漏洞:
DNS最大的安全威脅來自於系統漏洞,包括作業系統的漏洞、DNS系統的漏洞,甚至於是搭載在同一伺服器上的其他軟體服務漏洞。對於多數的系統管理者來說,系統漏洞的修補不是件容易的事情;管理者必須經常注意各項系統漏洞的通報,並且評估修補作業對於原本系統運作的影響。以百度事件為例,其註冊baidu.com所在的美國網域註冊單位便是因為沒有完成DNS漏洞的修補而讓駭客找到機會。

市場上普遍以柏克萊大學所開發的BIND及微軟的Windows Server為常見的DNS軟體工具,資源雖然免費但是安全性與管理維護上對於系統管理者都是很大的負擔,透過專業的DNS系統是比較有效率的解決方案。專業DNS系統會採取安全強化的系統平台,避免一般軟體作業系統可能的問題;並且由DNS安全實驗室更新即時的DNS安全問題,及主動提出修補,漏洞修補與系統更新程序都能以即時、有效率的方式完成。

2.DNS服務阻斷攻擊:
自2000年第一起的DoS阻斷式攻擊出現後,一直是資安威脅排行榜的重點,現今市場的資安設備都會將DoS/DDoS攻擊列為防護功能之一(端看設備的處理效能)。但面對DNS的DoS/DDoS攻擊防護並不容易,對於犯罪者所發起的大量DNS查詢要求,一般DNS系統只能乖乖的照單全收,因此整個系統效能嚴重耗損且服務癱瘓,造成合法使用者無法使用DNS查詢服務。由於DNS屬於網路基礎的服務,因此安全防火牆及入侵防禦系統多半無法有效的針對DNS阻斷攻擊加以識別或定義標準門檻值。

透過DNS Cache Server或許是個解決方法,可避免主要的DNS主機直接面對攻擊,不過我們仍需考慮DNS快取下毒攻擊的疑慮。專業的DNS系統對此提出DNS Firewall的設計,當專業DNS系統接收DNS查詢要求時,除了能夠記錄每個查詢來源外,也同時監測這些來源的行為是否有異常的情況。專業DNS系統針對異常DNS行為的來源進行管制並通報管理者,其目的在保護系統系統資源提供正常的DNS使用者,避免攻擊造成服務癱瘓或效能不佳的情況。

3. DNS安全協議:
最近備受關切的DNS安全議題則為DNS系統間資訊互通的安全協議,全球目前主要以DNSSEC為主流,將可以有效抵禦DNS快取下毒攻擊方式。Dan Kaminsky所公布的DNS快取下毒攻擊,犯罪者可以利用DNS Cache Server在無法驗證確認資料供應者(DNS Primary Server)的情況下進行假冒的資料更新。DNS Cache Server可視為正版DNS Server的分身,提供一般網路使用者對於經常查詢的記錄得以快速的回應,除了降低DNS真身的負荷之外也同時避免駭客直接侵入系統的威脅。Cricket Liu表示,目前”.gov”及”.org”頂層網域名稱已經開始採用DNSSEC安全協議,美國聯邦政府的所有機構及其內網使用DNSSEC,並且也獲得部分商業網域的支持。DNSSEC醞釀至今已15年了,雖然包括BIND和Windows等多數的DNS系統都已經支援,不過管理簽署的操作相當麻煩,容易造成DNS系統間溝通發生問題而造成其他的災難。

從事件學到的啟示
這次百度DNS駭客攻擊事件告訴我們核心網路服務(Core Network Service)的重要性,市場研究單位Gartner在去年的報告中新增一項研究議題「DDI」,提到DNS、DHCP、IP Address Management等3項技術將是未來網路發展的重點,這些技術都是核心網路服務(Core Network Service)的重要元素,無論在商務營運管理(Business Operation Management)或支付卡PCI-DSS法規中,都要求資訊系統管理者對核心網路服務進行管理與保護。

近幾年來,具威脅的駭客攻擊方式,已不再跟功能越來越強大的資安防護工具硬碰硬,反而採取更符合網路正常行為且更有效率的手法。從百度的事件看來,攻擊目標是以更上層的網域服務單位著手,相對的也很容易透過內部合法的員工裝置進行攻擊。在2008年由Infoblox、The Measurement Factory針對全球公眾DNS系統的調查中,全球1,190萬台的外部DNS服務主機,竟有高達25%的比率沒有執行修補作業,並且允許任一用戶登入造訪。

DNS系統的風險威脅單單只倚靠安全防護是不夠的,所有的資訊安全專家都會一再提醒,人為管理絕對是必須的。根據TANET的研究報告中,DNS問題事件中以人為操作疏誤佔極高的比例,包含不小心的新增、刪除、修改DNS記錄;而這些操作行為並無法被加以稽核,因為傳統DNS系統並沒有角色權限的區分。如果犯罪者透過取得系統管理者權限侵入DNS竄改記錄來假冒真實的企業商務網站或金融交易網站,則必須等到真的有受害民眾提出反映才有可能讓系統管理者警覺。


本文作者任職達友科技


推薦此文章
34
人推薦此新聞
文章回應話題
匿名 發表於: 2010 / 03 / 17
多家企业网络入侵事件传言的同源木马样本分析报告

http://www.antiy.com/cn/security/2010/s100128_002.htm

112百度域名劫持事件关联分析报告
http://www.antiy.com/cn/security/2010/s100113_001.htm

供参考
我要回應此文章
您的姓名:
回應內容:
  輸入圖片數字

你或許會對這些文章有興趣…