自動(dòng)探測(cè)

自動(dòng)化探測(cè)利用腳本正在完善優(yōu)化中，歡迎各位師傅試用交流：https://github.com/Echocipher/Subdomain-Takeover

如果您在使用中遇到了一些Bug，或者建議，期待您的交流：echocipher@163.com

0x00 What is Subdomain Takeover?

子域名接管是由于錯(cuò)誤配置等原因，對(duì)應(yīng)主機(jī)指向了一個(gè)當(dāng)前未在使用或已經(jīng)刪除的特定服務(wù)（例如：Github pages，Heroku等），攻擊者可以通過(guò)接管子域來(lái)獲取對(duì)另一個(gè)域的控制權(quán)的風(fēng)險(xiǎn)點(diǎn)。通常情形如下：

1. 域名使用CNAME記錄到了另一個(gè)域（例如，sub.example.com CNAME anotherdomain.com）

1565749573421

2. anotherdomain`到期并可以被任何人注冊(cè)
3. 由于未example.com DNS區(qū)域刪除CNAME記錄，因此攻擊者注冊(cè)anotherdomain.com后可以控制sub.example.com

如果上述存在的話，任何注冊(cè)anotherdomain.com的人都可以控制sub.example.com直到DNS記錄失效，攻擊者可以利用這一點(diǎn)構(gòu)造釣魚(yú)頁(yè)面、執(zhí)行跨站腳本攻擊（XSS）等等

子域名接管不僅僅限于CNAME記錄，NS,MX甚至A記錄也會(huì)受到影響。

0x02 How does it come about?

Transparency To Browser

resolution-2

上圖記錄了涉及CNAME的DNS解析，在第7步中，瀏覽器請(qǐng)求sub.example.com而不是anotherdomain，即使是使用了CNAME記錄，瀏覽器中的URL欄目中扔包含sub.example.com, Web瀏覽器會(huì)信任DNS解析后返回的內(nèi)容，這也就導(dǎo)致當(dāng)攻擊者能控制DNS記錄的時(shí)候，當(dāng)我們請(qǐng)求sub.example.com時(shí)，瀏覽器接收到攻擊者設(shè)置的A記錄的值，瀏覽器認(rèn)為這是合法的，就會(huì)顯示從該服務(wù)器接收到的所有內(nèi)容，通過(guò)這一點(diǎn)攻擊者就可以繞過(guò)Web瀏覽器的安全性檢測(cè)（例如：同源策略），而且由于子域接管不是常規(guī)的中間人攻擊，所以TLS/SSL并不能解決該問(wèn)題，甚至通過(guò)生成有效的SSL證書(shū)還可以使得攻擊場(chǎng)景更加完善。

SSL證書(shū)

例如Let’s Encrypt等證書(shū)機(jī)構(gòu)允許通過(guò)內(nèi)容自動(dòng)驗(yàn)證域名所有權(quán)：

1565757611338

攻擊者由于可以控制子域內(nèi)容，因此按照Let’s Encrypt的要求在特定的URL路徑上放置特定內(nèi)容之后，Let’s Encrypt 將會(huì)自動(dòng)完成證書(shū)的驗(yàn)證，然后批準(zhǔn)為給定域發(fā)放證書(shū)，這大大降低了用戶對(duì)網(wǎng)絡(luò)釣魚(yú)的識(shí)別度。

0x03 What will it lead to?

由于子域名接管導(dǎo)致的問(wèn)題，很多漏洞賞金廠商已經(jīng)開(kāi)始接收子域名接管的漏洞，從賞金方面我們可以推測(cè)出廠商對(duì)問(wèn)題的重視程度：

那么子域名接管都會(huì)導(dǎo)致哪些問(wèn)題呢？

Cookie竊取

瀏覽器實(shí)施了很多安全策略從而保證用戶不受惡意網(wǎng)站傷害，其中包括同源策略等內(nèi)容，瀏覽器主要安全職責(zé)之一就是保護(hù)已經(jīng)存在的Cookie，由于雖然HTTP是無(wú)狀態(tài)協(xié)議，但是為了方便用戶登錄，所以會(huì)采用Cookie充當(dāng)?shù)卿浟钆疲瑸g覽器識(shí)別過(guò)后驗(yàn)證用戶身份，而Cookie可以跨子域共享，例如當(dāng)網(wǎng)站使用基于Cookie的單點(diǎn)登錄系統(tǒng)時(shí)，用戶可以使用一個(gè)子域登錄，并且在各種子域中共享相同的會(huì)話令牌，設(shè)置常規(guī)Cookie的語(yǔ)法如下：

HTTP/1.1 200 OK
Set-Cookie: name=value

如果這個(gè)Cookie是由example.com所在的web服務(wù)器發(fā)出的，那么只有這個(gè)服務(wù)器才可以訪問(wèn)到這個(gè)Cookie，但是可以通過(guò)以下方式為通配符域發(fā)布Cookie：

HTTP/1.1 200 OK
Set-Cookie: name=value; domain=example.com

這樣Cookie可以存在于對(duì)example.com的HTTP請(qǐng)求中，也可以包含在任何其他子域里面（例如：subdomain.example.com），這樣導(dǎo)致使用子域名接管來(lái)進(jìn)行攻擊，例如某個(gè)特定的域使用Cookie用于通配符域，那么如果有一個(gè)子域遭受到攻擊者子域接管，如果用戶訪問(wèn)了該子域，Cookie會(huì)隨HTTP請(qǐng)求自動(dòng)發(fā)送，這樣會(huì)導(dǎo)致HttpOnly cookie被繞過(guò)，

HttpOnly cookie - 默認(rèn)情況下，Cookie可以通過(guò)在創(chuàng)建cookie的網(wǎng)站上下文中運(yùn)行的Javascript代碼訪問(wèn)。Javascript可以讀取，更新和刪除cookie。HttpOnly cookie標(biāo)志（由Web服務(wù)器設(shè)置）表示Javascript代碼無(wú)法訪問(wèn)特定cookie。獲取它的唯一方法是通過(guò)HTTP請(qǐng)求和響應(yīng)標(biāo)頭。

而上文我們又介紹了攻擊者可以生成SSL證書(shū)，因此瀏覽器的另一安全機(jī)制Secure cookie也會(huì)被繞過(guò)

Secure cookie - 當(dāng)cookie具有由Web服務(wù)器設(shè)置的安全標(biāo)志時(shí)，只有在使用HTTPS時(shí)才能將其傳送回Web服務(wù)器。

當(dāng)子域接管被利用后，攻擊者通過(guò)欺騙用戶訪問(wèn)自己控制的子域，由于沒(méi)有使用JavaScript訪問(wèn)Cookie，又可以生成SSL證書(shū)，所以可以繞過(guò)這兩個(gè)安全機(jī)制來(lái)竊取用戶Cookie

Arne Swinnen在hackerone的報(bào)告中詳細(xì)的介紹了攻擊過(guò)程：https://hackerone.com/reports/172137

而且由于JavaScript腳本是攻擊者可以控制的，因此攻擊者接管后可以進(jìn)行更多其他的攻擊。

但是有一種辦法可以保護(hù)瀏覽器中JavaScript腳本的完整性，Subresource Integrity提出了一種機(jī)制，將加密哈希添加到script中，

<script src="https://example.com/example-framework.js"
 integrity="sha384-Li9vy3DqF8tnTXuiaAJuML3ky+er10rcgNR/VqsVpcw+ThHmYcwiB1pbOxEbzJr7"
 crossorigin="anonymous"></script>

當(dāng)提供的加密哈希與下載文件不匹配時(shí)，瀏覽器將會(huì)拒絕執(zhí)行它。

電子郵件

當(dāng)可以進(jìn)行CNAME子域接管的時(shí)候。攻擊者可以將MX設(shè)置為任意Web服務(wù)器，這會(huì)允許接收電子郵件到某個(gè)子域中，攻擊者通常會(huì)使用欺騙Return-Path header的方法接收電子郵件的回復(fù)。在網(wǎng)絡(luò)釣魚(yú)攻擊中經(jīng)常大范圍使用，同時(shí)，由于SPF將配置存儲(chǔ)在DNS TXT記錄中，當(dāng)子域被接管的時(shí)候，攻擊者同樣可以控制TXT 記錄，就可以繞過(guò)SPF檢查來(lái)發(fā)送郵件

Rojan Rijal曾發(fā)現(xiàn)了Uber基于SendGrid服務(wù)的某個(gè)可劫持子域名，之后，利用該子域名，他成功攔截了Uber內(nèi)部的公司電郵通信，獲取了Uber官方$10,000美金的獎(jiǎng)勵(lì)。

漏洞詳情（內(nèi)附POC視頻）：https://www.arneswinnen.net/2017/06/authentication-bypass-on-ubers-sso-via-subdomain-takeover/

網(wǎng)絡(luò)釣魚(yú)

由于攻擊者對(duì)相應(yīng)子域有控制權(quán)限，他可以構(gòu)造釣魚(yú)頁(yè)面來(lái)進(jìn)行網(wǎng)絡(luò)釣魚(yú)攻擊，例如一個(gè)銀行的某個(gè)子域存在接管風(fēng)險(xiǎn)時(shí)，攻擊者可以通過(guò)偽造表單來(lái)誘騙用戶輸入銀行卡號(hào)、密碼等敏感信息

CORS跨域資源共享

跨域資源共享，Cross-Origin Resource Sharing (CORS), 允許 Web 應(yīng)用服務(wù)器進(jìn)行跨域的網(wǎng)頁(yè)訪問(wèn)控制。在Web應(yīng)用創(chuàng)建的某個(gè)域中，按照一組規(guī)則來(lái)允許某些網(wǎng)站可以訪問(wèn)提取包括認(rèn)證數(shù)據(jù)在內(nèi)的數(shù)據(jù)信息。以某些子域名是可信域名的前提下，一些Web應(yīng)用還允許子域名執(zhí)行跨域的HTTP請(qǐng)求。當(dāng)你挖掘子域名劫持漏洞時(shí)，可以留意一下COSR頭信息，在BurpSuite Pro專(zhuān)業(yè)版中就有這個(gè)檢測(cè)功能，另外可以看看Web應(yīng)用是否將子域名列入了白名單，這些設(shè)置都可能實(shí)現(xiàn)對(duì)Web授權(quán)用戶的數(shù)據(jù)竊取。

Oauth 授權(quán)白名單化

與跨域資源共享，Oauth 授權(quán)過(guò)程同樣具備一個(gè)白名單機(jī)制，藉此，Web開(kāi)發(fā)者可以指定指定哪個(gè)回調(diào)URIs是可以接受的。這里的風(fēng)險(xiǎn)在于，當(dāng)存在劫持漏洞的子域名被列入這個(gè)白名單中時(shí)，攻擊者可以在Oauth授權(quán)過(guò)程中把用戶會(huì)話重定向到先前那個(gè)存在劫持漏洞的子域名中，以此竊取用戶的
Oauth 授權(quán)信息。

內(nèi)容安全策略（Content-Security Policies）

內(nèi)容安全策略是Web應(yīng)用信任的另一個(gè)主機(jī)列表，CSP的目的在于限制哪些主機(jī)可以在應(yīng)用中執(zhí)行客戶端代碼。如果希望盡量減少跨站腳本的影響，這種方式非常有用。如果你可以劫持控制的子域名包含在白名單中，你就可以繞過(guò)CSP限制，在Web應(yīng)用中執(zhí)行惡意的客戶端代碼。

<pre>curl -sI https://hackerone.com | grep -i "content-security-policy"

content-security-policy: default-src 'none'; base-uri 'self'; block-all-mixed-content; child-src www.youtube-nocookie.co

m; connect-src 'self' www.google-analytics.com errors.hackerone.net; font-src 'self'; form-action 'self'; frame-ancestor

s 'none'; img-src 'self' data: cover-photos.hackerone-user-content.com hackathon-photos.hackerone-user-content.com profi

le-photos.hackerone-user-content.com hackerone-us-west-2-production-attachments.s3-us-west-2.amazonaws.com; media-src 's

elf' hackerone-us-west-2-production-attachments.s3-us-west-2.amazonaws.com; script-src 'self' www.google-analytics.com;

style-src 'self' 'unsafe-inline'; report-uri https://errors.hackerone.net/api/30/csp-report/?sentry_key=61c1e2f50d21487c

97a071737701f598

點(diǎn)擊劫持（ClickJacking）

在browser-security-whitepaper中提到，在X-Frame-Options標(biāo)頭中，IE、Edge和Safari都支持ALLOW-FROM uri機(jī)制，表示該頁(yè)面可以在指定來(lái)源的 frame 中展示，也就是說(shuō)，如果你可劫持控制的子域名在該機(jī)制的白名單中，那么就可以在目標(biāo)網(wǎng)頁(yè)應(yīng)用中構(gòu)建欺騙頁(yè)面，執(zhí)行點(diǎn)擊劫持（ClickJacking）攻擊。

密碼管理器的密碼信息泄露

某些密碼管理器，如LastPass會(huì)在一些主網(wǎng)站所屬的子域名網(wǎng)站中執(zhí)行自動(dòng)密碼填充功能，這相當(dāng)于讓網(wǎng)站設(shè)置了一個(gè)包含明文密碼的非httponly類(lèi)cookie，可以方便子域名劫持之后的深入利用。

Broken Link Hijacking

這種情況下的子域名，并不屬于目標(biāo)網(wǎng)站所有，但卻是用來(lái)運(yùn)行目標(biāo)網(wǎng)站的網(wǎng)頁(yè)內(nèi)容的。也就是說(shuō)，如目標(biāo)網(wǎng)站網(wǎng)頁(yè)內(nèi)容中某個(gè)資源需要從外部導(dǎo)入的第三方資源，舉例來(lái)說(shuō)，像js文件一樣，那么，攻擊者就可以通過(guò)JavaScript的Blob對(duì)象類(lèi)型進(jìn)行導(dǎo)入，從而聲明對(duì)目標(biāo)網(wǎng)站相關(guān)子域名的控制權(quán)限。

這種在網(wǎng)頁(yè)頁(yè)面的主機(jī)劫持可以導(dǎo)致存儲(chǔ)型跨站漏洞，攻擊者可以針對(duì)目標(biāo)網(wǎng)站頁(yè)面，利用這種模式來(lái)加載任意的客戶端代碼。我在此提出這種威脅，就是希望我們不要把想像力只限制在子域名身上，還可以延伸到代碼審查和目標(biāo)網(wǎng)站的主機(jī)映射等方面。

0x04 Where does it come from?

CNAME子域名接管

如果域名通過(guò)CNAME 記錄解析到的第三方服務(wù)可以被注冊(cè)，那么攻擊者就可以聲明對(duì)子域的接管，檢測(cè)流程如下：

1565758573620

像是Amazon S3、Github pages、Heroku、Readme.io都是存在被接管風(fēng)險(xiǎn)的

NS子域名接管

同樣，如果NS記錄解析到的域名可以被接管，源域名也是會(huì)受到子域影響的。使用NS記錄的子域名接管中存在著一個(gè)問(wèn)題是源域名為了冗余和負(fù)載均衡，通常會(huì)具有多個(gè)NS記錄，假設(shè)sub.example.com具有兩個(gè)NS記錄，分別是ns.vulnerable.com和ns.nonvulnerable.com，這時(shí)如果攻擊者接管了ns.vulnerable.com，那么如果有用戶請(qǐng)求sub.example.com時(shí)，由于有兩個(gè)ns記錄，所以有兩種情況：

1. 用戶DNS解析選擇了ns.nonvulnerable.com，由于是合法的DNS，所以用戶會(huì)得到正確的結(jié)果，并且可能會(huì)緩存6到24小時(shí)
2. 用戶DNS解析選擇了ns.vulnerable.com，由于被攻擊者接管，用戶會(huì)得到攻擊者設(shè)定好的結(jié)果，該結(jié)果同樣也會(huì)被緩存，而且由于攻擊者擁有控制權(quán)限，因此可以對(duì)TTL設(shè)置，例如一周

每次緩存條目到期時(shí)，都會(huì)重復(fù)上述過(guò)程。當(dāng)攻擊者選擇使用具有高值的TTL時(shí)，錯(cuò)誤結(jié)果將保留在該時(shí)段的DNS緩存中。在此期間，對(duì)sub.example.com的所有請(qǐng)求都將使用攻擊者緩存的虛假DNS結(jié)果。當(dāng)使用公共DNS解析器（例如，Google DNS）時(shí)，甚至?xí)糯筮@個(gè)攻擊程度。在這種情況下，公共解析器可能會(huì)緩存錯(cuò)誤結(jié)果，這意味著使用相同DNS解析程序的所有用戶將獲得錯(cuò)誤結(jié)果，直到緩存到期。

除了控制源域名外，還可以控制源域名的所有更高級(jí)別的域。這是因?yàn)閾碛蠳S記錄的規(guī)范域名意味著擁有源域名的完整DNS區(qū)域。

2016年，Matthew Bryant 在maris.int上展示了使用NS進(jìn)行子域名接管：

https://thehackerblog.com/the-international-incident-gaining-control-of-a-int-domain-name-with-dns-trickery/index.html

他還展示了如何控制所有.io域名的響應(yīng)

https://thehackerblog.com/the-io-error-taking-control-of-all-io-domains-with-a-targeted-registration/index.html

更多內(nèi)容詳細(xì)參考：https://0xpatrik.com/subdomain-takeover-ns/

MX子域名接管

與NS和CNAME子域名接管相比，MX子域名接管相對(duì)影響較小，因?yàn)?code>MX記錄僅用于接收電子郵件，因此在MX子域名接管僅允許攻擊者接收發(fā)往原域名的電子郵件，可能會(huì)造成網(wǎng)絡(luò)釣魚(yú)攻擊或者竊取相關(guān)信息

云服務(wù)廠商

隨著云服務(wù)的推廣，很多公司組織選擇了云平臺(tái)來(lái)進(jìn)行存儲(chǔ)等功能，云服務(wù)廠商大多數(shù)情況下回生成一個(gè)唯一的域名來(lái)用于訪問(wèn)用戶創(chuàng)建的資源，由于用戶數(shù)量眾多，云服務(wù)上通常選取使用子域來(lái)進(jìn)行表示，一般格式為name-of-customer.cloudprovider.com，其中cloudprovider.com是云服務(wù)提供商的主域。

而如果公司組織注冊(cè)的云服務(wù)是公開(kāi)的（例如：電商平臺(tái)），通常為了便于用戶記憶，公司會(huì)注冊(cè)自己的子域名進(jìn)行鏈接，有兩種方式進(jìn)行鏈接，

1. HTTP 301/302重定向 - 301和302是HTTP響應(yīng)代碼，用于觸發(fā)Web瀏覽器將當(dāng)前URL重定向到另一個(gè)URL。在云服務(wù)的上下文中，第一個(gè)請(qǐng)求是對(duì)組織的域名（例如，shop.organization.com），然后重定向到云提供商的域名（例如，organization.ecommerceprovider.com）
2. HTTP 301/302重定向 - 301和302是HTTP響應(yīng)代碼，用于觸發(fā)Web瀏覽器將當(dāng)前URL重定向到另一個(gè)URL。在云服務(wù)的上下文中，第一個(gè)請(qǐng)求是對(duì)組織的域名（例如，shop.organization.com），然后重定向到云提供商的域名（例如，organization.ecommerceprovider.com）。

如果使用CNAME記錄方法，子域名接管的可能性就會(huì)發(fā)揮作用。即使云提供商擁有規(guī)范域名的基本域，仍然可以進(jìn)行子域接管。

那么我們?nèi)绾稳ふ夷鼙唤庸艿脑品?wù)商呢？我們應(yīng)該盡可能尋找符合如下條件的服務(wù)商。

• 普遍性 - 基于CNAME記錄的統(tǒng)計(jì)信息，優(yōu)先考慮CNAME記錄中使用率最高的云提供商域。
• 支持CNAME記錄 - 如上所述，云提供商需要支持CNAME。
• 域所有權(quán)驗(yàn)證 - 所選的云提供商未驗(yàn)證源域名的所有權(quán)。由于所有者不需要經(jīng)過(guò)驗(yàn)證，因此任何人都可以使用過(guò)期的云配置來(lái)實(shí)現(xiàn)子域名接管。

例如：Amazon S3、Heroku、Shopify、GitHub、Microsoft Azure等，在can-i-take-over-xyz項(xiàng)目中提供了可接管的列表

0x05 How to exploit this vulnerability?

測(cè)試子域接管的流程如下：

1. 設(shè)定范圍
2. 收集子域名
3. 子域名接管驗(yàn)證
4. 報(bào)告輸出

process

這里我以Github Pages為例：

假設(shè)我們有一個(gè)這樣的域名test.djmag.club，我們將CNAME解析到myh4ck1ife.github.io

1565766053267

1565676691860

1565676715283

我們?cè)L問(wèn)一下試試

1565676780902

假如因?yàn)楦鞣N原因，我們的倉(cāng)庫(kù)被刪除了，但是DNS記錄忘了修改，當(dāng)攻擊者訪問(wèn)的時(shí)候就會(huì)發(fā)現(xiàn)：

1565676896298

那么接下來(lái)就可以進(jìn)行接管了：

我們假設(shè)攻擊者是Ecocipher：

這時(shí)候我們首先新建一個(gè)倉(cāng)庫(kù)，

1565678844688

我們新建一個(gè)主頁(yè)來(lái)驗(yàn)證是否接管成功：

1565678908924

接下來(lái)我們創(chuàng)建CNAME文件，并將其指向test.djmag.club

1565680995989

此時(shí)我們?cè)僭L問(wèn)test.djmag.club可以發(fā)現(xiàn)，我們已經(jīng)成功接管了該子域：

1565681024038-1565766393698

同樣的，如果我們編寫(xiě)主頁(yè)插入JavaScript腳本，我們同樣會(huì)觸發(fā)腳本：

1565681218834

1565681265024

0x06 How to Solve the Problem

1. 刪除受影響的DNS記錄 - 最簡(jiǎn)單的解決方案是從DNS區(qū)域中刪除受影響的記錄。如果組織確定不再需要受影響的源域名，則通常使用此步驟。
2. 聲明域名 - 這意味著在特定云提供商或常規(guī)互聯(lián)網(wǎng)域的情況下注冊(cè)資源，重新購(gòu)買(mǎi)過(guò)期域名。

0x07 What should we pay attention to when reporting vulnerabilities?

1. 請(qǐng)確保在你可劫持控制的子域名上部署了屬于你自己的Web內(nèi)容
2. 部署的Web內(nèi)容盡量簡(jiǎn)單干凈
3. 最佳方法就是在你部署的Web內(nèi)容HTML文件注釋中包含了某個(gè)隱秘消息即可，在與廠商聯(lián)系協(xié)調(diào)時(shí)，這就足以證明漏洞問(wèn)題
4. 如果廠商給你授權(quán)，為了說(shuō)明整體的威脅影響，你可以進(jìn)一步對(duì)這種子域名劫持漏洞做出測(cè)試
5. 大多數(shù)情況下，如果你的漏洞報(bào)告中包含了子域名劫持漏洞的利用步驟，廠商都會(huì)都會(huì)認(rèn)可這種漏洞
6. 子域名劫持漏洞屬于高危漏洞，在編寫(xiě)漏洞報(bào)告時(shí)，請(qǐng)認(rèn)真一點(diǎn)

0x08 Reference

1. https://github.com/EdOverflow/can-i-take-over-xyz
2. https://0xpatrik.com/subdomain-takeover-ns/
3. https://hackerone.com/reports/426165
4. https://www.hackerone.com/blog/Guide-Subdomain-Takeovers