小心DNS服務泄露了你的內網基礎設施

Tl; dr：有些域名名稱伺服器可能會在直接查詢反向解析私有IP時暴露內部的IP地址和域名。用dig -x檢查一下，或者使用privdns.py 檢查一下。

一個簡單的錯誤

我最近犯了一個很小且看似不重要的錯誤：我試圖連接某個公司的基礎設施的伺服器，但沒有登錄到他們的VPN。這看起來很無聊，你可能會覺得，這樣的事情每天都在發生。但幾個小時後，我正在編寫Python代碼，並且在大量掃描互聯網上的DNS伺服器。即使我最終沒有取得成功（從安全的角度來看這是很好的結果），但這仍然是一個有趣的實驗。那麼到底發生了什麼事。

當我試圖ping內部公司的伺服器時，我得到了下面的回應：

michael@seventysix:~ ping internal-db1.example.comPING internal-db1.example.com (10.0.0.1) 56(84) bytes of data.^C--- internal-db1.example.com ping statistics ---3 packets transmitted, 0 received, 100% packet loss, time 2014ms

當然，結果顯示超時了。但注意一些事情：域名已經被正確解析。即使我沒有登錄到VPN，我仍然可以解決內部域名。為了確保這不是由於某個DNS緩存造成的，我嘗試從雲集群中未曾登錄到公司網路並使用不同名稱伺服器的虛擬機中重現此操作，並得到了相同的結果。

為了理解這背後的事情為什麼這麼有趣，這裡有一些關於IP地址和DNS的背景知識。

內部，外部IP和DNS

IPv4和IPv6地址空間分為私有和公有IP。以下網路是私有的：

· 10.0.0.0/8

· 172.16.0.0/12

· 192.168.0.0/16

· FC00 :: / 7

例如，在你的家庭網路或公司內部網路中使用專用IP。如果你在內部網路中處理公司伺服器，他們通常具有上述範圍內的IP。

為了連接名稱伺服器和IP地址，我們使用DNS（域名服務）。DNS伺服器（或「域名伺服器」）是將域名http://example.com翻譯成IP的伺服器。老知識，到目前為止，你很可能知道這一點。內部公司網路中使用的是同樣的東西：你不必記住10.0.0.1內部資料庫伺服器的IP，而是使用DNS將域名http://internal-db1.example.com 翻譯成私有IP，例如10.0.0.1。因此，當你的普通Windows桌面客戶端嘗試連接到資料庫伺服器時，它會要求DNS伺服器將該域名解析為http://internal-db1.example.com可以與之通信的IP。（如果你想了解更多關於DNS的信息，我鼓勵你從偉大的互聯網上觀看這個漂亮，簡潔的視頻 —— 那個人不是我哦:)

https://youtu.be/4ZtFk2dtqv0

在一些公司中，管理內部IP的域名的同一DNS伺服器同時也管理著其公共IP的域名，例如他們網站的域名。請求「誰是www.example.com」和「誰是internal-db1.example.com」，都是從同一個DNS伺服器 —— 即公司的DNS伺服器來問詢http://ns1.example.com。這就是我剛才遇到的那種情況，http://ns1.example.com是為解決內部和 外部IP 而設立的名稱伺服器。只是這台名稱伺服器不在乎請求解析域名的IP地址是來自公司的內部網路還是外部，所以它響應了我的請求。

=> "Who is internal-db1.example.com"?

響應：

<= "Hey, its 10.0.0.1",

不用擔心它是通過內部地址來響應來自公司網路之外的DNS請求。

使這一事件成為可能的另一個要求是該公司使用了相同的域名來服務內部和外部。假設他們的網站被命名為：

· http://www.example.com。

內部資料庫伺服器被命名為：

· http://internal-db1.example.com。

在ping http://internal-db1.example.com時，我並沒有明確地查詢這個公司的DNS，因為我家的DNS被設置為使用不同的DNS（假設它是Google的DNS）。由於DNS具有分散式結構，如果Google的DNS想要獲取www.example.com的IP ，它首先會要求其中一個根DNS伺服器負責跟蹤誰負責第二級域名example.com。已聯繫的根伺服器會使用域名ns1.example.com的IP作為域名example.com的授權伺服器來響應Google的DNS 。然後谷歌的DNS請求ns1.example.com解析internal-db1.example.com並收到它最終轉給我們的響應也就是我們上面看到的內部IP。如果有內部域名internal-db1.example.local，Google的DNS就不會知道是誰要求頂級域名（.local），因為註冊的公司example.com沒有註冊（也不能）example.local。

想一想：在這一點上，Google的DNS知道公司的內部域名和相應的IP。而互聯網上查詢的其他所有DNS伺服器http://internal-db1.example.com都會知道同樣的事情。乍一看並不是什麼大不了的事情，但是作為一個試圖保護這個基礎設施的人，我希望你們仍然能夠明白這一點。

一個小的信息泄漏

顯然，我現在可以通過詢問任何公共DNS來解析公司的內部域名。更讓人感興趣的是許多公司都可以用來枚舉伺服器：

· http://db1-internal.company.com

· http://db2-internal.company.com

· http://db3-internal.company.com

等等 – 這意味著如果你知道一個伺服器的名稱，那麼你可以猜測其他伺服器的名稱。當然，你也可以嘗試爆破域名名稱，也許是http://dev-internal.company.com或http://log-internal.company.com。這裡的泄露信息的問題在於，你可以爆破內部域名，並檢查公司網路中是否有這些名稱的機器，檢索內部IP 而不登錄到網路。但是，你仍然需要暴力域名名稱。（是的，有工具可以做到這一點。）

一個更嚴重的信息泄漏問題

如果你對網路，IP和DNS有所了解，你可能會猜測我的下一步是什麼。許多人基本上知道DNS是如何工作的。人們所知道的是，你不僅可以將一個域名解析為一個IP地址，而且還可以反過來：給定一個IP地址，你可以將其解析為一個域名。與正向DNS相反，這被稱為反向解析或反向DNS，並且通過查詢特定ARPA域的PTR記錄的DNS來完成。如果你想反向解析一個給定的IP，你必須扭轉IP地址，並添加一個特殊的域名，比如http://in-addr.arpa.net域名。例如，為了解析IP 1.2.3.4對應的域名，你需要要求你的名稱伺服器尋找一條記錄是

4.3.2.1.in-addr.arpa.net

的PTR類型（與正向解析域名時的類A 的IPv4 或類型為AAAA的IPv6地址相比）。

當你「擁有」一個IP 1.2.3.4（意味著它是在IANA註冊的）時，你可以為相應的域名指定一個權威的域名伺服器，http://4.3.2.1.in-addr.arpa.net並且在該域名伺服器上配置一條PTR記錄，該記錄指向一個指定的域名。如果有人試圖反向解析1.2.3.4，他會被重定向到你的域名伺服器並尋找PTR條目。（即使將多個域名連接到相同的伺服器，你也只能將一個域名附加到IP地址。）

所以回到公司的域名http://example.com上來。如果我不僅能得到一個域名的IP地址，而且可以相反的操作，那麼有沒有辦法來檢查一個內部IP地址是否有一個域名與之相關聯呢？我可以只對私有IP空間進行反向查詢嗎？這會讓事情變得更有趣。如果可能的話，我可以簡單地開始迭代枚舉私有IP空間，檢查每個IP是否有註冊的PTR記錄，通過這種方式可以獲得大量有關公司內部網路的信息 -——IP地址，域名以及我可以從中得到的所有信息。

由於DNS的結構，簡單地反向解析IP是不起作用的：反向解析意味著你的默認域名伺服器（例如Google）需要尋找到http://1.0.0.10.in-addr.arpa.net的內部IP地址。由於沒有人可以擁有該IP並將其域名伺服器指定為權威伺服器，因此IANA不允許你在此處輸入條目，因此Google的DNS將無法處理該IP的反向DNS查詢，因為它使用http://company.com是做不到的。它不會像在域名解析的情況下那樣嘗試聯繫我們公司的DNS，因為它不知道我們公司的DNS將自己視為了這個內部IP的權威伺服器。

但是 – 如果我直接聯繫公司的域名伺服器，詢問能否為我解析http://1.0.0.10.in-addr.arpa.net，那麼這時會發生什麼？在這之間沒有谷歌DNS是不知道該怎麼做的。儘管這樣做是沒有意義的，但是儘管不能在IANA上註冊私有IP，但是這不會阻止DNS管理員會在他的伺服器上自己配置反向解析，對吧?

該公司的名稱伺服器並沒有讓人失望：

michael@seventysix:~ dig -x 10.0.0.1 @ns1.example.com; <<>> DiG 9.10.3-P4-Ubuntu <<>> -x 10.0.0.1 @ns1.example.com;; global options: +cmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6077;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1;; WARNING: recursion requested but not available;; OPT PSEUDOSECTION:; EDNS: version: 0, flags:; udp: 4096;; QUESTION SECTION:;1.0.0.10.in-addr.arpa. IN PTR;; ANSWER SECTION:1.0.0.10.in-addr.arpa. 3600 IN PTR internal-db1.example.com.;; Query time: 16 msec;; SERVER: XXX.XXX.XXX.XXX#53(XXX.XXX.XXX.XXX);; WHEN: Wed Jan 21 14:37:49 CET 2018;; MSG SIZE rcvd: 110

你看到那個美麗的「ANSWER 」部分了嗎？沒錯。我們通過公司的域名伺服器來解析內部IP。現在事情變得非常有趣，因為沒有什麼能阻止我迭代枚舉整個私有的IPv4地址空間，通過外部可訪問的DNS伺服器從網路外部來解決公司網路的每個IP地址。這是最純粹的樂趣。

自動化所有的東西

我現在所需要的是一個腳本，它可以遍歷私有IP地址空間，來獲取該公司的所有內部域名和IP地址。由於配置不當的DNS，導致了一個簡單而又簡單的信息泄漏。(後來有人告訴我，DNS實際上並不是「錯誤配置」的，但這完全是為了克服一些VPN DNS解析問題。要真正獲得這種反向IP地址解析，通常需要設置一個適當的zonefile，這意味著必須顯式地配置它，來反向解析內部IP。無論如何，至少在幾個小時後，本文中這個反向解析的問題已經被修復了。)

在發現了這個缺陷之後，我也很想知道它有多普遍，以及有多少DNS管理員應用了類似的配置。我編寫了一個python腳本，用於對給定的名稱伺服器的每個私有網路範圍的前15個主機進行反向查詢，並開始對域名伺服器進行掃描。使用masscan發生了一些麻煩，處理了麻煩之後 (最終效果很好)，我從Shodan下載了大約20.000 DNS伺服器的列表，並在周末進行了檢查。這些結果並不引人注目，但也有一些有趣的結果。我通知了一些受影響的公司，但也發現了一些私有的路由器(大多是Broadcom)，這些公司透露了諸如「邁克爾的iPhone」或惠普印表機、亞馬遜之類的名稱。

michael@seventysix ~/privdns % ./privdns.py XXX.XXX.XXX.XXX 10.0.0.0/8[*] Checking nameserver XXX.XXX.XXX.XXX[+] 10.0.0.1 : E***.net.[+] 10.0.0.2 : P***.net.[+] 10.0.0.3 : A***.net.[+] 10.0.0.4 : A***.net.[+] 10.0.0.5 : E***.net.[+] 10.0.0.6 : E***.net.[+] 10.0.0.7 : P***.net.[+] 10.0.0.8 : P***.net.[+] 10.0.0.9 : E***.net.[+] 10.0.0.10 : P***.net.[+] 10.0.0.11 : a***.net.[.] Resolved but no entry for 10.0.0.12...

如果你想自己玩的話，你可以在我的GitHub上找到這個腳本。畢竟，這只是一個信息泄露，而我所看到的並不是太常見。據我所知，它還需要一個特定的DNS配置。

privdns.py

就是這樣。這是一個關於如何在一個公司的DNS中解析私有IP地址時，泄露他們的基礎設施和IP的故事，並且沒有特別的複雜的黑客攻擊和利用技術。

本文翻譯自：https://codemetrix.net/when-your-dns-leaks-your-infrastructure/ ，如若轉載，請註明原文地址： http://www.4hou.com/system/10239.html 更多內容請關注「嘶吼專業版」——Pro4hou

推薦閱讀：