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

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

 一個簡單的錯誤

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

當(dāng)我試圖ping內(nèi)部公司的服務(wù)器時，我得到了下面的回應(yīng)：

michael@seventysix:~ ping internal-db1.example.com 
PING 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 

當(dāng)然，結(jié)果顯示超時了。但注意一些事情：域名已經(jīng)被正確解析。即使我沒有登錄到VPN，我仍然可以解決內(nèi)部域名。為了確保這不是由于某個DNS緩存造成的，我嘗試從云集群中未曾登錄到公司網(wǎng)絡(luò)并使用不同名稱服務(wù)器的虛擬機中重現(xiàn)此操作，并得到了相同的結(jié)果。

為了理解這背后的事情為什么這么有趣，這里有一些關(guān)于IP地址和DNS的背景知識。

 內(nèi)部，外部IP和DNS

IPv4和IPv6地址空間分為私有和公有IP。以下網(wǎng)絡(luò)是私有的：

• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16
• FC00 :: / 7

例如，在你的家庭網(wǎng)絡(luò)或公司內(nèi)部網(wǎng)絡(luò)中使用專用IP。如果你在內(nèi)部網(wǎng)絡(luò)中處理公司服務(wù)器，他們通常具有上述范圍內(nèi)的IP。

為了連接名稱服務(wù)器和IP地址，我們使用DNS（域名服務(wù)）。DNS服務(wù)器（或“域名服務(wù)器”）是將域名example.com翻譯成IP的服務(wù)器。老知識，到目前為止，你很可能知道這一點。內(nèi)部公司網(wǎng)絡(luò)中使用的是同樣的東西：你不必記住10.0.0.1內(nèi)部數(shù)據(jù)庫服務(wù)器的IP，而是使用DNS將域名internal-db1.example.com 翻譯成私有IP，例如10.0.0.1。因此，當(dāng)你的普通Windows桌面客戶端嘗試連接到數(shù)據(jù)庫服務(wù)器時，它會要求DNS服務(wù)器將該域名解析為internal-db1.example.com可以與之通信的IP。（如果你想了解更多關(guān)于DNS的信息，我鼓勵你從偉大的互聯(lián)網(wǎng)上觀看這個漂亮，簡潔的視頻 —— 那個人不是我哦:)

https://youtu.be/4ZtFk2dtqv0

在一些公司中，管理內(nèi)部IP的域名的同一DNS服務(wù)器同時也管理著其公共IP的域名，例如他們網(wǎng)站的域名。請求“誰是www.example.com”和“誰是internal-db1.example.com”，都是從同一個DNS服務(wù)器 —— 即公司的DNS服務(wù)器來問詢ns1.example.com。這就是我剛才遇到的那種情況，ns1.example.com是為解決內(nèi)部和 外部IP 而設(shè)立的名稱服務(wù)器。只是這臺名稱服務(wù)器不在乎請求解析域名的IP地址是來自公司的內(nèi)部網(wǎng)絡(luò)還是外部，所以它響應(yīng)了我的請求。

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

響應(yīng)：

<= "Hey, it's 10.0.0.1", 

不用擔(dān)心它是通過內(nèi)部地址來響應(yīng)來自公司網(wǎng)絡(luò)之外的DNS請求。

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

· www.example.com。

內(nèi)部數(shù)據(jù)庫服務(wù)器被命名為：

· internal-db1.example.com。

在ping internal-db1.example.com時，我并沒有明確地查詢這個公司的DNS，因為我家的DNS被設(shè)置為使用不同的DNS（假設(shè)它是Google的DNS）。由于DNS具有分布式結(jié)構(gòu)，如果Google的DNS想要獲取www.example.com的IP ，它首先會要求其中一個根DNS服務(wù)器負責(zé)跟蹤誰負責(zé)第二級域名example.com。已聯(lián)系的根服務(wù)器會使用域名ns1.example.com的IP作為域名example.com的授權(quán)服務(wù)器來響應(yīng)Google的DNS 。然后谷歌的DNS請求ns1.example.com解析internal-db1.example.com并收到它最終轉(zhuǎn)給我們的響應(yīng)也就是我們上面看到的內(nèi)部IP。如果有內(nèi)部域名internal-db1.example.local，Google的DNS就不會知道是誰要求頂級域名（.local），因為注冊的公司example.com沒有注冊（也不能）example.local。

想一想：在這一點上，Google的DNS知道公司的內(nèi)部域名和相應(yīng)的IP。而互聯(lián)網(wǎng)上查詢的其他所有DNS服務(wù)器internal-db1.example.com都會知道同樣的事情。乍一看并不是什么大不了的事情，但是作為一個試圖保護這個基礎(chǔ)設(shè)施的人，我希望你們?nèi)匀荒軌蛎靼走@一點。

 一個小的信息泄漏

顯然，我現(xiàn)在可以通過詢問任何公共DNS來解析公司的內(nèi)部域名。更讓人感興趣的是許多公司都可以用來枚舉服務(wù)器：

db1-internal.company.com 
db2-internal.company.com 
db3-internal.company.com 

等等 - 這意味著如果你知道一個服務(wù)器的名稱，那么你可以猜測其他服務(wù)器的名稱。當(dāng)然，你也可以嘗試爆破域名名稱，也許是dev-internal.company.com或log-internal.company.com。這里的泄露信息的問題在于，你可以爆破內(nèi)部域名，并檢查公司網(wǎng)絡(luò)中是否有這些名稱的機器，檢索內(nèi)部IP 而不登錄到網(wǎng)絡(luò)。但是，你仍然需要暴力域名名稱。（是的，有工具可以做到這一點。）

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

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

4.3.2.1.in-addr.arpa.net 

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

當(dāng)你“擁有”一個IP 1.2.3.4（意味著它是在IANA注冊的）時，你可以為相應(yīng)的域名指定一個權(quán)威的域名服務(wù)器，4.3.2.1.in-addr.arpa.net并且在該域名服務(wù)器上配置一條PTR記錄，該記錄指向一個指定的域名。如果有人試圖反向解析1.2.3.4，他會被重定向到你的域名服務(wù)器并尋找PTR條目。（即使將多個域名連接到相同的服務(wù)器，你也只能將一個域名附加到IP地址。）

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

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

但是 - 如果我直接聯(lián)系公司的域名服務(wù)器，詢問能否為我解析1.0.0.10.in-addr.arpa.net，那么這時會發(fā)生什么？在這之間沒有谷歌DNS是不知道該怎么做的。盡管這樣做是沒有意義的，但是盡管不能在IANA上注冊私有IP，但是這不會阻止DNS管理員會在他的服務(wù)器上自己配置反向解析，對吧?

該公司的名稱服務(wù)器并沒有讓人失望：

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 ”部分了嗎？沒錯。我們通過公司的域名服務(wù)器來解析內(nèi)部IP?，F(xiàn)在事情變得非常有趣，因為沒有什么能阻止我迭代枚舉整個私有的IPv4地址空間，通過外部可訪問的DNS服務(wù)器從網(wǎng)絡(luò)外部來解決公司網(wǎng)絡(luò)的每個IP地址。這是最純粹的樂趣。

自動化所有的東西

我現(xiàn)在所需要的是一個腳本，它可以遍歷私有IP地址空間，來獲取該公司的所有內(nèi)部域名和IP地址。由于配置不當(dāng)?shù)腄NS，導(dǎo)致了一個簡單而又簡單的信息泄漏。(后來有人告訴我，DNS實際上并不是“錯誤配置”的，但這完全是為了克服一些VPN DNS解析問題。要真正獲得這種反向IP地址解析，通常需要設(shè)置一個適當(dāng)?shù)膠onefile，這意味著必須顯式地配置它，來反向解析內(nèi)部IP。無論如何，至少在幾個小時后，本文中這個反向解析的問題已經(jīng)被修復(fù)了。)

在發(fā)現(xiàn)了這個缺陷之后，我也很想知道它有多普遍，以及有多少DNS管理員應(yīng)用了類似的配置。我編寫了一個python腳本，用于對給定的名稱服務(wù)器的每個私有網(wǎng)絡(luò)范圍的前15個主機進行反向查詢，并開始對域名服務(wù)器進行掃描。使用masscan發(fā)生了一些麻煩，處理了麻煩之后 (最終效果很好)，我從Shodan下載了大約20.000 DNS服務(wù)器的列表，并在周末進行了檢查。這些結(jié)果并不引人注目，但也有一些有趣的結(jié)果。我通知了一些受影響的公司，但也發(fā)現(xiàn)了一些私有的路由器(大多是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上找到這個腳本。畢竟，這只是一個信息泄露，而我所看到的并不是太常見。據(jù)我所知，它還需要一個特定的DNS配置。

privdns.py 

就是這樣。這是一個關(guān)于如何在一個公司的DNS中解析私有IP地址時，泄露他們的基礎(chǔ)設(shè)施和IP的故事，并且沒有特別的復(fù)雜的黑客攻擊和利用技術(shù)。