[[183819]]

前言

為了尋找新的有趣的域名解析系統漏洞，我決定查看各種各樣的頂級域名，并分析它們的錯誤配置，經過一些初步的搜索，我發現有一個很好的開源服務工具，可以幫助DNS管理員掃描它們的域名系統，察看是否存在錯誤配置，這就是瑞典互聯網基金會開發的DNScheck工具,該工具會高亮顯示出各種各樣的奇怪DNS配置錯誤，這種錯誤例如：有一個權威名稱服務器列表，一個域名的權威名稱服務器和該名稱服務器在上一級頂級名稱服務器的設置之間不配置(引起這種問題的原因在“通過劫持DNS解析服務器攻擊目標”這篇文章中可以看到)。盡管這些域名有配置錯誤，但是它并沒有明確指出漏洞在哪里，不過它可以讓我們知道：如果發現有些配置是錯誤的，那么研究這些錯誤配置，將是研究工作的一個不錯的開始。

[[183820]]

截止寫這篇文章時，有1519個頂級域名。我并沒有手動的逐個掃描每一個頂級域名，我選擇寫一個腳本來自動掃描所有頂級域名。我已將這個腳本的掃描結果放在了Github上，名稱是“TLD Health Report”。該腳本可以高亮顯示出有嚴重配置錯誤的頂級域名。在花了一兩個小時對頂級域名配置錯誤進行檢查后，我在“.gt”頂級域名上發現了一個有趣的問題，該錯誤可以從Github的頁面看到，下面是一部分：

正如上面我們看到的，maestro.gt域名存在多個錯誤或警告狀態，有無法路由錯誤，并且是“.gt”頂級域名的一個無效的主名稱服務器(MNAME)。我們可以通過執行下面的dig命令，來看一下這個配置：

如上所示，我們對隨機的一個“.gt”域名進行dig后得到了一個NXDOMAIN錯誤(因為我們請求的域名不存在，可以被注冊)，而且與此同時，我們得到了一個起始授權機構(SOA)的記錄，maestro.gt域名作為了主名稱服務器。因此任何“.gt”頂級域名下，不存在的域名發送的請求，在返回的SOA記錄中的域名都是maestro.gt(SOA記錄)。

“無法解決的”另一個說法是“還沒有解決”

如果你讀過我之前寫的關于DNS漏洞的一篇文章，你就有可能已經猜到了為什么這些域名問題還沒有被解決。那是因為這些域名不存在(可以被別人注冊并使用)!事實證明，maestro.gt域名也是開放注冊的。在進行了一些搜索和Google翻譯后，我發現在“Registro de Dominios .gt.”上可以注冊該域名，每年大約需要60美元(至少需要注冊兩年)。

你相信它使用Visa卡嗎?

雖然價格昂貴，但是和美國中部的許多其他頂級域名注冊相比，它的注冊過程很快，并且完全自動化。唯一的缺陷是我的借記卡因為可疑活動被立即凍結了，我不得不去網上解凍它，使訂單可以通過：

很顯然，上午1:30買了一個危地馬拉域名是卡片被凍結的理由(成功注冊了這個域名)。

發現可能存在的問題

由于起始授權機構的主名稱服務器(SOA MNAME)是DNS的一個復雜特性，我無法預測DNS流量中有什么。因此我配置了我的“Bind DNS”服務器(使用了剛才成功注冊的域名)，并發送查詢，來請求“.gt”下所有域名的A記錄，并根據我的IP地址，來過濾出所有數據包。我設置了tcpdump，將所有DNS流量打包成一個pcap文件，便于后面的分析。

我在早晨發現的東西是我遠遠沒有預料到的，當我檢查pcap數據時，我發現來自危地馬拉各地的計算機向我的服務器發送了DNS查詢請求。

世界上正在發生什么呢?進一步觀察結果只會產生更多的混亂：

大部分DNS UPDATE請求流量來自于內部IP地址。上面是一個DNS UPDATE請求的例子，正在嘗試更新我DNS服務器的區域，目的是為了更新一個SRV記錄，包含一個LDAP服務器，它屬于危地馬拉的一個隨機的政府網絡。

WINDOWS活動目錄域

為了理解我們得到的這個流量是什么，我們需要快速了解一下什么是Windows活動目錄(AD)域和動態DNS(DDNS)。Windows域的結構與互聯網域名的結構大致相同。創建一個Windows域時，你必須指定一個DNS后綴，這個DNS后綴可以看作是一個基域(父域)，在這個父域下，所有子域或機器的簡單主機名都包含這個子域名。例如，我們有一個thehackerblog.com域，在這個父域下，有兩個活動目錄網絡：east和west。在thehackerblog.com父域下，我們可以設置兩個子域：east.thehackerblog.com和west.thehackerblog.com。如果我們有一個專門的WEB服務器來放置east部門的所有文檔，它的主機名就有可能類似于documentation.east.thehackerblog.com。我們為該網絡建立了一個域樹，如下示例：

類似于documentation.east.thehackerblog.com的主機名允許計算機和人們在這個網絡中輕松地找到對方。該網絡的DNS服務器會將這個人類可讀的主機名轉換成該機器指定的IP地址，這樣你的計算機才會知道去哪請求你尋找的信息。因此，當你在瀏覽器鍵入documentation.east.thehackerblog.com這個內部的網站URL時，你的計算機首先會向該網絡的DNS服務器發出請求，目的是為了獲得這個主機名對應的IP地址，從而找到這個主機并將流量路由過去。

根據這種結構，產生了一個問題，在這個網絡中，由于機器的IP地址會經常改變，當documentation.east.thehackerblog.com的IP突然改變后，會發生什么呢?網絡中的DNS服務器如何才能知道該機器的新IP地址呢?

WINDOWS動態DNS(DDNS)

Windows活動目錄網絡通過動態更新機制來解決這個問題，動態更新的核心其實很簡單。為了將documentation.east.thehackerblog.com的記錄保持為正確的和最新的，該服務器會偶爾訪問網絡的DNS服務器，并更新它的DNS記錄，例如，如果documentation.east.thehackerblog.com的IP地址突然改變了，該服務器會訪問域的DNS服務器，并告訴它：“嗨，我的IP改變了，請將documentation.east.thehackerblog.com的IP記錄更新為我的新IP，以便于人們知道我在哪”。這就好比一個真實世界的人在搬家后，它可以通過郵件，將新的地址通知給它的朋友、工作場所、及在線商店。

這個技術的關鍵點總結如下(這是從“理解動態更新”中引用的)：

1.DNS客戶端使用該計算機的DNS域名發送一個SOA類型的查詢。

2.該客戶端計算機使用它當前配置的完全合格域名(FQDN)(如newhost.tailspintoys.com)，作為這個查詢的指定名稱。

對于標準的主要區域，在SOA查詢響應中返回的主服務器或擁有者是固定的和靜態的。主服務器名稱始終與準確的DNS名稱相匹配,因為該名稱會存儲在區域中，并顯示在SOA資源記錄中。然而,如果正在更新的區域是目錄集成區域,則任何加載此區域的DNS服務器都可以響應此SOA查詢,并在SOA查詢響應中動態插入它自己的名稱作為此區域的主服務器。

3.DNS客戶端服務會嘗試聯系主DNS服務器。

客戶端會對它名稱的SOA查詢響應進行處理，以確定這個IP所在的、接受它名稱的、作為主服務器的DNS服務器是被授權的。然后，它將根據需要執行下列步驟，以聯系并動態更新主服務器。

(1)客戶端向SOA查詢響應中確定的主服務器發送一個動態更新請求。

如果更新成功，則不執行其他操作。

(2)如果更新失敗，接下來，客戶端針對SOA記錄中指定的區域名稱，發送一個NS類型的請求。

(3)當客戶端收到此查詢的響應時，向收到的響應列表中的第一個DNS服務器發送一個SOA查詢。

(4)解析此SOA查詢后，客戶端向SOA解析出的服務器發送一個動態更新。

如果成功，則不執行其他操作。

(5)如果更新失敗，根據第(2)步中查詢響應的服務器列表，客戶端繼續下一個SOA查詢過程。

4.聯系到可以執行更新的主服務器后，客戶端將發送更新請求，隨后服務器將處理該請求。

更新請求的內容包括指示添加“newhost.tailspintoys.com”的 A(以及可能的PTR)資源記錄,并刪除“oldhost.tailspintoys.com”的這些相同類型的記錄，因為該名稱先前已經注冊過。

服務器還將進行檢查，以確保允許根據客戶端請求進行更新。對于標準主要區域，動態更新并不安全，因為任何客戶端的更新嘗試都會成功。對于活動目錄集成區域，更新是安全的，并且使用基于目錄的安全設置執行更新。

上面的過程是比較啰嗦的，主要過程可以精簡一些，因此我將上面步驟的重要部分加粗了，并將上面步驟中客戶端最重要的工作總結如下：

1.機器使用當前完整的主機名，向網絡中的DNS服務器發送一個SOA查詢。我拿剛才的例子來說明，它會包含documentation.east.thehackerblog.com作為主機名。

2.網絡中的DNS服務器收到這個查詢后，會返回它自己的一個SOA記錄，內容是指定的主名稱服務器的主機名，例如，這可能類似于ns1.thehackerblog.com。

3.然后，客戶端解析這個SOA記錄，并訪問解析出的ns1.thehackerblog.com主服務器，并發送它想要做的DNS更新/修改。

4.ns1.thehackerblog.com DNS服務器收到這個更新后，將documentation.east.thehackerblog.com的IP修改為新的IP。好了，一切路線再次正常了!

Windows域命名約定&最佳實踐指南

在我們理解危地馬拉DNS異常前，我們需要了解的最后一段信息是Windows域的要求：

“默認情況下，DNS客戶端不會嘗試動態更新頂級域名(TLD)區域，任何使用單標簽命名的區域都會被認為是一個TLD區域，例如，com、edu、blank、my-company。為了允許DNS客戶端能動態更新TLD區域，你可以使用更新頂級域名區域策略設置，或者你可以修改注冊表”

因此，默認情況下，你不能有類似于companydomain的一個Windows域，因為它是單標簽的，會被Windows認為是一個頂級域名，如.com，.net，或.gt。而這個設置可以(有希望的)在每個單獨的DNS客戶端被禁用，這很容易，僅需要companydomain.com一個域。雖然不是所有的公司都遵循這個說明，但還是在強烈建議，因為使用單標簽域名時，如果你內部網絡域名的末端被注冊為互聯網頂級域名的DNS根區域，就有可能引起很多沖突(一個著名的問題是名稱碰撞，這是一個熱門的網絡討論話題，并且還會繼續)。

把它們全放在一起----成為你域名的主人

現在我們有了所有信息，情況變得更加明朗了，危地馬拉國家有很多Windows網絡，在這些網絡中有內部的Windows域，它們采用了“.gt”頂級域名的子域名。例如，如果微軟在危地馬拉有一個部門，他們的內部網絡域名有可能類似于microsoftinternal.com.gt，這個機器會周期性的向它網絡中的DNS服務器發送動態DNS更新，以確保它網絡中的主機名是最新的，并能正確路由。由于種種理由，例如防止與外部公司互聯網子域名產生名稱碰撞，許多網絡很可能利用內部網絡域名，該域名在更廣泛的互聯網中是不存在的，例如在這個例子中，微軟可以使用一個內部的活動目錄域名，如microsoftinternal.com.gt，從而在這個域里，就不會和外部互聯網子域名microsoft.com.gt產生名稱碰撞。

問題是，很多巧妙的DNS配置錯誤，有可能造成本來是向內部域的DNS服務器發送的請求，卻發送到了頂級域名服務器上。這個問題被稱為名稱碰撞，并且是一個證據充分的問題，這有時也被稱為DNS查詢“泄漏”。

如果一個機器使用一個DNS解析器，并且不清楚該內部網絡的DNS設置，或配置錯誤，導致查詢到了外部網絡的DNS服務器，從而會使這個查詢泄漏到“.gt”頂級域名服務器上，因為他們是整個頂級域名空間的授權名稱服務器。名稱碰撞問題是非常常見的，并且因為這個原因，新的頂級域名往往會做大量的審查，以確保它們不是一般的內部網絡域名，例如.local，.localhost，.localdomain，等等。

當有“.gt”擴展的一個內部區域發生泄漏時，一個機器嘗試更新一條內部DNS記錄，并發送DNS更新查詢，但是意外的發送到了“.gt”頂級域名服務器上。例如，microsoftinternal.com.gt內部域有一個主機，并且向com.gt頂級域名服務器發送DNS更新查詢。以下是執行此查詢的示例，使用了nsupdate DNS命令行工具(大部分OSX和Linux系統都支持)：

我們可以看到該查詢導致了一個NXDOMAIN錯誤，但無論如何，卻返回了一個SOA響應，并包含了maestro.gt，它作為了主名稱服務器。對于該查詢，這是一個有效的SOA響應，因此所有主機會繼續向maestro.gt服務器發送DNS更新查詢，它的IP地址是52.15.155.128(這是我的服務器，我已經注冊了maestro.gt域名)。此更新查詢會以失敗結束，因為我將自己的DNS服務器設置成拒絕客戶端的更新請求(因為我不想主動干擾這些機器/網絡)。這就是為什么所有這些隨機的機器會向我的maestro.gt服務器發送DNS更新請求的原因。

我們現在遇到的問題從本質上說是一個新的DNS漏洞，這是名稱碰撞的結果，導致動態DNS更新被發送到“登記在頂級域名的SOA記錄列表中”的任何服務器。與常規名稱碰撞不同，為了利用這個漏洞，我不需要注冊一個完整的新的頂級域名，我們只需要注冊一個普通域名，只要這個域名存在于頂級域名的SOA記錄列表中就可以(就像我們注冊的maestro.gt)。

自己嘗試一下---快速的實驗室

如果你想在活動中看到這種行為，實際上重現相當簡單。我們將使用Windows 7系統作為我們的示例系統，并安裝在虛擬機里，并運行Wireshark監控所有我們機器發送的DNS流量。

更改你計算機的DNS后綴，以匹配危地馬拉活動目錄域，并將主DNS后綴設置為“.gt”頂級域名下的任何域，如下圖所示：

單擊確定并應用此新設置，將提示你重啟計算機。繼續進行，并且當Windows重啟時，請保持Wireshark一直運行。你可以看到，在啟動過程中，一些動態更新查詢發生了：

上圖是當Windows在啟動期間，Wireshark的輸出結果，具體活動如下：

1.嘗試向8.8.8.8DNS解析器查詢mandatory.dnsleaktestnetwork.com.gt的SOA記錄(結果是一個NXDOMAIN錯誤，因為它查詢的配置是8.8.8.8，而該域名在公共互聯網上是不存在的)。

2.Windows然后會對這個NXDOMAIN響應進行解析，并從頂級域名的響應中找到一個無效的SOA主名稱服務器記錄，這就是maestro.gt。

3.然后，Windows會訪問maestro.gt(此時它已經是我的服務器了)，并嘗試發送一個DNS更新請求。這會失敗，因為我把服務器設置成了拒絕模式。

4.然后，Windows會再次嘗試整個過程。

那么，這個問題有多普遍?

因為危地馬拉國家使用的是“.gt”域名空間，該空間和一些大的頂級域名相比很小，如.com、.net、.org、.us等等，因此，我們看到只有一小部分DNS請求受到這個問題的影響。但是，在較大規模的頂級域名空間上，使用了頂級域名的活動目錄域、并訪問常用頂級域名服務器的流量，有可能很大。

盡管我還沒有明確地找到任何以前的“關于動態更新SOA劫持”的研究報告，但幸運的是，我們有很多以前的“關于名稱碰撞”的研究，這很大程度上是由于擔心發布的頂級域名和內部網絡域名相矛盾，而內部網絡遍布全球。想要研究這個問題有多么普遍，我推薦讀一下《DNS中的名稱碰撞》這篇文章，這是ICANN委員會的報告，它對于這個問題有一個很好的概述，能更好的理解名稱碰撞問題、及它在互聯網中的影響。這篇文章包括了很多真實世界的數據，展現出了名稱碰撞問題有多大，這使得我們有一個很好的基礎，讓我們推斷出在這個世界里特殊的SOA動態更新變種分布有多廣泛。

也許，在這個報告中，真實世界中最震撼的數據是下面的這張表：

上表是一個頂級域名請求數據表，按照根域名服務器的DNS請求數量排列，單位是千。在原始報告中包含了前100個頂級域名，在這里我們只列出前20個。這張表揭示了原始數據中DNS請求泄漏、并訪問了根域名服務器的情況，而這個情況并不意味著到此為止。可以看出，有很多無效的“.local”頂級域名請求并查詢了根域名服務器，數據排在了第三位，而且比所有“.org”和“.arpa”的請求數量加起來還多。下面的餅狀圖也能進一步揭示問題的規模：

上圖顯示了一個驚人的結果，有45%的請求訪問了根服務器，這些請求來自于頂級域名，并且是不存在的、無效的域名，它們有可能是DNS請求泄漏的結果。也許更令人震驚的是，該數字可能更高，由于有些內部域有一個有效的頂級域名，但有一個無效的二級域名，例如之前我們提到過的microsoftinternal.com.gt。這些請求對于根服務器來講是有效的(因為“.gt”在根區域是一個有效的記錄)，但是可能在com.gt頂級服務器上會被視為泄漏/無效的。

該報告中提到了一個同樣很有趣的問題，它們觀察到了這些問題的流量，但是卻沒有進行更進一步的調查，如下圖：

很多請求采用了上面的格式，通常這是在查詢SRV記錄，盡管有些時候它們是在請求SOA記錄，但是它們似乎與微軟活動目錄服務有關。說明它們存在和本文相同的問題。

報告后面又再次提到：

意思是：“雖然在本研究中絕大多數觀察到的DNS流量是用名字查找的(例如，傳統的查詢)，但也探測到了其它一些DNS請求。這些都是動態更新的流量，應該永遠不會到達根服務器。畢竟，修改根服務器是不會使用動態更新的，更不用說起源于互聯網的隨機IP了。最可能的解釋是它們可能由于活動目錄安裝配置錯誤，流量走出了內部網絡，并泄漏到了公共互聯網上。需要注意的是，這項研究并沒有檢查導致這種流量的根本原因。”

該文章最終得到的結論是：

可惜的是，該報告對這個流量的大小并沒有給出任何陳述，因此和其它名稱碰撞相比，我們沒有好的辦法得到這個問題的百分比和總量。基于頂級域名可能返回完全隨意的SOA主名稱服務器域名這個事實(就是.gt和maestro.gt這種情況)，實際上要在更大的范圍內考慮安全問題，而報告中還沒有認識到這一點。這允許潛在的攻擊者通過注冊一個域名，就像我們利用的maestro.gt，進入到DNS的中間過程。

鑒于公認的這個有限的信息，我認為這個問題有可能正在積極地發生，許多頂級域名服務器在這個問題上肯定能看到一些不平常的流量。依賴于每個頂級域名SOA記錄的特殊配置，如果它們的SOA主名稱服務器是可以被注冊的，就像本案例中一樣，它們就有可能存在易受攻擊的漏洞。

修復這個問題&充分的TLD安全考慮

鑒于利用這個漏洞的門檻是如此之低(基本上僅僅需要買一個域名)，關注它所造成的影響有很多原因，我認為應該要求TLD確保它們響應的SOA的主名稱服務器字段是不能被解析的、或解析到TLD控制的服務器上，然后拒絕處理動態更新查詢。考慮到這個錯誤似乎很容易造成，因為SOA主名稱服務器字段不再用于從屬DNS復制，我不認為這種改變是不合理的。悲哀的是，如果你讀過本文前面提到過的生成的TLD健康報告的結果，你將會看到驚人數量的TLD在功能配置上是有問題的。鑒于這一事實，修復這個安全問題的希望也很低，即使是簡單的事情，就像是“使所有TLD名稱服務器處理于正確工作狀態”對于TLDs來講也是不實際的。如果我們甚至不能確保TLDs的健康，那么我們又怎么能希望確保所有TLDs能減輕這個問題呢?

呼叫網絡管理員去阻止他們自己網絡中這種類型的問題似乎也無法打贏這場戰爭，況且還有那么多的DNS名稱碰撞。同時通知并確保網絡管理員了解這個風險是很重要的，不過確保100%的網絡都能正確配置是不可能的。

隱私的噩夢

鑒于這個事實，這臺危地馬拉機器的問題建立在一個相當普通的基礎上，這個漏洞帶來了一個相當大的隱私問題，很多DNS請求包含了主機名，這是很隱私的(想像一下NANCY-PC、MYLAPTOP，等等)。由于各種觸發因素，造成機器發送了DNS更新查詢包，意味著用戶的個人電腦在他每次旅行、改變網絡、或重啟時都會向我的名稱服務器發送信息。這導致這個人只要帶著他的個人便攜電腦，不管他是去上班、還是回家、去本地咖啡店等等，我們都能很容易的監控到他。內部IP地址也增加了隱私風險，因為用它可以繪制出遠程網絡的IP地址圖，這些人的電腦在默默地報告他們的位置，想象一下下面這樣的圖片就有可能是以這些數據為基礎：

不用多說，這種隱私問題肯定會讓人有所觸動。

有道德的處理研究數據

出于對當事人隱私的尊重，我們在這次研究中收集的數據將不會被公開，并會安全的刪除。此外，所有這些計算機的進一步流量都會被路由到127.0.53.53，以確保在我maestro.gt域名剩下的注冊期限里(大約兩年)，沒有發送進一步的更新查詢。127.0.53.53這個IP是很特殊的，因為它是ICANN專門授權的用于提醒網絡管理員存在名稱碰撞問題的IP地址。希望危地馬拉的網絡管理員/技術精明的用戶看到DNS流量路由到這個IP后，他能搜索這個IP，并立即發現他們的網絡/活動目錄設置存在這個易受攻擊的問題。

此外，我已經給“.gt”頂級域名的DNS管理員發送了郵件，給她們通知了這個問題，并要求她修改主名稱服務器的設置，使它不再被解析。基于沒有人可以再利用這一點，并且我已經將流量引導到了127.0.53.53這個事實，同時我的域名注冊時間是兩年，因此，我決定發布這篇文章，盡管此時主名稱服務器仍然是maestro.gt。

總的來說這是一個非常有趣的實驗，強調即使是TLD的一個輕微配置錯誤，也可能造成一些有趣的后果。

狀態更新：在我將這個問題發送給危地馬拉的DNS管理員后，他們很快修復了這個問題(并很快進行了回復)。