多個 DNS 執行上的快取記憶體下毒 (Cache Poisoning) 漏洞
風險: 中度風險
由於 DNS 協定和通用 DNS 執行上存在漏洞,促使 DNS 快取記憶體下毒 (Cache Poisoning) 的攻擊。 DNS 快取記憶體下毒 (也可稱為快取記憶體污染) 是一種攻擊技術,允許攻擊者將偽造的 DNS 資料輸入到快取名稱伺服器的快取記憶體。這種攻擊技術的概念已被公開了一段時間,在以往的公開文獻上已描述了大量的 DNS 協定和通用 DNS 在執行上所引起的 DNS 快取記憶體下毒漏洞。以下是一些上述的不足或缺陷例子:
- 交易碼空間不足
DNS 協定規格包括一個 16 位元的交易碼項目。如果依照規格實作,並利用強效隨機數產生器任意選擇的交易碼,攻擊者平均需要作 32,768 次嘗試,才能成功預測交易碼資料。一些有瑕疵的實作可能使用更少位元數作為交易碼, 於是嘗試更少次數就能預測交易碼。另外,亦有不少實作存在已知的交易碼隨機性錯誤。 - 多個未完成請求
當收到多個相同查詢詢問同一資源記錄(resource record - RR)時,一些 DNS 服務實作會產生多個有關此資源記錄的對外查詢漏洞,此種狀況可引致"生日攻擊"的可能,並明顯提高攻擊者成功機會。 - 使用固定來源連接埠產生查詢
一些現有實作於起始時會隨意安排連接埠(或隨機選擇),並重覆使用來源連接埠作對外查詢。有些實作則以傳統 DNS 編配的連接埠號碼 53/udp 作固定連接埠的對外查詢。
最近更多的研究顯示此些問題會以不同的結合方法,以改良的快取記憶體下毒(Cache Poisoning)攻擊並產生高效漏洞攻擊技巧。無論有否開啟 DNS 辨析器( DNS 辨析器如能向管理網域以外的客戶端提供循環名稱分析查詢,即處於開啟狀態),快取 DNS 辨析器都會首當其害。此類快取辨析器是最常見的攻擊目標,Stub 辨析器亦同樣受險。
因這些漏洞的攻擊,全是依賴攻擊者偽冒流量。在伺服器中每項查詢的來源連接埠隨機實作,能在現時協定規格的範圍中,起了對攻擊的實際舒緩作用。隨機來源連接埠可帶來額外約 16位元的資料隨機性,迫使攻擊者需作額名的預測。雖然從技術角度看連接埠合共有 65,535 個可用,但實作者卻不能編配全部連接埠(1024以下的連接埠可能被保留, 其他連接埠亦可能已被編配等原因),反之,把可用的連接埠隨機卻大大增加攻擊的彈性。值得大家注意的是,在沒有對DNS協定作改動的情況下,如DNS Security Extensions (DNSSEC)所引入的考量,上列的緩解措施並不能預防快取記憶體下毒。相反,如能恰當實作此等緩解措施,可大大減低攻擊的成功機會,甚至令攻擊失效。
成功進行快取記憶體下毒攻擊的攻擊者可利用漏洞,將名稱伺服器的用戶端連接到不正確和可能含有特定服務的惡意主機。因此,受害者的網絡交通、電郵和其他重要的網絡資料都會被重新導向至攻擊者控制的系統。
此漏洞的攻擊方法已在互聯網廣被發佈,其風險亦不斷上升。
HKCERT 已於 2008年7月31日 發出 保安忠告
影響
- 仿冒
受影響之系統或技術
- 微軟視窗 2000 伺服器 DNS
- 微軟視窗伺服器 2003 DNS
- 微軟視窗伺服器 2008 DNS
- BIND 9.3
- BIND 9.4
- BIND 9.5
- 思科 IOS 軟件
- 思科網絡 Registrar
- 思科應用程式及網絡內容系統
- 思科 Global Site Selector 結合了思科網絡 Registrar 使用
- Juniper 防火牆安裝了 ScreenOS
- Juniper J-Series 路由器安裝了 JUNOS (2008年5月23日之前的版本)
- Juniper 交換器產品安裝了 JUNOS (2008年5月23日之前的版本)
- Solaris 8 BIND 8.2.4 及之前的版本
- Solaris 9 BIND 8.3.3 及之前的版本
- Solaris 10 BIND 9.3.4-P1 及之前的版本
- Nominum 3.0.4.0 之前的版本
- Vantio 3.3.1.0 之前的版本
解決方案
- 怎樣找出你所用的DNS 伺服器是否存在漏洞?
- DNS Checker (http://www.doxpara.com/?p=1185):
此工具能夠檢查你所用的 DNS 伺服器來源連接埠及查詢碼的隨機性。如果有足夠的隨機性,這個測試便可通過。 - DNSStuff Test Tool (http://www.dnsstuff.com):
此工具能夠檢查你所用的 DNS 伺服器來源連接埠及查詢碼的隨機性,並以圖表方式清晰顯示。 - DNS-OARC 測試 (參考:https://www.dns-oarc.net/oarc/services/porttest):它是一個利用自身 IP 位址檢查任何 DNS 伺服器的通用測試,它使用現存的網域查詢指令行工具去詢問 "porttest.dns-oarc.net" 的TXT 記錄。
這裡有三個工具可作檢查
[Linux] | dig @IP-of-DNS-SERVER +short porttest.dns-oarc.net TXT | |
[Windows] | nslookup -type=txt -timeout=30 porttest.dns-oarc.net IP-of-DNS-SERVER |
此測試的結果取決於被所觀察到的來源連接埠標準差 (standard deviation),值會是 GREAT、GOOD 或 POOR。
- 即時的行動 - 安裝供應商的修補程式
- 在安裝軟體之前,請先瀏覽軟體供應商之網站,以獲得更多詳細資料。
大量的供應商已發放修補程式,在名稱伺服器上實行隨機配置來源連接埠 (source port randomization)。 這個修正減低了快取記憶體下毒攻擊的可行性。Stub 辨析器也受這個漏洞影響,系統管理員應對那些以攻擊者行為回應而發送查詢及接收封包的 Stub 辨析器修保漏洞。 請瀏覽受影響系統的部份,以獲得供應商的更多詳細資料。系統管理員應留意使用者為用戶端作業系統安裝相應的修補程式,令 stub resolver 實行隨機配置來源連接埠 。
備註: 路由器、防火牆、代理伺服器及其他閘道裝置等透過網絡地址轉換 (NAT - Network Address Translation) [ 特別是執行端口地址轉換 (PAT - Port Address Translation)] 運作的裝置,經常重訂來源連接埠來追蹤連線狀態。PAT裝置會減低或消除那些 DNS 軟件 透過安裝修補程式實行隨機配置來源連接埠所帶來的安全改善。如果我們能做到以下的臨時處理方法,在網路閘道上強制隨機配置來源連接埠,漏洞就可以解決。
聯絡你所屬的 DNS 伺服器擁有者去修正漏洞
如果你所存取的 DNS 伺服器不是你管轄的,請聯絡 DNS 伺服器擁有者並告知他們這個漏洞。- 實行隨機配置來源連接埠(source port randomization)
建議執行 DNS 軟體的供應商參考 IETF 草稿文件 "Measures for making DNS more resilient against forged answers" ,以獲得更多在它們產品中能夠緩和風險的資料。由於這份文件仍在編輯中,在正式發行為 RFC 文件前仍有可能會被修改。亦可參考 IETF 草稿文件 "Port Randomization" ,了解運用隨機連接埠的廣泛方法,緩減其他偽冒攻擊類型。
- 臨時處理方法
- 強制網路閘道使用隨機配置來源連接埠
如果網路閘道是使用 iptables ,不論 DNS 軟件在防火牆、路由器或代理伺服器的後端使用,我們也可透過NAT的運作為來源連接埠引入額外的隨機性(詳見 --random 選項及 SNAT 目標)。此方法適用於本機產生及轉發封包。詳細資料,請參考 "Mitigating DNS Cache Poisoning Attacks with iptables" - 關閉循環查詢,或限制外來的 DNS 循環查詢
管理員可以在 DNS 伺服器關閉循環查詢或只接受白名單上子網絡的循環查詢。 - 關閉 glue-fetching 選項
管理員可以在 DNS 伺服器關閉 glue-fetching 選項,從而可避免快取記憶體下毒。 - 過濾網絡邊界的交通
由於進行這些攻擊需要有偽造 IP 位址的能力,管理員應留意網絡邊界的交通過濾。 IETF Request for Comments (RFC) 文件 RFC 2827 、 RFC 3704 及 RFC 3013 描述了實行這些防禦措施的最佳方法。在決定那些變更才是合適前,請了解你的網絡設定和服務要求。 - 執行本機的 DNS 快取記憶體
將名稱伺服器分開為兩部份,一部份為區域的請求提供授權回應 (公眾查詢) 或另一部份為內部系統提供名稱分析循環查詢 (本機的 DNS 快取記憶體)。除了在 stub辨析器實行隨機配置來源連接埠,無論是用戶端系統和在網絡規劃上接近用戶端的伺服器,管理員可以使用本機所有服務快取記憶體辨析器來保護系統。執行本機 DNS 快取記憶體必須與上述的網絡分割 (network segmentation) 和過濾策略一起使用。 - 採用沒有漏洞的 DNS 伺服器
如果你不能修補 DNS 伺服器,或 DNS 伺服器不是你管轄的,你可告知 DNS 伺服器擁有者去修正伺服器。你也可以轉用其他沒有漏洞的 DNS 供應商,例如:OpenDNS (http://www.opendns.com),它們提供了兩個 DNS 伺服器的 IP 位址。OpenDNS 採用 anycast 的方法處理網路交通,所以它應該能夠處理更多來自不同地區的請求。不過,建議你在使用 OpenDNS 前,應先對DNS回答的表現進行測試。
如果你不能修補 DNS 伺服器,或 DNS 伺服器不是你管轄的,以下的臨時處理方法可緩解危機。
漏洞識別碼
資料來源
相關連結
- http://www.us-cert.gov/cas/techalerts/TA08-190B.html
- http://www.kb.cert.org/vuls/id/800113
- http://www.auscert.org.au/render.html?it=9546
- http://www.kb.cert.org/vuls/id/484649
- http://www.kb.cert.org/vuls/id/252735
- http://www.kb.cert.org/vuls/id/927905
- http://www.kb.cert.org/vuls/id/457875
- http://www.microsoft.com/technet/security/bulletin/ms08-037.mspx
- http://cipherdyne.org/blog/2008/07/mitigating-dns-cache-poisoning-attacks-with-iptables.html
- http://www.doxpara.com/?p=1162
- http://isc.sans.org/diary.html?storyid=4765
分享至