子域名接管安全性分析及落地化

能說只是為了學Go嘛？33333
Github專案直通車
原文連結

簡介

1. 子域名接管，主要原因歸結於失效dns記錄未刪除。

   譬如，一條指向test.sec.com的CNAME記錄未被刪除，而test.sec.com已被登出，這個時候，如果攻擊者如果註冊了該域名，那麼該子域名就會指向一個可控的主機或者域名上。

   CNAME記錄是最常被利用的，但其實A記錄，NS記錄等其他DNS記錄也存在被接管的可能。

2. 那麼子域名在實戰中又能發揮哪些作用？

   • 記得紅隊釣魚時有一個釣魚網站的操作，而往往為了更逼真，獲取更高的可信度，往往將域名設定為一個和原域名很相似的域名。而如果能直接接管子域名中的CNAME記錄，那豈不是很nice。所以子域名接管的利用主要就是為了高度偽造目標站點，提供高偽裝性。

   • 其他危害

DNS

DNS主要就是將好記得域名解析為不好記的IP地址

DNS檔案-RFC1034

DNS檔案2-RFC1035

從1034到1035新增了幾個記錄，當下共有16中DNS記錄，簡要介紹其中和當前分析有關的幾個記錄型別：

• A 記錄域名指向的主機ip
• NS 域名伺服器記錄，用來指定該域名由哪個DNS伺服器來進行解析
• CNAME 別名記錄，允許您將多個名字對映到同一臺計算機
• MX 郵件交換記錄，它指向一個郵件伺服器

DNS記錄與子域名接管

從上面幾個DNS記錄來看，如果是A記錄，由於ip的可控性很低，雖然也存在類似的服務，例如彈性公網ip申請之類的，所以暫不考慮A記錄的接管。而如果記錄是指向一個域名的話，則往往可控性更高，可利用性也就更高。

Subtaker專案

有了上面的知識，現在就開始落地化了。

專案需求

1. 判斷記錄是否被登出，可被重新申請註冊
2. 記錄指向是否間接可控，例如github page

設計思路

1. 讀取字典，遍歷子域名的CNAME,MX記錄
2. 對收集到的記錄進行分別判斷其是否可註冊
3. 繼續對CNAME記錄進行指紋識別，看是否為間接可控
4. 輸出結果

存在的問題或者關鍵點

• CNAME鏈解決(這裡也許有什麼CNAME->MX記錄，但實戰中存在的可能性較低，相反工具的效能降低，所以只對CNAME記錄鏈進行處理)
• 執行緒控制實現方法：採用了號誌+鎖的方式
• 高並行性的同時，怎麼確保域名查詢註冊介面進行有效反饋？隨機切換查詢API+狀態碼判斷
• 單個子域名對應多個記錄，go中的net解析時被當作CNAME記錄
• 奇奇怪怪的域名解析處理：CNAME解析最後一直返回同樣的記錄！MX記錄進行CNAME記錄查詢解析竟然也會返回CNAME記錄--》調換了MX記錄和CNAME記錄的判斷順序，但無疑會影響解析速度
• 部分頁面例如Github是屬於外網，存取速度很慢，或者乾脆不能存取，這直接影響結果的準確率--》你們懂的

https://github.com/EdOverflow/can-i-take-over-xyz，這個倉庫裡還有很多可間接接管的指紋，但由於不常見，沒有完全新增進去，感興趣，可以自己新增進去試試。

專案展示