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

新聞 02-06

反向解析公共IP - 這裡沒有問題

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

一個簡單的錯誤

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

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

michael@seventysix:~ ping internal-db1.example.com

PING internal-db1.example.com (10.0.0.1) 56(84) bytes of data.

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

https://youtu.be/4ZtFk2dtqv0

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

響應：

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

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

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

· internal-db1.example.com。

在ping 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伺服器internal-db1.example.com都會知道同樣的事情。乍一看並不是什麼大不了的事情，但是作為一個試圖保護這個基礎設施的人，我希望你們仍然能夠明白這一點。

一個小的信息泄漏

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

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

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

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

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

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

;; OPT PSEUDOSECTION:; EDNS: version: 0, flags:; udp: 4096;; QUESTION SECTION:;1.0.0.10.in-addr.arpa.INPTR

;; ANSWER SECTION:1.0.0.10.in-addr.arpa.3600INPTRinternal-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.