前言
子域名接管是指註冊一個不存在的域名以獲得對另一個域名控制權的過程。此過程最常見的情況如下：
- 域名（例如http://sub.example.com）將CNAME記錄用於另一個域（例如http://sub.example.com CNAME http:// anotherdomain.com ）。
- 在某個時間點， http:// anotherdomain.com 到期，任何人都可以註冊。
- 由於不會從 http://example.com DNS區域刪除CNAME記錄，因此註冊 http:// anotherdomain.com 域名的任何人都可以完全控制http://sub.example.com，直到存在DNS記錄為止。
子域接管的含義非常重要。通過使用子域名託管，攻擊者可以從合法的域名發送網絡釣魚電子郵件，執行跨站腳本（XSS）或破壞與該域相關聯的品牌的聲譽。您可以在我的其他文章中瞭解有關隱含（風險）的更多信息。
子域接管不限於CNAME記錄,NS，MX甚至A記錄(均不受此限制）也將受到影響。這篇文章主要涉及CNAME記錄。但是，在需要的地方也會提供NS和MX記錄的用例。
常規域名
使用CNAME記錄的DNS委託對用戶完全透明，即在DNS解析過程都在後臺發生。下圖說明了具有CNAME記錄的域名的Web瀏覽器的行為。
請注意，Web瀏覽器無保留地信任DNS解析程序返回的任何內容。這種信任意味著，當攻擊者獲得對DNS記錄的控制權時，將繞過所有Web瀏覽器安全性度量（例如， 同源策略 ）。由於子域接管破壞了域的真實性，攻擊者可以通過多種方式利用該域的真實性，因此這帶來了相當大的安全威脅。TLS / SSL也無法解決此問題，因為子域名接管不是常規的中間人式攻擊。
CNAME子域接管 。
CNAME子域接管的主要類型之一是規範域名,常規的Internet域（指非雲提供商擁有的一個域名）的情況。檢測某些源域名是否易受CNAME子域接管的過程非常簡單：
給定源域名和規範域名對，如果可以使用規範域名的基本域進行註冊，則源域名容易受到子域接管。
在此過程中 ， 值得注意的是 “規範域名的基本域” 。這是因為規範域名可能採用更高級別的域的形式。如果基本域名可以被註冊，那麼之後在DNS區域裡更高級別的域名也能被輕鬆再創建.
可以使用域名註冊商（例如Namecheap）來檢查基本域名的可用性。有的人認為測試NXDOMAIN的DNS 響應狀態足以表明該域名是否可供註冊。但是事實上並非如此，因為在某些情況下域名會以 NXDOMAIN 響應，但無法註冊。原因主要是受限制的頂級域名（例如.GOV，.MIL）或TLD註冊服務商保留的域名 。
NS子域接管 。
子域接管的概念可以自然地擴展到NS記錄： 如果至少一個NS記錄的規範域名的基礎域可用於註冊，則源域名也會容易受到子域接管的影響。
使用NS記錄進行子域接管的問題之一就是源域名通常具有多個NS記錄，多個NS記錄用於冗餘和負載平衡。假設域 http://sub.example.com 具有兩個NS記錄：
- http:// ns.vulnerable.com
- ns.nonvul http:// nerable.com
如果攻擊者接管了 http:// ns.vulnerable.com ，那麼從查詢 http://sub.example.com 的用戶的角度來看，有以下三種情況:
- 由於有兩條記錄，因此隨機選擇一個。這意味著查詢由攻擊者控制的服務器名稱的可能性為50％。
- 如果用戶的DNS解析器選擇 ns.nonvul http:// nerable.com （合法的名稱服務器），則會返回正確的結果，並且可能會在6到24小時之間進行緩存。
- 如果用戶的DNS解析器選擇 http:// ns.vulnerable.com （攻擊者擁有的名稱服務器），則攻擊者可能會提供錯誤的結果，該結果也將被緩存。由於攻擊者控制著名稱服務器，因此她可以對特定結果進行TTL設置,例如一週。
MX子域接管。
與NS和CNAME子域接管相比，MX子域接管影響最小。由於MX記錄僅用於接收電子郵件，因此，獲得對MX記錄中規範域名的控制權只可以使攻擊者能夠接收發送到源域名的電子郵件。儘管影響不如CNAME或NS子域接管大，但MX子域接管在魚叉式網絡釣魚攻擊和知識產權竊取中起了非常大的作用。
雲提供商
近年來，雲服務越來越受歡迎。雲的基本前提之一是減輕其用戶設置基礎架構的負擔。企業組織正在從本地設置切換雲替代方案，例如雲存儲，雲中的電子商務和SAAS等。
用戶創建了新的雲服務後，大多數情況下，雲提供商會生成一個唯一的域名，該域名用於訪問創建的資源。由於大量的雲服務客戶，通過TLD註冊服務商註冊域名不是很方便，因此雲提供商會選擇使用子域。
標識唯一雲資源的子域通常採用 http:// name-of-customer.cloudprovider.com 的格式，其中 http:// cloudprovider.com 是特定雲提供商所擁有的基本域。
如果組織註冊的雲服務是公開的（例如，電子商務商店），則特定組織可能希望將其作為其域的一部分呈現。其背後的主要原因是品牌塑造： http:// shop.organization.com 看起來比 http:// organization.ecommerceprovider.com 更好。在這種情況下，組織會有兩個選擇：
- HTTP重定向301/302 - 301 和 302 是HTTP觸發web瀏覽器到當前URL重定向到另一個URL響應代碼。在雲服務的上下文中，第一個請求是對組織的域名（例如， http:// shop.organization.com ）進行的，然後重定向到雲提供商的域名（例如， http:// organization.ecommerceprovider.com ）。
- CNAME記錄 —使用此方法，“ redirect”在DNS解析期間發生。組織設置CNAME記錄，所有流量自動委派給雲提供商。使用此方法，用戶瀏覽器中的URL保持不變。但是請注意特定的雲服務必須支持使用CNAME記錄的委派。
如果使用CNAME記錄方法，則可能發生子域接管。即使雲提供商擁有規範域名的基本域，也可以進行子域接管，如以下小節所述。
據統計,以下三個原因是雲提供商發生子域名接管的常見原因。
- 流行度 -基於CNAME記錄的統計信息，對CNAME記錄中使用率最高的雲提供商域進行了優先級排序。
- 支持CNAME記錄 —如上所述，雲提供商需要支持CNAME委派。雲提供商意識到客戶要求這種行為，並且最受歡迎的雲提供商已經支持了這種行為。
- 域名所有權驗證 -所選的雲提供商未在驗證源域名的所有權。由於不需要證明所有者，因此任何人都可以使用過期的雲配置來實現子域接管。
根據這三個原因下文我將對各個雲服務展開風險分析。
亞馬遜CloudFront
Amazon CloudFront是Amazon Web Services（AWS）中的 內容交付網絡（CDN ）。CDN將Web內容的副本分發到位於不同地理位置（稱為存在點）的服務器。當用戶向CDN發出請求時，將根據訪問者的位置選擇最近的存在點以降低延遲。組織使用CDN，主要用於分發媒體文件，例如視頻，音頻和圖像。CDN的其他優點包括拒絕服務攻擊防護，減少帶寬以及在流量高峰時進行負載平衡。
CloudFront使用 Amazon S3 作為Web內容的主要來源。Amazon S3是AWS提供的另一項服務。它是一種雲存儲服務（S3是簡單存儲服務的縮寫），允許用戶將文件上傳到所謂的 存儲桶中 ，這是S3中邏輯組的名稱。
CloudFront遵循 發行版 的概念。每個分發都是指向特定Amazon S3存儲桶的鏈接，以從中獲取對象（文件）。創建新的CloudFront分配後，將生成一個唯一的子域來提供訪問權限。該子域的格式為
http:// SUBDOMAIN.cloudfront.net 。上述 SUBDOMAIN 部分由CloudFront的產生，並且不能由用戶來指定。那麼除了隨機生成的子域外，CloudFront還可以指定用於訪問發行版的備用域名。通過創建從備用域名到CloudFront生成的子域的CNAME記錄來實現獲取內容的訪問。儘管Amazon不提供有關內部CloudFront概念的文檔，但是可以從其行為中推斷出高級架構。根據地理位置，對 http:// cloudfront.net 的 任何子域的DNS查詢會導致相同的A記錄（在相同區域中）。這表明CloudFront正在後端使用虛擬主機設置。HTTP請求到達後，CloudFront的邊緣服務器會根據HTTP Host 標頭確定正確的分發。
其使用文檔中指出：
當備用域名已經存在於另一個CloudFront分配中時，您無法將備用域名添加到另外的CloudFront分配中，即使您的AWS賬戶擁有另一個分配也是如此 。
所以我們可以發現,一個"分配"可以同時擁有多個備用域名，但是在多個"分配"中存在相同的備用域名,這樣就會報錯。
圖片展示了CloudFront 邊緣服務器的大致工作流程
因此，想要正確處理備用域名，CloudFront就需要事先知道備用域名附加了到哪個發行版。換句話說，僅配置CNAME記錄是不夠的，還需要在分發設置中設置其備用域名。
CloudFront中備用域名的問題類似於“ 常規域” 部分中說明的問題。假設 http://sub.example.com 的CNAME記錄設置為 http:// d1231731281.cloudfront.net 。如果在CloudFront發行版中沒有註冊 http://sub.example.com 作為備用域名，則可以進行子域接管。任何人都可以創建一個新的發行版，並將 http://sub.example.com 設置為備用域名。但是請注意，新創建的CloudFront子域不需要與CNAME記錄（ http:// d1231731281.cloudfront.net ）。由於CloudFront使用虛擬主機設置，因此在解析時會使用HTTP主機標頭而不是DNS記錄來確定正確的分配。
下圖顯示了在HTTP請求到備用域名後的錯誤消息，該備用域名具有到CloudFront的DNS CNAME記錄，但未在任何CloudFront發行版中註冊。
此錯誤消息展示了子域接管可能性的提示。但是，在此基礎上我們還需要考慮兩個例外：
- 僅HTTP / HTTPS分發 -CloudFront允許指定分發是僅HTTP還是僅HTTPS。將HTTP切換為HTTPS可能會為某些發行版提供正確的響應。
- 禁用的分發 -某些分發可能已禁用。禁用的分發不再繼續有效地提供內容，同時仍保留其設置。這意味著某些備用域名可能在HTTP請求後引發錯誤消息。但是，它甚至已在禁用的分發中註冊，因此不容易受到子域接管。確定是否在某個發行版中註冊了備用域的正確方法是創建新的發行版並設置備用域名。如果註冊過程沒有引發錯誤，則自定義域容易受到子域接管。下面的屏幕快照顯示了用戶嘗試註冊其他某些CloudFront發行版中已經存在的備用域名後出現的錯誤。
其他
如CloudFront所示，即使沒有基域可用於註冊的雲服務，也可以進行子域接管。但是，由於雲服務提供了一種指定備用域名（CNAME記錄）的方式，因此仍然存在子域接管的可能性。本節將提供與CloudFront（虛擬主機架構）非常相似的其他雲服務的快速概述。
- Amazon S3 —先前曾簡要提到過Amazon S3。用於訪問存儲桶的默認基本域並不總是相同，並且取決於所使用的AWS區域。AWS文檔中提供了Amazon S3基本域的完整列表。與CloudFront相似，Amazon S3允許指定備用（自定義）域名來訪問存儲桶的內容。
- Heroku — Heroku是一個SAAS(平臺即服務)的提供程序，它允許使用簡單的工作流來部署應用程序。由於需要訪問該應用程序，因此Heroku使用在 http:// herokuapp.com 上 形成的子域公開該應用程序。但是，也可以指定自定義域名來訪問已部署的應用程序。
- Shopify -Shopify提供了一種在雲中創建和自定義電子商務商店的方法。訪問商店的默認子域構建在 http:// myshopify.com 上 。如前所述，Shopify允許指定備用域名。值得注意的是，Shopify會驗證正確的CNAME記錄配置。但是，此驗證不是域所有權驗證。Shopify僅檢查備用域的DNS區域中是否存在正確的CNAME記錄。因此，此驗證不會阻止子域接管。
- GitHub -GitHub是Git的版本控制存儲庫。GitHub還允許使用其 GitHub Pages 項目進行免費的虛擬主機。該虛擬主機通常用於項目的文檔，技術博客或開源項目的支持網頁。GitHub Pages除了 http:// github.io 下的默認域名外，還支持自定義域名。
- Microsoft Azure — Microsoft Azure是更傑出的雲提供商，類似於AWS。與上面提到的雲服務相比，它的不同之處在於它不提供虛擬託管架構。簡而言之，對於每個雲服務，Azure都會使用自己的IP地址創建自己的虛擬機。因此，域名和IP地址之間的映射是明確的（一對一映射）。值得注意的是，由於這不是常規的虛擬主機設置，因此不一定必須在資源設置中明確定義配置CNAME記錄。Azure提供了多種雲服務，但本文中討論的服務具有默認域 http:// cloudapp.net 和 http:// azurewebsites.net 。其文檔描述了使用A或CNAME記錄（指向前面提到的兩個域之一）來設置域名和Azure資源之間的鏈接。一個有趣的發現是，對於A記錄，Azure使用TXT記錄進行域所有權驗證。但是，CNAME記錄不是這種情況，因此即使在Microsoft Azure的情況下也可以進行子域接管。
全互聯網掃描
Sonar項目可用於顯示Internet上子域接管的普遍性。由於Sonar項目已經包含已解析的CNAME記錄，因此通過Internet自動掃描子域接管非常簡單。本節說明其結果。
CNAME記錄鏈 。在某些情況下，CNAME記錄可能形成CNAME記錄鏈。讓我們來看看 http://sub.example.com 這個域名，它的CNAME記錄是 http:// sub.example1.com 。如果反過來， http:// sub.example1.com 擁有一個到 http:// sub.example2.com 的CNAME記錄，則形成三向鏈：
<code>sub
.example
.com
-
>sub
.example1
.com
-
>sub
.example2
.com
/<code>
在這種情況下，當鏈中最後一個域的基本域（ http:// example2.com ）可用於註冊時， http:// sub.example1.com 和 http://sub.example.com都會 受到影響。幸運的是，Sonar項目默認包含了鏈中的所有CNAME引用。對於上面給出的鏈，即使沒有從 http://sub.example.com 到 http:// sub.example2.com 的 直接CNAME記錄，Project Sonar仍包含該記錄。因此，無需對自動化工具進行多餘配置即可支持Project Sonar中的CNAME記錄鏈。
掃描是使用自定義自動化工具執行的，該工具尚不打算髮布。該工具能夠掃描雲提供商域，並發現 12888個 源域名易受子域接管（2017年11月）。雲提供商的分發如下：
