通過偽造DNS響應繞過域名所有權驗證

譯者：testvul_001

預估稿費：120RMB

投稿方式：發送郵件至linwei#360.cn，或登陸網頁版在線投稿

前言：

我們的客座博主和Detectify眾包團隊黑客Evgeny Morozov將在本文中解釋他是如何通過偽造DNS響應來繞過Detectify的域名所有權驗證的。非常感謝Evgeny的突出貢獻—眾包團隊中有這樣的研究者很令人感到自豪。

當用戶需要使用Detectify來掃描一個網站時，我們必須先驗證他對這個域名的所有權（幾乎所有的在線掃描都有這種驗證）。其中的一種驗證方式是在DNS的TXT記錄中增加Detectify提供的字元串。當用戶點擊驗證時，Detectify會執行一個DNS檢查來確認是否存在驗證字元串。下面我們來看看如果驗證一個你並不擁有的域名會發生什麼。

DNS 偽造背景

DNS查詢和響應通常都是通過UDP協議傳輸的，所以IP地址偽造可以讓查詢客戶端認為攻擊者所發的DNS響應是來自於正常DNS伺服器的。當然查詢客戶端只會接受明顯符合要求的響應，下面的幾個項目必須符合要求：

1、源IP地址（DNS伺服器）

2、目的IP地址（DNS客戶端）

3、源埠（DNS伺服器）-通常是53

4、目的埠（DNS客戶端）-DNS請求的源埠

5、Transaction ID- 客戶端產生的16 bit數字

6、Questions-本質上是複製的DNS查詢請求

源地址和埠以及目的IP都是已知的，DNS 「question」可以猜出來，或者從一個攻擊者可以訪問的地方複製一個真實的查詢。現在唯一不能確定的就是目的埠和Transaction ID了。

九年前很多DNS客戶端修復了可以預測源埠和Transaction ID的漏洞。猜測一個16bit的數字是完全可行的—因為只有65536種可能，攻擊者完全可以在真實的DNS響應到達前給DNS客服端發送成千上萬的假響應包。2008年的7月Dan Kaminsky披露了這個問題。隨後DNS維護方就用完全隨機的Transaction ID和埠修復了這個問題。所以這種攻擊已經過時了，那麼真是這樣嗎？

通過驗證

我有一種預感，為了避免得到緩存數據，Detectify會執行自己的DNS查詢，而不僅僅是使用系統的DNS解析工具。如果這樣的話，它就仍可能還在使用可預測的Transaction ID和小範圍的源埠。

事情簡單了！！！

Transaction ID每次都是0，現在我準確的知道Detectify發出的DNS查詢，所以偽造一個正確的DNS響應的唯一問題就是源埠。

POC

儘管現在我已經可以報告漏洞了，但是我想確定它是可利用的。一個理論漏洞和可利用的漏洞還是有差別的。

下面我們嘗試驗證example.com。創造一個偽造的DNS響應payload很簡單：首先用tcpdump抓取一個真實的響應，然後手工改變域名。Nping工具可以用來發送這個響應並偽造原地址和埠：

事實上現在所有的ISP和數據中心都會在出口過濾偽造的數據包—防止它們離開自己的網路，並且有很好地理由。偽造的數據包最常見的用途是DDOS攻擊，特別是DNS反射放大攻擊。所以我需要一個不會做過濾的主機，並且攻擊機和受害者之間的延遲必須儘可能的低，以提高偽造的響應在真實的響應之前到達的概率。

如何找到這樣的一個主機就留給讀者作為練習了。但是現在我可以自豪的說我已經是6個虛擬伺服器的主人了，雖然其中的5個並沒有什麼卵用（所幸它們都很便宜）。在瘋狂的點擊Detectify網站的驗證按鈕後，我們終於得到了下面的提示：

成功了！

總結：

Detectify在報告後的三小時內修復了漏洞。

點擊展開全文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！