通過DNS響應欺騙來繞過域控制驗證

最新 09-16

在用戶驗證他們有域名控制權後，Detectify才會掃描這個網站。其中一個驗證方法是向域添加一個DNS TXT記錄，其中包含由Detectify提供的字元串。當用戶進行驗證時，Detectify將執行DNS查詢並檢查相應字元串。讓我們來看看它是如何通過 DNS 響應欺騙來繞過域控制驗證。

譯者註：Detectify是基於SaaS網站安全掃描工具，是一個免費的幫助站長們發現網站漏洞的安全掃描應用工具，通過該工具來掃描網站的安全性能。

DNS欺騙

DNS查詢和響應通常是通過UDP發送的，因此攻擊者可以使用IP地址欺騙，向來查詢的DNS伺服器的客戶端發送DNS響應。當然，如果用戶的設備能匹配未處理的查詢，則只接受響應。具體來說，以下欄位必須匹配:

1.源(DNS伺服器)IP地址

2.目的地(DNS客戶端)IP地址

3.源(DNS伺服器)埠-總是53

4.目的地(DNS客戶端)埠——DNS請求的源埠

5.「事務ID」——由客戶機生成的16位數字

6.「問題」——本質上是DNS查詢的副本

已知源埠、源IP和目的地IP。DNS「問題」通常可以被猜到，甚至可以從真正的查詢中複製出來，如果攻擊者能夠訪問它的話，唯一未知的欄位就剩目標埠和事務ID了。

大約9年前，許多DNS客戶端使用了一個固定的或容易預測的源埠或事務ID或兩者都使用。這樣，雖然有65536個可能，但猜測一個16位的數字還是完全可行的，而攻擊者可以在實際響應到達之前，將數千個虛假的響應包發送到DNS客戶端。在2008年7月，Dan Kaminsky揭示了這個問題，在問題被披露後，DNS實現被快速修補以使用真正隨機的事務id和埠號，同時各大廠商也開始採用DNSSEC協議。

對驗證器的驗證

為了避免任何緩存的影響，Detectify的驗證器可能會執行自己的DNS查詢，而不是只使用操作系統的DNS解析器。如果是這樣，它仍然可以使用可預測的事務ID或少量的源埠。