反向解析公共IP- 這里沒(méi)有問(wèn)題

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

 一個(gè)簡(jiǎn)單的錯(cuò)誤

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

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

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

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

https://youtu.be/4ZtFk2dtqv0

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

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

響應(yīng)：

<= "Hey, it's 10.0.0.1", 

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

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

· www.example.com。

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

· internal-db1.example.com。

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

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

 一個(gè)小的信息泄漏

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

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

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

 一個(gè)更嚴(yán)重的信息泄漏問(wèn)題

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

4.3.2.1.in-addr.arpa.net 

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

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

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

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

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

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

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 

你看到那個(gè)美麗的“ANSWER ”部分了嗎？沒(méi)錯(cuò)。我們通過(guò)公司的域名服務(wù)器來(lái)解析內(nèi)部IP?，F(xiàn)在事情變得非常有趣，因?yàn)闆](méi)有什么能阻止我迭代枚舉整個(gè)私有的IPv4地址空間，通過(guò)外部可訪問(wèn)的DNS服務(wù)器從網(wǎng)絡(luò)外部來(lái)解決公司網(wǎng)絡(luò)的每個(gè)IP地址。這是最純粹的樂(lè)趣。

自動(dòng)化所有的東西

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

在發(fā)現(xiàn)了這個(gè)缺陷之后，我也很想知道它有多普遍，以及有多少DNS管理員應(yīng)用了類似的配置。我編寫(xiě)了一個(gè)python腳本，用于對(duì)給定的名稱服務(wù)器的每個(gè)私有網(wǎng)絡(luò)范圍的前15個(gè)主機(jī)進(jìn)行反向查詢，并開(kāi)始對(duì)域名服務(wù)器進(jìn)行掃描。使用masscan發(fā)生了一些麻煩，處理了麻煩之后 (最終效果很好)，我從Shodan下載了大約20.000 DNS服務(wù)器的列表，并在周末進(jìn)行了檢查。這些結(jié)果并不引人注目，但也有一些有趣的結(jié)果。我通知了一些受影響的公司，但也發(fā)現(xiàn)了一些私有的路由器(大多是Broadcom)，這些公司透露了諸如“邁克爾的iPhone”或惠普打印機(jī)、亞馬遜之類的名稱。

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上找到這個(gè)腳本。畢竟，這只是一個(gè)信息泄露，而我所看到的并不是太常見(jiàn)。據(jù)我所知，它還需要一個(gè)特定的DNS配置。

privdns.py 

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