子網域接管（Subdomain Takeover）發生在攻擊者能取得合法網站底下的某個子網域控制權。一旦得手，就可以在該子網域上提供惡意內容或攔截使用者流量。

網域名稱結構基礎#

要理解這類漏洞，先快速回顧 DNS：

  • 頂層網域（TLD）：最右側的部分，如 .com、.ca、.info
  • 註冊網域：可被個人或公司註冊的部分，如 example.com
  • 子網域（Subdomain）：左側額外段落，如 webmail.example.com、www.example.com

子網域常用兩種 DNS 記錄建立：

  • A record：把名稱對應到一個或多個 IP
  • CNAME record：把一個名稱對應到另一個名稱（常指向第三方服務）

只有網站管理員可建立這些記錄——除非找到漏洞。

子網域接管的成因#

當 A／CNAME 指向的目標已被釋出但 DNS 紀錄沒清除，攻擊者就能搶下該目標、繼承這條子網域。

經典 Heroku 情境#

  1. Example Company 在 Heroku 註冊帳號，獲得 unicorn457.herokuapp.com
  2. 在自己 DNS 設 CNAME：test.example.com → unicorn457.herokuapp.com
  3. 幾個月後決定收掉 test.example.com，關掉 Heroku 帳號但忘了刪 CNAME
  4. 攻擊者注意到 CNAME 還指向已釋出的 unicorn457.herokuapp.com，搶下該名稱
  5. 從此 test.example.com 顯示攻擊者的內容——以正當網域之名行騙

常見高風險服務#

Heroku、Zendesk、GitHub、Amazon S3、SendGrid、Fastly、Modulus 等都曾是接管漏洞的溫床。

為何危害大#

  • 共享 Cookie 範圍：若 example.com 的 Cookie 設成 .example.com，會被送到任何子網域——攻擊者可在被接管的子網域上讀走 Cookie
  • 釣魚：以「看似官方」的子網域提供登入頁
  • 電子郵件攔截（如後續 Uber/SendGrid 案例）

找這類漏洞的工具：

案例 1：Ubiquiti Subdomain Takeover#

漏洞描述#

Ubiquiti 的 CNAME assets.goubiquiti.com 指向 S3 的 uwn-images，但這個 bucket 已經未被認領（或被刪除而忘了清 DNS）。Amazon S3 的 bucket 名是全域唯一，攻擊者可以直接註冊 uwn-images → 立即接管 assets.goubiquiti.com。

Takeaways#

任何指向第三方服務（特別是 S3）的 DNS 紀錄都要追問：「對方是不是真的還在使用這個資源？」用 KnockPy 持續監控可以及時抓到變化。

案例 2：Scan.me Pointing to Zendesk#

漏洞描述#

scan.me 將 support.scan.me 透過 CNAME 指到 scan.zendesk.com。Snapchat 收購 scan.me 後關閉 Zendesk 帳號但沒刪 CNAME。研究者 harry_mg 在 Zendesk 上認領 scan.zendesk.com 並接管子網域。

Takeaways#

企業合併／收購是接管漏洞的高發期。整合過程中常有子網域被棄用但 DNS 留存——值得在收購公告後持續監看。

案例 3：Shopify Windsor Subdomain Takeover#

漏洞描述#

並非所有接管都涉及第三方服務。研究者 zseano 在 crt.sh 找到 windsor.shopify.com 的 SSL 憑證紀錄，發現 CNAME 指向 aislingofwindsor.com——一個實際註冊的網域。造訪該子網域返回 404，他乾脆花 $10 買下 aislingofwindsor.com，順勢接管 windsor.shopify.com。

Takeaways#

CNAME 指向另一個普通網域，子網域回 404 → 嘗試在註冊商查詢該網域是否可註冊。這是繞過第三方服務模型的另一條路。

案例 4：Snapchat Fastly Takeover#

漏洞描述#

Fastly 是 CDN。研究者 Ebrietas 發現 fastly.sc-cdn.net 的 CNAME 指向 Fastly 的子網域，回應錯誤訊息：

Fastly error: unknown domain: . Please check that this domain has been added to a service.

他先在 censys.io 用 SSL 憑證資訊確認 sc-cdn.net 屬於 Snapchat（域名本身沒提到 Snapchat），再設定自己的伺服器接收流量驗證——確認後才回報。

Snapchat 確認當時仍有少部分舊版 App 對該子網域請求未驗證內容——攻擊者本可在這段時間內提供惡意檔案。

Takeaways#

  • 看到第三方服務的錯誤訊息時，去讀該服務的文件，了解需要哪些設定才能接管
  • 驗證歸屬：透過 SSL 憑證資訊確認模糊的網域是不是目標公司所有

案例 5：Legal Robot Takeover#

漏洞描述#

Legal Robot 已正確在 Modulus.io 上認領 api.legalrobot.com。但 Frans Rosen 換個角度——嘗試認領通配子網域 *.legalrobot.com。Modulus 的設計允許通配子網域覆蓋特定子網域，於是 Rosen 接管了 api.legalrobot.com。

Figure 14-1: Frans Rosen 為子網域接管所提供的 HTML PoC 頁面原始碼

Rosen 的 PoC 是一個低調的 HTML 頁面，加上 HTML 註解標示自己持有，避免讓公司在公開 URL 上看起來「被攻陷」。這是值得學的善意做法。

Takeaways#

即使網站「正確設定」第三方服務，第三方服務本身的設計缺陷仍可能讓接管成立。試完特定子網域後，別忘了試 * 通配。

案例 6：Uber SendGrid Mail Takeover#

漏洞描述#

SendGrid 是雲端電子郵件服務。研究者 Rojan Rijal 發現 Uber 對 em.uber.com 設了 MX 記錄指向 mx.sendgrid.net。SendGrid 文件中提到 Inbound Parse Webhook 服務需要兩步：

  1. MX 記錄指到 mx.sendgrid.net（Uber 已做）
  2. 在 SendGrid 後台把該網域與 Webhook URL 關聯起來

Uber 沒做第二步。Rijal 在自己的 SendGrid 帳號裡認領 em.uber.com 為 Inbound Parse Webhook，並在自己伺服器上接收流量——成功攔截寄到 em.uber.com 的所有電子郵件。

回報後 SendGrid 加入「必須先驗證網域歸屬」的安全檢查。

Takeaways#

讀第三方服務的開發者文件——尋找「需要兩步以上設定才安全」的功能。任何有一步是「在主控台開關」的整合，都該檢查目標是否漏做。

章末總結#

  • 子網域接管的常見模式：DNS 記錄指向已釋出或未認領的第三方資源
  • 高 CP 值切入點：
    • DNS 紀錄指向 Heroku、S3、Zendesk、Fastly、SendGrid、Modulus
    • SSL 憑證紀錄列出來但目前回 404 的子網域
    • 收購／合併後留下的孤兒紀錄
  • 進階技巧：通配子網域接管、Webhook 接管、MX 接管攔截 Email
  • PoC 要低調：用 HTML 註解或非破壞性內容驗證即可，避免讓對方公開難堪
Backward 記憶體漏洞 競態條件 Forward