MassDNS：跨域DNS枚舉工具
譯文【51CTO.com快譯】
一、使用MassDNS
唯一大量枚舉跨域的工具。
TLDR
MassDNS可以在幾秒鐘內可靠地解析100K子域，可以使用AltDNS的功能，并為用戶提供超過超乎想象的結果。可以使用它來連續暴力破解大量的域名。
譯者注：AltDNS - 通過更改和排列進行子域發現，AltDNSs是一種DNS偵察工具，允許發現符合模式的子域名。AltDNS接受可能存在于域下的子域中的單詞(例如測試，開發，分期)，以及獲取您知道的子域列表。工具傳送門：https://github.com/infosec-au/altdns
二、靈感
進攻安全的第一步是偵察。獲取目標的全部范圍是偵查階段的目標。主要是，這篇文章將重點放在如何有效地發現子域名，在大量的目標中使用MassDNS。此外，關于這個空白我已經研究了很長一段時間，并沒有找到一個運行在許多目標上的比較好的工具。
三、工具
有很多腳本和程序可以處理子域名枚舉。我將主要討論以下工具(我基于他們的受歡迎程度來選擇)：
- Passive sources(https://github.com/rondilley/passivedns)
- Subbrute(https://github.com/TheRook/subbrute)
- Sublist3r(https://github.com/aboul3la/Sublist3r)
- Enumall(https://github.com/jhaddix/domain)
- Brutesubs(https://github.com/anshumanbh/brutesubs)
- DNS-Parallel-Prober(https://github.com/lorenzog/dns-parallel-prober)
1. Passive sources
我想手動處理被動源，因為我已經有一個自動化框架，很難將其集成到預構建的工具中。被動來源是可以的，但是他們永遠不會暴力破解一樣好。原因很簡單：如果它是被動來源，它已經在別處找到并被索引了。然而，如果你是暴力破解的話，就有一定的幾率導致一些被動渠道沒有選擇這些子域名。
在我看來，被動來源永遠都是有益于，你得到你的子域，但不應該是主要來源，這使得我們使用其他工具。
2. Subbrute
許多人都知道如何利用一個經過很長時間測試的工具。在我看來，該工具的最大特點是內置的遞歸，檢查子域中的子域。當我為每個公開范圍漏洞獎勵目標啟動子域枚舉時，我首先選擇了這個工具。
當您有很多域要掃描時，時間和可靠性是一個工具擁有的最重要的功能。當我嘗試將Subbrute整合到我的進程中時，我發現了一些事情：
- 運行很多次
- 腳本不會停止
- 遞延延長運行時間
列出了大約100K子域名，使用超過15分鐘才完成了單個域的掃描。由于完成掃描所需的時間，您的自動化忽略了其它域名，這里新的子域名可能剛剛出現。當Subbrute運行時，我有點想阻止這個運行在我的被動模塊中。這樣一來，當域被掃描時，我會從其它域名中獲取被動DNS信息。
在漏洞獎勵挖掘中，在其他人之前找到易受攻擊的服務是非常重要的，而Subbrute完成任務所需的時間成本對我來說太高了(我的機器)。另外，當跑完我所有的目標時，Subbrute會偶爾掛起。這使得偵測的結束是一場噩夢，最終有太多的工作需要跟上，我開始尋找其他的工具。
3. Sublist3r
Sublist3r更側重于被動來源信息收集。這些被動源通常提供一個API，使用戶的搜索變得更加容易。然而，對他們往往有速率限制，使許多領域的自動化困擾。很多時候，源會阻止我的實例的IP地址，因為請求數量(可以理解)。
注意Sublist3r可以為您運行Subbrute，但由于上述原因我不會建議。此外，Sublist3r必須在目標上運行，然后依次運行Subbrute，從而增加每個域的運行時間。
因此，我創建了一個腳本來為域運行Sublist3r，然后單獨為一個域運行Subbrute。這樣，一旦其中一個進程完成，它就可以開始在另一個域上運行，從而提高了自動化的效率。這種方法在正確的軌道上，非常類似于我如何手動處理Subbrute和被動源。主要的缺點是完成掃描的時間。
4. Enumall
Enumall依靠Recon-NG(https://bitbucket.org/LaNMaSteR53/recon-ng)進行被動信息收集和暴力破解。Enumall是一個方便的小腳本，我認為它以聰明的一種方式利用多種其他工具來完成任務。通過使用Recon-NG來發現主機，它將自動將您列舉的子域存儲在其內置的表中。
但是，為了能在多個域中運行并且效率高，對我來說是不可能的。Recon-NG將按順序運行每個測試，嚴重影響其性能。
另外，由于它將在工作空間中創建表，我遇到了內存問題($ 20在box中)。完成運行后，我必須刪除域的每個工作區，然后為下一個域創建一個新的工作區。如果有一個大的域，它會導致我的實例耗盡內存。
由于這些原因，我無法使用枚舉。
5. Brutesubs
另一個運行一些其他提及工具的工具。就個人而言，我沒有玩的特別好，作為枚舉子域名的簡單方法而獲得青睞。
6. DNS-Parallel-Prober
在這個時候，它是無限的，但可能是MassDNS的競爭對手。沒有使用它，但可能值得研究，如果MassDNS導致你太多的麻煩。
工具地址：https://github.com/blechschmidt/massdns
四、絕望
在這一點上我沒有希望。在有效性方面，我認為被動來源和Subbrute是最好的方法。但是，我不想創建處理容錯程序的維護。正是在這一點上，我遇到了MassDNS，我的救世主 。
優點(你也可以認為我是一個“托”)
認真地運行MassDNS。如果我遇到這個工具，我將節省大量的時間，將其他子域暴力破解應用程序并入。
首先，可靠性和速度是無與倫比的。100K子域在10秒以內暴力破解。以前，如果我很幸運，許多子域名，僅僅需要5-10分鐘。我連續運行2-3個月，在可靠性方面本身并沒有遇到任何問題。
以前，我通過Subbrute收集子域名，并利用我的腳本來解析被動源。之后，我沒有想到會發現很多子域名，但是運行MassDNS時使用大字典，它給了我太多子域來調查每個子域。(提示：有些人正在使用EyeWitness：https://github.com/ChrisTruncer/EyeWitness，我想知道為什么?)
此外，對我來說，似乎AltDNS被創建用于此工具(即使AltDNS包含一種解決域本身的方式)。AltDNS將創建一個字典，您可以將其添加到MassDNS中，以便為您解決問題。這是偉大的，因為當你有一個域下面有很多子域和一個大的前綴列表，排列列表是巨大的。到目前為止，我還沒有找到比MassDNS更快的DNS解析器。
最后，解析輸出效率。如果允許它輸出，MassDNS絕對是啰嗦的。無論響應如何，您絕對不會缺少大多數記錄的關鍵輸出。這一點在下面的缺點中得到了擴展。
除此之外，我認為大多數(數據)賞金獵人都在使用MassDNS，但顯然這不是我可以肯定的一點。
五、缺點
我還沒有討論MassDNS有一個主要的缺點：它是一個非常簡單的工具，具有復雜的輸出。
所討論的其他許多工具都提供了一個方便使用的界面和易于理解的輸出。不過，您只需要看看Frans Rosen在AppSec歐盟的演講，在那里他解決了其他工具有，而MassDNS沒有的問題(https://www.youtube.com/watch?v=FXCzdWm2qDg)。MassDNS不會保留其他工具所做的信息。例如，如果沒有找到子域，許多工具將不會顯示(因為它是NXDOMAIN)。但是，Frans顯示，這里有一個CNAME沒有一個子域的A記錄。使用該host命令將返回NXDOMAIN，因為它找不到CNAME的地址。但是，如果有人注冊了CNAME，則會有一個A地址。一些工具錯過了這一點，所以接收被忽略了。但是，MassDNS不會隱藏信息(除非您提供標志)。
下一個缺點是解析器。
為了加快枚舉，MassDNS會為每個主機聯系多個解析器。這樣一個DNS服務器不會減慢進程，您可以有效地擴展枚舉(Subbrute也是這樣)。但是，有時候還有錯誤的解析。
錯誤的解析器返回舊的和過期的記錄(或只是錯誤的)。因為一些不存在的子域名信息，你會疼恨，這嚴重妨礙了您的枚舉。
解決這個問題的一種方法是解析“找到”的子域，然后使用Google的DNS(8.8.8.8)來解析每個域。如果Google沒有解決，我可以從解析器列表中刪除返回該記錄的原始DNS服務器。這樣，我已經刪除了大多數的壞解決方案，給我留下了好的結果。
然而這里CPU吃緊。每次我運行這個，我花$20沒有做的盒子，每次運行都讓我心靈很受傷!但是，結果非常好，所以我可以用它(并考慮一個更強大的盒子來支持它)。
最后，MassDNS 要求用戶解析其輸出。這意味著對于自動化系統，必須創建一個腳本來從輸出中提取有意義的信息。需要基本的腳本/編程知識才能獲得良好的自動化和覆蓋。
最后的想法
總的來說，為了使用MassDNS提供的信息，您必須編寫一個腳本來解析它，并與輸出結果進行交互。在我看來，這是每個人使用MassDNS的最大障礙。有了這個說法，如果你具備足夠的編程能力來解析輸出并將其傳遞到自動化中，那么，你將有一個很好的子域枚舉過程。嘗試一下，與以前的枚舉方法進行比較，考慮結果，可靠性和速度。
原文標題：Offensive Security by Automation
【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】
