Subdomain Takeover

發佈日期: 作者:

子域名接管（Subdomain Takeover）是一種攻擊技術，當子域名指向的資源（如雲端服務、託管服務等）已經被刪除或不再存在時，攻擊者可以利用這個機會接管該子域名。

攻擊方式

  1. DNS 設定錯誤或遺留：通常，子域名接管發生的原因是子域名在 DNS 設定中指向一個已經不再存在或不再使用的外部服務。例如，子域名 sub.example.com 可能指向一個被刪除的 Amazon S3 bucket 或者一個已經不再使用的應用程式。
  2. 發現未使用的子域名：攻擊者會掃描目標網站的子域名，尋找那些指向不存在資源的子域名。這些子域名可能會返回 404 錯誤或者其他類型的錯誤訊息，表明資源已經被移除。
  3. 註冊或創建資源：一旦攻擊者確定某個子域名指向的資源不存在，他們可以嘗試在相同的平台上創建一個新的資源，並配置該資源以使用目標子域名。例如，如果 sub.example.com 指向一個已刪除的 Amazon S3 bucket nonexistent-bucket，攻擊者可以創建一個名為 nonexistent-bucket 的新 S3 bucket。
  4. 接管子域名：由於 DNS 設定仍然指向該資源，攻擊者創建的新資源會自動綁定到這個子域名。這樣，當用戶訪問 sub.example.com 時，實際上會訪問攻擊者控制的資源。
  5. 利用接管的子域名：攻擊者可以利用被接管的子域名進行多種惡意活動，例如發布釣魚網站、注入惡意代碼、進行社交工程攻擊等。

攻擊架構可參考下圖

refer:
https://0x3zzat.medium.com/subdomain-takeover-vulnerability-and-how-to-find-it-using-a-simple-technique-c359c34960ea

情境

Amazon S3 是一個雲端儲存服務，你可以把檔案上傳上去，然後設定誰可以存取。很多人會用 S3 來放圖片或是整個網站，因為它也可以用來託管網站。S3 的每個儲存空間叫做 bucket，每個 bucket 都有自己的名稱，這個名稱對應到一個網址。

舉例來說，如果我的 bucket 叫做 systw，那它的網址就是 https://systw.s3.us-east-1.amazonaws.com。S3 很方便，所以很多公司會把前端網站放在上面，尤其是靜態網站，這樣就不用自己管理伺服器了。

不過，這個網址看起來不夠漂亮。公司通常會想要用自己的網域名稱來取代，S3 也有提供這個功能，而且設定很簡單。所以會先把 bucket 名稱改成你想要的網域名稱，比如 school.systw.net。接著，在你的 DNS 設定裡，新增一個 CNAME 記錄，將 school.systw.net 指向 systw.s3.us-east-1.amazonaws.com，這樣就可以使用自己的網域 https://school.systw.net 來訪問網站了。

產生安全問題的原因主要因為2個事情 ：

第一，當你不再需要這個網站時，並刪掉 S3 bucket時。但是DNS 記錄沒有刪，因為管理 DNS 設定的可能是其他部門，他們沒有收到要刪除的通知。或是DNS設定*萬用字元預設就是指向 S3 bucket。

第二，在 S3 中如果一個 bucket 名稱沒被佔用，你可以重新註冊這個名字。所以攻擊者可以重新建立一個同樣名稱的 bucket，在加上之前DNS記錄還留著，因此這原本school.systw.net這個網域會指向新建的 S3 bucket，而裡面的內容是攻擊者控制的。

除了 S3 以外，還有一大堆提供類似功能的服務都有這種問題，詳細清單可以參考：Can I take over XYZ

檢測工具

sub404

https://github.com/r3curs1v3-pr0xy/sub404.git

是一个使用python编写的工具，利用异步方式批量检查子域劫持漏洞。它会批量查询目标URL的状态，通过404页面的内容来判断是否具有子域名劫持漏洞，另外，它还会通过获取CNAME来进行检测，这个工具使用的前提是安装了sublist3r 和 subfinder。

用法：掃描子域清單检查接管漏洞 python3 sub404.py -f subdomain.txt

nuclei

如果有web的subdomain可以直接跑

$ subfinder -dL subdomains.txt -t ~/.local/nuclei-templates/http/takeovers/

也可以加個過濾將subdomain是web的清單，在做分析

$ subfinder -dL domains.txt | httpx -silent > subdomains.txt ; nuclei -t ~/.local/nuclei-templates/http/takeovers/ -l subdomains.txt

人工驗證

檢查CNAME記錄

# dig vulnerable.yourdomain.com CNAME
...omit...
;; ANSWER SECTION:
vulnerable.yourdomain.com. 300 IN    CNAME    example-deleted-app.herokuapp.com.
...omit...

這裡顯示 vulnerable.yourdomain.com 是一個 CNAME，指向 example-deleted-app.herokuapp.com.。這就是你需要確認這個目標 herokuapp.com 上的 example-deleted-app 是否已刪除或可被聲明的目標。

檢查A記錄

# dig vulnerable.yourdomain.com A
...omit...
;; ANSWER SECTION:
vulnerable.yourdomain.com. 300 IN    A    192.0.2.100
...omit...

這裡顯示子網域指向一個 IP 位址 192.0.2.100。你需要確認這個 IP 位址是否是你仍在控制的伺服器，或者是否是一個已釋放的 IP 位址。

檢查NS記錄

# dig vulnerable.yourdomain.com NS
;; ANSWER SECTION:
vulnerable.yourdomain.com. 3600 IN    NS    ns1.some-old-provider.com.
vulnerable.yourdomain.com. 3600 IN    NS    ns2.some-old-provider.com.

如果子網域的 NS 記錄指向你不再使用的外部名稱伺服器，而該外部名稱伺服器又可以被攻擊者註冊或控制，那麼這也是一種劫持的風險。

訪問目標子網域：

  • 在瀏覽器中直接訪問該子網域 (例如 http://vulnerable.yourdomain.com)。
  • 觀察錯誤訊息： 如果返回的是第三方服務的特定錯誤頁面，例如：
    • GitHub Pages 的 “There isn’t a GitHub Pages site here.” 或 “404” 頁面，但 URL 仍是你的子網域。
    • AWS S3 的 “NoSuchBucket” 錯誤。
    • Heroku 的 “No such app” 或 “Heroku | No such app” 錯誤。
    • Shopify 的 “Sorry, this shop is unavailable.”。
    • 其他雲服務提供商的通用 404 或特定錯誤頁面。
  • 關鍵是： 這個錯誤頁面是由第三方服務返回的，而不是你自己的伺服器。這表示你的 DNS 記錄成功解析到了那個服務，但那個服務上對應的資源（例如專案、bucket）已經不存在或未被聲明。

防範措施

  1. 定期檢查 DNS 設定：定期審計和清理 DNS 設定，確保所有指向外部服務的子域名都指向存在且有效的資源。
  2. 使用 DNS 設定檔管理工具：利用工具來自動化和管理 DNS 設定變更，減少人為錯誤的可能性。
  3. 清理不再使用的資源：當不再使用某個資源時，應該同時更新或刪除相關的 DNS 設定。
  4. 實施子域名監控：配置監控工具，檢測子域名的狀態變更，以便及時發現和響應潛在的接管風險。