最近在HackerOne上看到了幾個子域名接管方面的漏洞，幾個漏洞都可以輕鬆就對子域獲得控制權，並且獲得了來自企業的高額獎金。在國外看到了這篇文章，粗略翻譯了下，也順便圍繞這個話題說說吧，相關漏洞案例可以去H1搜尋“subdomain takeover”檢視。

0x01 前言

子域名接管漏洞通常被濫用於以下幾個目的：惡意軟體分發、網路釣魚/魚叉式網路釣魚、XSS 、身份驗證繞過等等。由於某些證書頒發機構僅需要域驗證，因此也可以輕鬆生成SSL證書。

子域名接管是註冊不存在的域名以獲得對另一個域的控制權的過程。此過程最常見的情況如下：

1.域名（例如，sub.example.com）將CNAME記錄用於另一個域（例如，sub.example.com CNAME anotherdomain.com）。

2.在某個時間點，anotherdomain.com到期並可供任何人註冊。

3.由於未從example.com DNS區域刪除CNAME記錄，因此註冊anotherdomain.com的任何人都可以完全控制sub.example.com，直到存在DNS記錄。

子域名接管的影響可能非常重要。使用子域名接管，攻擊者可以從合法域傳送網路釣魚電子郵件，執行跨站點指令碼（XSS）或破壞與域關聯的品牌聲譽。

子域名接管不僅限於CNAME記錄。NS，MX甚至A記錄也會受到影響。這篇文章主要涉及CNAME記錄。但是，NS和MX記錄的相關用例會在需要時也會介紹到。

0x02 常規域名

使用CNAME記錄的DNS授權對使用者完全透明，它發生在DNS解析期間的後臺。下圖說明了具有CNAME記錄的域名的Web瀏覽器的行為。

需要注意的是，Web瀏覽器隱式地信任放在DNS解析器返回的任何內容上。這種信任意味著當攻擊者獲得對DNS記錄的控制時，繞過所有Web瀏覽器安全策略（例如，同源策略）。這會帶來相當大的安全威脅，因為子域名接管會破壞域名的真實性，攻擊者可以通過多種方式利用域名的真實性。如稍後所示，TLS / SSL無法解決此問題，因為子域名接管不是常規的中間人攻擊。

CNAME子域接管。CNAME子域接管的主要型別之一是叫做網際網路常規域名的規範域，而不是雲服務商擁有的域名的情況，如下所述。檢測某些源域名是否容易受到CNAME子域名接管的過程非常簡單：

給定一對源域名和規範域名，如果規範域名的基本域可供註冊，則源域名容易被子域接管。

這個過程中值得注意的事情是，規範域名的基本域。這是因為規範域名可能是更高級別的域名。如果基礎域可用於註冊，高階域名可以很容易地在DNS區域中重新建立。

使用域名註冊商（如Namecheap）可以檢查基礎域名的可用性。有人可能認為測試NXDOMAIN的DNS響應狀態足以表明域名可用於註冊。但請注意，情況並非如此，因為存在域名以NXDOMAIN響應但無法註冊的情況。原因包括TLD註冊商限制的頂級域名（例如.GOV，.MIL）或保留域。

NS子域名接管。子域名接管的概念可以自然地擴充套件到NS記錄：如果至少一個NS記錄的規範域名的基本域可用於註冊，則源域名易受子域名接管的影響。

使用NS記錄而產生子域名接管漏洞中的一個問題是源域名通常具有多個NS記錄。多個NS記錄用於冗餘和負載平衡。在DNS解析之前隨機選擇名稱伺服器。假設域sub.example.com有兩個NS記錄：ns.vulnerable.com和ns.nonvulnerable.com。如果攻擊者接管了ns.vulnerable.com，則從查詢sub.example.com的使用者的角度來看，情況如下：

1.由於有兩個名稱伺服器，因此隨機選擇一個。這意味著查詢攻擊者控制的名稱伺服器的概率為50％。

2.如果使用者的DNS解析程式選擇ns.nonvulnerable.com（合法名稱伺服器），則返回正確的結果，並且可能會在6到24小時之間快取。

3.如果使用者的DNS解析器選擇ns.vulnerable.com（攻擊者擁有的名稱伺服器），則攻擊者可能會提供錯誤的結果，該結果也將被快取。比如，由於攻擊者控制著名稱伺服器，因此她可以將此特定結果的TTL設定為一週。

MX子域名接管。與NS和CNAME子域名接管相比，MX子域名接管的影響最小。由於MX記錄僅用於接收電子郵件，因此在MX記錄中獲得對規範域名的控制僅允許攻擊者接收發往源域名的電子郵件。雖然影響不如CNAME或NS子域名接管那麼重要，但MX子域名接管可能會在魚叉式網路釣魚攻擊和智慧財產權竊取中發揮作用。

0x03 雲提供商

雲服務近年來越來越受歡迎。雲的基本前提之一是從建立他們的基礎設施中解除安裝使用者。舉幾個例子，組織正在從內部部署設定轉向諸如雲儲存，雲中的電子商務和平臺即服務等替代方案。

使用者建立新的雲服務後，雲提供商在大多數情況下會生成一個唯一的域名，用於訪問建立的資源。由於雲服務客戶數量眾多，因此通過TLD註冊商註冊域名不是很方便，因此雲提供商選擇使用子域名。標識唯一雲資源的子域通常採用name-of-customer.cloudprovider.com的格式，其中cloudprovider.com是特定雲提供商擁有的基本域。

如果組織註冊的雲服務是公開的（例如，電子商務商店），則組織可能希望將其作為其域的一部分存在。這背後的主要原因是品牌推廣：shop.organization.com看起來比organization.ecommerceprovider.com好。在這種情況下，組織有兩種選擇：

• HTTP 301/302重定向 - 301和302是HTTP響應程式碼，用於觸發Web瀏覽器將當前URL重定向到另一個URL。在雲服務的上下文中，首先請求組織的域名（例如，shop.organization.com），然後重定向到雲提供商的域名（例如，organization.ecommerceprovider.com）。

• CNAME記錄 - 使用此方法，“重定向”在DNS解析期間發生。組織設定CNAME記錄，並且所有流量都自動委託給雲提供商。使用此方法，使用者瀏覽器中的URL保持不變。但是需要注意是是，雲服務必須支援使用CNAME記錄的委派。

如果使用CNAME記錄方法，子域名接管的可能性就會發揮作用。即使雲提供商擁有規範域名的基本域，仍然可以進行子域接管，如下面所述。

• 普遍性 - 基於CNAME記錄的統計資訊，優先考慮CNAME記錄中使用率最高的雲提供商域。

• 支援CNAME記錄 - 如上所述，雲提供商需要支援CNAME委派。雲提供商意識到客戶要求此類行為，而最受歡迎的雲提供商已經支援此行為。

• 域所有權驗證 - 所選的雲提供商未驗證源域名的所有權。由於所有者不需要經過驗證，因此任何人都可以使用過期的雲配置來實現子域名接管。

0x04 Amazon CloudFront

Amazon CloudFront是Amazon Web Services（AWS）中的內容交付網路（CDN）。CDN將Web內容的副本分發到位於不同地理位置（稱為存在點）的伺服器。當用戶向CDN發出請求時，基於訪問者位置選擇最近的存在點以降低延遲。組織使用CDN，主要用於分發視訊，音訊和影象等媒體檔案。CDN的其他優點包括拒絕服務攻擊保護，減少頻寬以及高流量峰值時的負載平衡。

CloudFront使用Amazon S3作為Web內容的主要來源。Amazon S3是AWS提供的另一項服務。它是一種雲端儲存服務（S3是Simple Storage Service的縮寫），它允許使用者將檔案上傳到所謂的儲存桶中，這是S3中邏輯組的名稱。

CloudFront使用分發的概念。每個分發都是指向特定Amazon S3儲存桶的連結，用於提供物件（檔案）。建立新的CloudFront分配時，會生成唯一的子域以提供訪問許可權。此子域的格式為SUBDOMAIN.cloudfront.net。所述SUBDOMAIN部分由CloudFront的產生，並且不能由使用者來指定。

除了隨機生成的子域外，CloudFront還可以指定用於訪問分發的備用域名。這可以通過從備用域名到CloudFront生成的子域建立CNAME記錄來實現。雖然亞馬遜沒有提供有關內部CloudFront概念的文件，但可以從其行為中扣除高階體系結構。根據地理位置，對cloudfront.net的任何子域的DNS查詢會導致相同的A記錄（在同一區域中）。這表明CloudFront正在後端使用虛擬主機設定。HTTP請求到達後，CloudFront的邊緣伺服器根據HTTP 主機頭確定正確的分發。文件也支援這一理論，因為它表明：如果備用域名已存在於另一個CloudFront分配中，則無法將備用域名新增到CloudFront分配，即使您的AWS賬戶擁有其他分配。將多個備用域指向一個分發是正確的，但是，在多個分發中具有相同的備用域名則不是。

因此，為了正確處理備用域名，CloudFront需要事先知道備用域名附加到哪個分發。換句話說，配置CNAME記錄是不夠的，需要在分發設定中明確設定備用域名。

CloudFront中備用域名的問題類似於常規域部分中解釋的問題。我們假設sub.example.com的CNAME記錄設定為d1231731281.cloudfront.net。如果沒有在任何CloudFront分配中註冊的sub.example.com作為備用域名，則可以進行子域名接管。任何人都可以建立新的釋出，並在其設定中將sub.example.com設定為備用域名。但請注意，新建立的CloudFront子域不需要與CNAME記錄中指定的子域匹配（d1231731281.cloudfront.net））。由於CloudFront使用虛擬主機設定，因此使用HTTP主機頭而非DNS記錄確定正確的分發。

下圖顯示了HTTP請求到備用域名後出現的錯誤訊息，該域名具有到CloudFront的DNS CNAME記錄，但未在任何CloudFront分配中註冊。

此錯誤訊息可以明確表示子域名接管的可能性。然而，需要考慮兩個例外情況：

• 僅HTTP / HTTPS分發 - CloudFront允許指定分發是僅HTTP還是僅HTTPS。將HTTP切換為HTTPS可能會為某些分發提供正確的響應。

• 禁用分發 - 某些分發可能已禁用。禁用分發不再主動提供內容，同時仍保留其設定。這意味著某些備用域名可能在HTTP請求後丟擲錯誤訊息。但是，它甚至在禁用的發行版中註冊，因此不容易受到子域名接管的影響。確定備用域是否在某個分發中註冊的正確方法是建立新分發並設定備用域名。如果註冊過程不會引發錯誤，則自定義域很容易受到子域名接管。下面的螢幕截圖顯示了在使用者嘗試註冊其他某個CloudFront分配中已存在的備用域名後顯示的錯誤。

0x05 其他

如CloudFront中所示，即使在沒有可用於註冊的基本域的雲服務上，也可以進行子域接管。但是，由於雲服務提供了指定備用域名（CNAME記錄）的方法，因此仍然存在子域接管的可能性。本節簡要概述了與CloudFront（虛擬主機架構）非常相似的其他雲服務。

• Amazon S3 - 以前簡要提到了Amazon S3。用於訪問儲存桶的預設基本域並不總是相同，並且取決於所使用的AWS區域。AWS文件中提供了Amazon S3基本域的完整列表。與CloudFront類似，Amazon S3允許指定備用（自定義）域名以訪問儲存桶的內容。

• Heroku - Heroku是一個平臺即服務提供商，可以使用簡單的工作流程部署應用程式。由於需要訪問應用程式，Heroku使用herokuapp.com上形成的子域公開應用程式。但是，也可以指定自定義域名以訪問已部署的應用程式。

• Shopify - Shopify提供了一種在雲中建立和自定義電子商務商店的方法。訪問商店的預設子域是在myshopify.com上構建的。作為之前描述的服務，Shopify允許指定備用域名。值得注意的是Shopify驗證了正確的CNAME記錄配置。但是，此驗證不是域名所有權驗證。Shopify僅檢查備用域的DNS區域中存在的準確CNAME記錄。因此，此驗證不會阻止子域名的接管。

• GitHub - GitHub是Git的版本控制儲存庫。GitHub還允許使用他們的GitHub Pages專案進行免費的虛擬主機託管。此Web託管通常用於專案的文件，技術部落格或支援Web頁面到開源專案。除github.io下的預設域名外，GitHub Pages還支援自定義域名。

• Microsoft Azure - Microsoft Azure是一個更加突出的雲提供商，類似於AWS。與上面提到的雲服務相比，它不同，因為它不提供虛擬主機架構。簡而言之，對於每個雲服務，Azure都會建立自己的具有自己IP地址的虛擬機器。因此，域名和IP地址之間的對映是明確的（一對一對映）。值得注意的是，由於這不是常規虛擬主機設定，因此不一定必須在資源設定中明確定義配置CNAME記錄。Azure提供多種雲服務，但本文中討論的雲服務具有cloudapp.net和azurewebsites.net的預設域。其文件描述了使用A或CNAME記錄設定域名和Azure資源之間的連結（指向前面提到的兩個域之一）。一個有趣的觀察是，對於A記錄，Azure使用TXT記錄進行域所有權驗證。但是，對於CNAME記錄而言並非如此，因此即使在Microsoft Azure的情況下也可以進行子域接管。

0x06 網際網路範圍的掃描

Sonar專案可用於顯示網際網路上子域名接管的普遍程度。由於Project Sonar已經包含已解析的CNAME記錄，因此通過Internet自動掃描子域接管非常簡單。本節介紹其結果。

CNAME記錄鏈。在某些情況下，CNAME記錄可能會形成CNAME記錄鏈。讓我們域sub.example.com具有CNAME記錄sub.example1.com。如果反過來，sub.example1.com有一個到sub.example2.com的CNAME記錄，則會形成一個三向鏈：

sub.example.com -> sub.example1.com -> sub.example2.com

在這種情況下，當鏈（example2.com）中的最後一個域的基本域可用於註冊時，sub.example1.com和sub.example.com都會受到影響。幸運的是，Project Sonar隱含地包含鏈中的所有CNAME引用。對於上面給出的鏈，即使從sub.example.com到sub.example2.com沒有直接的CNAME記錄，Project Sonar也包含此記錄。因此，不需要對自動化工具進行直接更改以支援Project Sonar中的CNAME記錄鏈。

掃描雲提供商域，發現12,888個源域名易受子域名接管（2017年11月）。

雲提供商分發如下：

翻譯自：https://0xpatrik.com/subdomain-takeover-basics

原文作者：@Patrik    /  翻譯：@倉鼠

註明：翻譯時進行了適當刪減與更改，轉載請註明，感謝。