未經授權，侵刪。
2017年6月4日
凡聽見我這話就去做的，好比一個聰明人，把房子蓋在磐石上。雨淋、水沖、風吹，撞著那房子，房子總不倒塌；因為根基立在磐石上。凡聽見我這話不去做的，好比一個無知的人，把房子蓋在沙土上。雨淋、水沖、風吹，撞著那房子，房子就倒塌了。
--馬太福音7章24-27節
域名是我們當代互聯網的根基，然而盡管所有人都在使用卻很少有人理解他背后的機制。因為現在有各種抽象中間層以及供應商提供的服務，大部分人都能在不知道什么是DNS、域名注冊和WHOIS的情況下搭建自己的網站并擁有自己的域名。雖然這些抽象中間層非常有用，但是它也為最終的使用者屏蔽了很多重要的信息。舉個例子，很多域名注冊的網站會更樂意向你推薦.io 的域名，但是買了.io 域名的人真的知道是哪些組織正在維護管理.io 域名嗎？我認為大部分買了域名的人對域名背后的運作所知甚少，更不要說有多少人會問“這個域名的安全追溯記錄是什么樣的？”。
DNS結構簡介
如果你已經了解DNS是如何運行和被代理的，可以直接跳過這節。
當你為域名掏錢時到底買到了什么呢？從本質上來說，你只是買到了一些NS (nameserver，域名服務器)記錄，這些記錄會被域名后綴對應的服務器（包括各種類似與WHOIS、registry/registrar operational costs, and other fees which go to ICANN）所持有。為了更好地理解后綴名在整個DNS各個階段中的位置，我們來看一副圖，上面標注了example.com的“代理鏈”。我發現圖表對于理解DNS運作方式有很大的好處，所以我寫了一個名叫TrustTrees的工具，它可以用來生成某個域名完整的代理路徑。
上圖展示了從根DNS服務開始的完整“代理鏈”，可見DNS代理的工作方式就是在連續的鏈路上尋找對應的域名是否存在。用戶在發起的DNS請求會從請求某一個根域名服務器開始。根節點可能不知道這個請求的結果，然后后會將這次請求通過代理的方式轉發給TLD（頂級域名服務器），而后者則會再次通過代理的方式轉發給和是的域名服務器，直到接收到“權威回答”并確認它來自正確的域名服務器。上圖戰士了所有可能的代理路徑（藍色的線代表了“權威回復”）。之所以會有這么多路徑，是因為DNS最終的回復中會包含一系列隨機排列的答案（稱之為 Round Robin DNS的技術），這么做是為了實現一定程度上的負載均衡。根據返回結果的順序，每次請求的可能會是不同的域名服務器，并得到一些不同的答案。上圖還展示了所有的排列可能以及域名服務器之間的聯系。
綜上所述，如果你購買了 example.com 域名，那么.com 注冊局將會增加一些NS記錄，然后所有關于example.com 的DNS請求都會被轉發到對應的域名服務器上。這些接受代理的域名服務器則是會真正控制example.com 域名以及生成其他子域名的地方。如果擁有 .com 的組織決定去掉相關的域名服務器（NS）記錄，那么你的域名請求將不會被代理給給任何服務器，進而你的example.com 就不能正常運作了。
進一步思考你會發現頂級域名服務器（TLD）和域名后綴之間的關系在其他域名層級的關系也是類似的。TLD存在的意義就是等待根域名服務器將請求代理給他們。如果根域名服務器決定去掉 .com 的NS記錄，那么世界上所有的.com結尾的域名都將無法解析。
和普通域名相同，域名后綴也會受到同樣漏洞的影響
現在我們理解了TLD和域名后綴也同樣是通過域名服務器來管理的，就像普通的域名一樣。那么問題來了，這意味著TLD也會受到同樣的DNS安全問題的影響嗎？答案當然是肯定的。如果你在我的博客里看過之前的一些文章，那么就可以知道我們可以通過各種方式劫持域名服務器。我演示過 過期或出錯的域名服務器可能導致被劫持（typo-ed還沒找到如何翻譯……），也看過很多DNS供應商可以無需驗證就獲得其控制權。在學習完上述滲透實例之后，我們就有了足夠的知識來做一件更偉大的事情：控制整個域名后綴。
拿下域名后綴之攻擊計劃
我并不是一個壞人，因此并不愿意教你們如何快速達到劫持域名后綴的目的。在整個尋找攻擊方法的研究過程中，我發現很多TLD級別的域名服務器以及注冊局都處于一團糟的狀態，所以獲取他們的控制權可能比想像的要簡單很多。盡管類似與在注冊局或者域名服務器上遠程執行惡意代碼這樣的策略并不在我們的考量范圍內，但是我仍然將提及他們，畢竟現實中的作惡者并沒有多少道德顧慮。
一般來說，下列幾個方法是拿下TLD相對可行的方法：
- 通過域名后綴所在的DNS 服務器的漏洞。攻擊注冊局也算是這種方法的范圍之內，因為它有能力可以直接操作對應域名服務器上的內容。
- 找到已經過時或者寫錯的域名服務，并且搶先注冊。
- 通過在域名提供商那里重新創建一個 DNS 區，以此來劫持域名后綴。
- 劫持TLD的WHOIS聯系郵箱（在 IANA root zone 數據庫中列出的這些）。
我們將逐一介紹每一種方法以及在實踐中發現的對應結果。
TLD和域名后綴服務器的漏洞其實相當常見
為了開始對第一種方法進行探索，我決定對一個TLD域名服務器做一個簡單的端口掃描。在理想狀況下你將看到一批服務器在53端口監聽著UDP/TCP消息，并且其他所有的端口都是關閉的。畢竟這些域名服務器十分關鍵，他們應該盡量減少對外的暴露。任何類似于HTTP，SSH或者SMTP都可能成為攻擊者進入TLD的方式。
這一章的內容可能會有點奇怪，因為我將介紹如果不對惡意的活動設防情況會有多糟糕。在調查過程中我甚至發現，某些TLD上竟然還運行著網站，這意味著他很可能有被入侵的入口。我們將忽略這些極端的例子，主要集中分析一些典型案例。
Finger
- 203.119.60.105 (e.dns-servers.vn): 越南的.vn TLD域名服務器
- 202.29.151.3 (munnari.oz.au): 波斯尼亞和黑塞哥維那的.ba TLD 域名服務器
finger 協議 是Les Earnestz 在1971年創建的，它可以讓用戶查看遠程電腦上某個用戶的狀態。這是一種超級過時的協議，現代的操作系統中基本不會支持。這個協議的想法實質上是為了回答“Dave現在在他的機子上登錄著嗎？他現在忙嗎？”這樣的問題。你可以通過finger協議來查看遠程機器上用戶的登錄名，真是姓名，終端名，空閑時間，登錄時間，辦公室地址和辦公室電話號碼。舉個例子，我們將訪問波斯尼亞的域名服務器的finger服務，查看他的root用戶的下列信息：
bash-3.2$ finger -l root@202.29.151.3
[202.29.151.3]
Login: root Name: Charlie Root
Directory: /root Shell: /bin/sh
Last login Sat Dec 14 16:41 2013 (ICT) on console
No Mail.
No Plan.
看上去root用戶已經很久沒有登錄了！讓我們再看看越南的某個域名服務器：
bash-3.2$ finger -l user@203.119.60.105
[203.119.60.105]
Login name: nobody In real life: NFS Anonymous Access User
Directory: /
Never logged in.
No unread mail
No Plan.
Login name: noaccess In real life: No Access User
Directory: /
Never logged in.
No unread mail
No Plan.
Login name: nobody4 In real life: SunOS 4.x NFS Anonymous Access User
Directory: /
Never logged in.
No unread mail
No Plan.
Login name: named In real life: User run named
Directory: /home/named Shell: /bin/false
Never logged in.
No unread mail
No Plan.
bash-3.2$
bash-3.2$ finger -l root@203.119.60.105
[203.119.60.105]
Login name: root In real life: Super-User
Directory: / Shell: /sbin/sh
Last login Tue Sep 30, 2014 on pts/1 from DNS-E
No unread mail
No Plan.
這邊root用戶的上一次登錄時間是2014年9月30號。實際上這機子上裝載這這種協議也表明了這服務器是有多過時了。
動態網站
可能除了53之外，域名服務器上最常見的公開端口應該就是80（HTTP）了。訪問他們的網站經常會獲得很有趣的結果。例如某個域名服務器直接將我重定向到一個廣告網站：
* Rebuilt URL to: http://93.190.140.242/
* Trying 93.190.140.242...
* Connected to 93.190.140.242 (93.190.140.242) port 80 (#0)
> GET / HTTP/1.1
> Host: 93.190.140.242
> Accept: */*
> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0
>
< HTTP/1.1 302 Moved Temporarily
< Server: nginx/1.10.1
< Date: Sun, 04 Jun 2017 03:16:30 GMT
< Content-Type: text/html
< Transfer-Encoding: chunked
< Connection: close
< X-Powered-By: PHP/5.3.3
< Location: http://n158adserv.com/ads?key=6c6004f94a84a1d702c2b8dc16052e50&ch=140.242
<
* Closing connection 0
我仍然不能確定，這個域名服務器是不是之前就已經被人入侵過，或者他的擁有者想以此賺點外快？
其他的域名服務器（例如阿爾巴尼亞的 .com.al ，.edu.al，.mil.al，.net.al,和.nic.al 的域名服務器）則返回了很多描述他們機器詳細信息的配置頁：
另外還有能在上面直接遠程執行命令行工具的（例如.ke，.ba 和其他一大把域名后綴）：
更有甚者……
我們還發現了其他很多有意思的服務，但這里就不詳細展開了。例如SMTP，IMAP，MySQL，SNMP，RDP都是域名服務器上常見的開放端口。這給了攻擊者一個很大的施展空間，我認為通過各種漏洞成功拿下服務器的成功路很高。但是我們將不再做進一步測試，因為我們不是壞人。由于很多服務器都已經過時了，修復上面的安全漏洞對于各個所有者來說工作量十分巨大。
……
PS：原文后面還有很多展開講述其他奇技淫巧來攻占頂級域名服務器，這里就先不翻譯了：）
