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

01-29

在用戶驗證他們有域名控制權後，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或少量的源埠。

為了測試這一點，我建立了一個簡單的nameserver，使用dnsmasq來控制一個域，並使用tcpdump來捕獲它的流量，因為我多次嘗試在Detectify站點上驗證它。在Wireshark中打開結果捕獲文件顯示，確實有一個DNS查詢來自http://scanner.detectify.com。源埠看上去足夠隨機,但是事務ID在哪裡?

它是零!事務ID每次都為零，由於我知道準確的查詢Detectify發送，所以欺騙正確的響應只是猜測源埠的問題。

POC

現在，讓我們來驗證一下http://example.com。創建一個欺騙的DNS響應有效載荷很簡單，採取真正的響應，由tcpdump捕獲，並手動更改域名。nping可以用來發送這個響應，欺騙源IP和埠:

nping --udp -g 53 -p 30000-39999 -S 199.43.133.53 -c 100 --rate 100000 -N -H --data 000085000001000100000000076578616d706c650000100001c00c00100001000000010038376465746563746966792d766572696669636174696f6e3d6530363663623430643165353234323362613661646539393562613433636663 scanner.detectify.comn

上面的命令會嘗試發送假的DNS響應，從199.43.133.53(http://example.com的真實名稱)到scanner . http://detectify.com，源埠在30000到39999之間循環。現在這個問題就很簡單了，只需在我的筆記本電腦上運行，在Detectify的網站上反覆點擊驗證即可。

IP欺騙的用途

幾乎所有的isp和數據中心今天都進行了出口過濾，以防止欺騙的數據包脫離他們的網路。所以，IP欺騙最常見的用途是DDOS攻擊，特別是DNS放大攻擊。

為了進行實踐分析，我需要一個不做這種過濾的主機，此外，攻擊主機和受害者之間的延遲必須儘可能地低，以最大限度地提高在真正的應答之前收到的虛假響應的機會。

本文翻譯自https://labs.detectify.com/2017/09/11/guest-blog-bypassing-domain-control-verification-with-dns-response-spoofing/，如若轉載，請註明原文地址： http://www.4hou.com/technology/7657.html 更多內容請關注「嘶吼專業版」——Pro4hou