自動探測
自動化探測利用腳本正在完善優(yōu)化中凡纳，歡迎各位師傅試用交流：https://github.com/Echocipher/Subdomain-Takeover
如果您在使用中遇到了一些Bug肋杖，或者建議栏饮，期待您的交流：echocipher@163.com
0x00 What is Subdomain Takeover?
子域名接管是由于錯誤配置等原因，對應(yīng)主機指向了一個當前未在使用或已經(jīng)刪除的特定服務(wù)（例如：Github pages，Heroku等）优炬，攻擊者可以通過接管子域來獲取對另一個域的控制權(quán)的風險點疏叨。通常情形如下：
- 域名使用
CNAME記錄到了另一個域（例如，sub.example.comCNAMEanotherdomain.com）
- anotherdomain`到期并可以被任何人注冊
- 由于未
example.comDNS區(qū)域刪除CNAME記錄穿剖，因此攻擊者注冊anotherdomain.com后可以控制sub.example.com
如果上述存在的話蚤蔓，任何注冊anotherdomain.com的人都可以控制sub.example.com直到DNS記錄失效，攻擊者可以利用這一點構(gòu)造釣魚頁面糊余、執(zhí)行跨站腳本攻擊（XSS）等等
子域名接管不僅僅限于CNAME記錄秀又，NS,MX甚至A記錄也會受到影響。
0x02 How does it come about?
Transparency To Browser
上圖記錄了涉及CNAME的DNS解析贬芥，在第7步中吐辙，瀏覽器請求sub.example.com而不是anotherdomain，即使是使用了CNAME記錄蘸劈，瀏覽器中的URL欄目中扔包含sub.example.com, Web瀏覽器會信任DNS解析后返回的內(nèi)容昏苏，這也就導(dǎo)致當攻擊者能控制DNS記錄的時候，當我們請求sub.example.com時威沫，瀏覽器接收到攻擊者設(shè)置的A記錄的值贤惯，瀏覽器認為這是合法的，就會顯示從該服務(wù)器接收到的所有內(nèi)容棒掠，通過這一點攻擊者就可以繞過Web瀏覽器的安全性檢測（例如：同源策略）孵构，而且由于子域接管不是常規(guī)的中間人攻擊，所以TLS/SSL并不能解決該問題烟很，甚至通過生成有效的SSL證書還可以使得攻擊場景更加完善颈墅。
SSL證書
例如Let’s Encrypt等證書機構(gòu)允許通過內(nèi)容自動驗證域名所有權(quán)：
攻擊者由于可以控制子域內(nèi)容，因此按照Let’s Encrypt的要求在特定的URL路徑上放置特定內(nèi)容之后雾袱，Let’s Encrypt 將會自動完成證書的驗證恤筛，然后批準為給定域發(fā)放證書，這大大降低了用戶對網(wǎng)絡(luò)釣魚的識別度芹橡。
0x03 What will it lead to?
由于子域名接管導(dǎo)致的問題毒坛，很多漏洞賞金廠商已經(jīng)開始接收子域名接管的漏洞，從賞金方面我們可以推測出廠商對問題的重視程度：
那么子域名接管都會導(dǎo)致哪些問題呢僻族？
Cookie竊取
瀏覽器實施了很多安全策略從而保證用戶不受惡意網(wǎng)站傷害粘驰，其中包括同源策略等內(nèi)容，瀏覽器主要安全職責之一就是保護已經(jīng)存在的Cookie，由于雖然HTTP是無狀態(tài)協(xié)議丧诺，但是為了方便用戶登錄冗美，所以會采用Cookie充當?shù)卿浟钆疲瑸g覽器識別過后驗證用戶身份乖仇，而Cookie可以跨子域共享，例如當網(wǎng)站使用基于Cookie的單點登錄系統(tǒng)時势誊，用戶可以使用一個子域登錄剑梳，并且在各種子域中共享相同的會話令牌唆貌，設(shè)置常規(guī)Cookie的語法如下：
HTTP/1.1 200 OK
Set-Cookie: name=value
如果這個Cookie是由example.com所在的web服務(wù)器發(fā)出的，那么只有這個服務(wù)器才可以訪問到這個Cookie垢乙，但是可以通過以下方式為通配符域發(fā)布Cookie：
HTTP/1.1 200 OK
Set-Cookie: name=value; domain=example.com
這樣Cookie可以存在于對example.com的HTTP請求中锨咙，也可以包含在任何其他子域里面（例如：subdomain.example.com），這樣導(dǎo)致使用子域名接管來進行攻擊追逮，例如某個特定的域使用Cookie用于通配符域酪刀，那么如果有一個子域遭受到攻擊者子域接管，如果用戶訪問了該子域钮孵，Cookie會隨HTTP請求自動發(fā)送骂倘，這樣會導(dǎo)致HttpOnly cookie被繞過，
HttpOnly cookie - 默認情況下巴席，Cookie可以通過在創(chuàng)建cookie的網(wǎng)站上下文中運行的Javascript代碼訪問历涝。Javascript可以讀取，更新和刪除cookie漾唉。HttpOnly cookie標志（由Web服務(wù)器設(shè)置）表示Javascript代碼無法訪問特定cookie荧库。獲取它的唯一方法是通過HTTP請求和響應(yīng)標頭。
而上文我們又介紹了攻擊者可以生成SSL證書赵刑，因此瀏覽器的另一安全機制Secure cookie也會被繞過
Secure cookie - 當cookie具有由Web服務(wù)器設(shè)置的安全標志時电爹，只有在使用HTTPS時才能將其傳送回Web服務(wù)器。
當子域接管被利用后料睛，攻擊者通過欺騙用戶訪問自己控制的子域丐箩，由于沒有使用JavaScript訪問Cookie，又可以生成SSL證書恤煞，所以可以繞過這兩個安全機制來竊取用戶Cookie
Arne Swinnen在hackerone的報告中詳細的介紹了攻擊過程：https://hackerone.com/reports/172137
而且由于JavaScript腳本是攻擊者可以控制的屎勘，因此攻擊者接管后可以進行更多其他的攻擊。
但是有一種辦法可以保護瀏覽器中JavaScript腳本的完整性居扒，Subresource Integrity提出了一種機制概漱，將加密哈希添加到script中，
<script src="https://example.com/example-framework.js"
integrity="sha384-Li9vy3DqF8tnTXuiaAJuML3ky+er10rcgNR/VqsVpcw+ThHmYcwiB1pbOxEbzJr7"
crossorigin="anonymous"></script>
當提供的加密哈希與下載文件不匹配時喜喂，瀏覽器將會拒絕執(zhí)行它瓤摧。
電子郵件
當可以進行CNAME子域接管的時候。攻擊者可以將MX設(shè)置為任意Web服務(wù)器玉吁，這會允許接收電子郵件到某個子域中照弥，攻擊者通常會使用欺騙Return-Path header的方法接收電子郵件的回復(fù)。在網(wǎng)絡(luò)釣魚攻擊中經(jīng)常大范圍使用进副，同時这揣，由于SPF將配置存儲在DNS TXT記錄中，當子域被接管的時候，攻擊者同樣可以控制TXT 記錄给赞，就可以繞過SPF檢查來發(fā)送郵件
Rojan Rijal曾發(fā)現(xiàn)了Uber基于SendGrid服務(wù)的某個可劫持子域名机打，之后，利用該子域名片迅，他成功攔截了Uber內(nèi)部的公司電郵通信残邀，獲取了Uber官方$10,000美金的獎勵。
漏洞詳情（內(nèi)附POC視頻）：https://www.arneswinnen.net/2017/06/authentication-bypass-on-ubers-sso-via-subdomain-takeover/
網(wǎng)絡(luò)釣魚
由于攻擊者對相應(yīng)子域有控制權(quán)限柑蛇，他可以構(gòu)造釣魚頁面來進行網(wǎng)絡(luò)釣魚攻擊罐旗，例如一個銀行的某個子域存在接管風險時，攻擊者可以通過偽造表單來誘騙用戶輸入銀行卡號唯蝶、密碼等敏感信息
CORS跨域資源共享
跨域資源共享九秀，Cross-Origin Resource Sharing (CORS), 允許 Web 應(yīng)用服務(wù)器進行跨域的網(wǎng)頁訪問控制。在Web應(yīng)用創(chuàng)建的某個域中粘我，按照一組規(guī)則來允許某些網(wǎng)站可以訪問提取包括認證數(shù)據(jù)在內(nèi)的數(shù)據(jù)信息鼓蜒。以某些子域名是可信域名的前提下，一些Web應(yīng)用還允許子域名執(zhí)行跨域的HTTP請求征字。當你挖掘子域名劫持漏洞時都弹，可以留意一下COSR頭信息，在BurpSuite Pro專業(yè)版中就有這個檢測功能匙姜，另外可以看看Web應(yīng)用是否將子域名列入了白名單畅厢，這些設(shè)置都可能實現(xiàn)對Web授權(quán)用戶的數(shù)據(jù)竊取。
Oauth 授權(quán)白名單化
與跨域資源共享氮昧，Oauth 授權(quán)過程同樣具備一個白名單機制框杜，藉此，Web開發(fā)者可以指定指定哪個回調(diào)URIs是可以接受的袖肥。這里的風險在于咪辱，當存在劫持漏洞的子域名被列入這個白名單中時，攻擊者可以在Oauth授權(quán)過程中把用戶會話重定向到先前那個存在劫持漏洞的子域名中椎组，以此竊取用戶的
Oauth 授權(quán)信息油狂。
內(nèi)容安全策略（Content-Security Policies）
內(nèi)容安全策略是Web應(yīng)用信任的另一個主機列表，CSP的目的在于限制哪些主機可以在應(yīng)用中執(zhí)行客戶端代碼寸癌。如果希望盡量減少跨站腳本的影響专筷，這種方式非常有用。如果你可以劫持控制的子域名包含在白名單中蒸苇，你就可以繞過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
點擊劫持（ClickJacking）
在browser-security-whitepaper中提到填渠，在X-Frame-Options標頭中弦聂，IE鸟辅、Edge和Safari都支持ALLOW-FROM uri機制氛什，表示該頁面可以在指定來源的 frame 中展示莺葫，也就是說，如果你可劫持控制的子域名在該機制的白名單中枪眉，那么就可以在目標網(wǎng)頁應(yīng)用中構(gòu)建欺騙頁面捺檬，執(zhí)行點擊劫持（ClickJacking）攻擊。
密碼管理器的密碼信息泄露
某些密碼管理器贸铜，如LastPass會在一些主網(wǎng)站所屬的子域名網(wǎng)站中執(zhí)行自動密碼填充功能堡纬，這相當于讓網(wǎng)站設(shè)置了一個包含明文密碼的非httponly類cookie，可以方便子域名劫持之后的深入利用蒿秦。
Broken Link Hijacking
這種情況下的子域名烤镐，并不屬于目標網(wǎng)站所有，但卻是用來運行目標網(wǎng)站的網(wǎng)頁內(nèi)容的棍鳖。也就是說炮叶，如目標網(wǎng)站網(wǎng)頁內(nèi)容中某個資源需要從外部導(dǎo)入的第三方資源，舉例來說渡处，像js文件一樣镜悉，那么，攻擊者就可以通過JavaScript的Blob對象類型進行導(dǎo)入医瘫，從而聲明對目標網(wǎng)站相關(guān)子域名的控制權(quán)限侣肄。
這種在網(wǎng)頁頁面的主機劫持可以導(dǎo)致存儲型跨站漏洞，攻擊者可以針對目標網(wǎng)站頁面醇份，利用這種模式來加載任意的客戶端代碼稼锅。我在此提出這種威脅，就是希望我們不要把想像力只限制在子域名身上僚纷，還可以延伸到代碼審查和目標網(wǎng)站的主機映射等方面缰贝。
0x04 Where does it come from?
CNAME子域名接管
如果域名通過CNAME 記錄解析到的第三方服務(wù)可以被注冊，那么攻擊者就可以聲明對子域的接管畔濒，檢測流程如下：
像是Amazon S3剩晴、Github pages、Heroku侵状、Readme.io都是存在被接管風險的
NS子域名接管
同樣赞弥，如果NS記錄解析到的域名可以被接管，源域名也是會受到子域影響的趣兄。使用NS記錄的子域名接管中存在著一個問題是源域名為了冗余和負載均衡绽左，通常會具有多個NS記錄，假設(shè)sub.example.com具有兩個NS記錄艇潭，分別是ns.vulnerable.com和ns.nonvulnerable.com拼窥，這時如果攻擊者接管了ns.vulnerable.com戏蔑，那么如果有用戶請求sub.example.com時，由于有兩個ns記錄鲁纠，所以有兩種情況：
- 用戶DNS解析選擇了
ns.nonvulnerable.com总棵，由于是合法的DNS，所以用戶會得到正確的結(jié)果改含，并且可能會緩存6到24小時 - 用戶DNS解析選擇了
ns.vulnerable.com情龄，由于被攻擊者接管，用戶會得到攻擊者設(shè)定好的結(jié)果捍壤，該結(jié)果同樣也會被緩存骤视，而且由于攻擊者擁有控制權(quán)限，因此可以對TTL設(shè)置鹃觉，例如一周
每次緩存條目到期時专酗，都會重復(fù)上述過程。當攻擊者選擇使用具有高值的TTL時祷肯，錯誤結(jié)果將保留在該時段的DNS緩存中。在此期間粱玲，對sub.example.com的所有請求都將使用攻擊者緩存的虛假DNS結(jié)果躬柬。當使用公共DNS解析器（例如，Google DNS）時抽减，甚至會放大這個攻擊程度允青。在這種情況下，公共解析器可能會緩存錯誤結(jié)果卵沉，這意味著使用相同DNS解析程序的所有用戶將獲得錯誤結(jié)果颠锉，直到緩存到期。
除了控制源域名外史汗，還可以控制源域名的所有更高級別的域琼掠。這是因為擁有NS記錄的規(guī)范域名意味著擁有源域名的完整DNS區(qū)域。
2016年停撞，Matthew Bryant 在maris.int上展示了使用NS進行子域名接管：
他還展示了如何控制所有.io域名的響應(yīng)
更多內(nèi)容詳細參考：https://0xpatrik.com/subdomain-takeover-ns/
MX子域名接管
與NS和CNAME子域名接管相比瓷蛙，MX子域名接管相對影響較小，因為MX記錄僅用于接收電子郵件戈毒，因此在MX子域名接管僅允許攻擊者接收發(fā)往原域名的電子郵件艰猬，可能會造成網(wǎng)絡(luò)釣魚攻擊或者竊取相關(guān)信息
云服務(wù)廠商
隨著云服務(wù)的推廣，很多公司組織選擇了云平臺來進行存儲等功能埋市，云服務(wù)廠商大多數(shù)情況下回生成一個唯一的域名來用于訪問用戶創(chuàng)建的資源冠桃，由于用戶數(shù)量眾多，云服務(wù)上通常選取使用子域來進行表示道宅，一般格式為name-of-customer.cloudprovider.com食听，其中cloudprovider.com是云服務(wù)提供商的主域胸蛛。
而如果公司組織注冊的云服務(wù)是公開的（例如：電商平臺），通常為了便于用戶記憶樱报，公司會注冊自己的子域名進行鏈接葬项，有兩種方式進行鏈接，
- HTTP 301/302重定向 - 301和302是HTTP響應(yīng)代碼肃弟，用于觸發(fā)Web瀏覽器將當前URL重定向到另一個URL玷室。在云服務(wù)的上下文中零蓉，第一個請求是對組織的域名（例如笤受，shop.organization.com），然后重定向到云提供商的域名（例如敌蜂，organization.ecommerceprovider.com）
- HTTP 301/302重定向 - 301和302是HTTP響應(yīng)代碼箩兽，用于觸發(fā)Web瀏覽器將當前URL重定向到另一個URL。在云服務(wù)的上下文中章喉，第一個請求是對組織的域名（例如汗贫，shop.organization.com），然后重定向到云提供商的域名（例如秸脱，organization.ecommerceprovider.com）落包。
如果使用CNAME記錄方法，子域名接管的可能性就會發(fā)揮作用摊唇。即使云提供商擁有規(guī)范域名的基本域咐蝇，仍然可以進行子域接管。
那么我們?nèi)绾稳ふ夷鼙唤庸艿脑品?wù)商呢巷查？我們應(yīng)該盡可能尋找符合如下條件的服務(wù)商有序。
- 普遍性 - 基于CNAME記錄的統(tǒng)計信息，優(yōu)先考慮CNAME記錄中使用率最高的云提供商域岛请。
- 支持CNAME記錄 - 如上所述旭寿，云提供商需要支持CNAME。
- 域所有權(quán)驗證 - 所選的云提供商未驗證源域名的所有權(quán)崇败。由于所有者不需要經(jīng)過驗證盅称，因此任何人都可以使用過期的云配置來實現(xiàn)子域名接管。
例如：Amazon S3后室、Heroku缩膝、Shopify、GitHub咧擂、Microsoft Azure等逞盆，在can-i-take-over-xyz項目中提供了可接管的列表
0x05 How to exploit this vulnerability?
測試子域接管的流程如下：
- 設(shè)定范圍
- 收集子域名
- 子域名接管驗證
- 報告輸出
這里我以Github Pages為例：
假設(shè)我們有一個這樣的域名test.djmag.club，我們將CNAME解析到myh4ck1ife.github.io
我們訪問一下試試
假如因為各種原因松申，我們的倉庫被刪除了云芦，但是DNS記錄忘了修改俯逾，當攻擊者訪問的時候就會發(fā)現(xiàn)：
那么接下來就可以進行接管了：
我們假設(shè)攻擊者是Ecocipher：
這時候我們首先新建一個倉庫，
我們新建一個主頁來驗證是否接管成功：
接下來我們創(chuàng)建CNAME文件舅逸，并將其指向test.djmag.club
此時我們再訪問test.djmag.club可以發(fā)現(xiàn)桌肴，我們已經(jīng)成功接管了該子域：
同樣的，如果我們編寫主頁插入JavaScript腳本琉历，我們同樣會觸發(fā)腳本：
0x06 How to Solve the Problem
- 刪除受影響的DNS記錄 - 最簡單的解決方案是從DNS區(qū)域中刪除受影響的記錄坠七。如果組織確定不再需要受影響的源域名，則通常使用此步驟旗笔。
- 聲明域名 - 這意味著在特定云提供商或常規(guī)互聯(lián)網(wǎng)域的情況下注冊資源彪置，重新購買過期域名。
0x07 What should we pay attention to when reporting vulnerabilities?
- 請確保在你可劫持控制的子域名上部署了屬于你自己的Web內(nèi)容
- 部署的Web內(nèi)容盡量簡單干凈
- 最佳方法就是在你部署的Web內(nèi)容HTML文件注釋中包含了某個隱秘消息即可蝇恶，在與廠商聯(lián)系協(xié)調(diào)時拳魁，這就足以證明漏洞問題
- 如果廠商給你授權(quán)，為了說明整體的威脅影響撮弧，你可以進一步對這種子域名劫持漏洞做出測試
- 大多數(shù)情況下潘懊，如果你的漏洞報告中包含了子域名劫持漏洞的利用步驟，廠商都會都會認可這種漏洞
- 子域名劫持漏洞屬于高危漏洞贿衍，在編寫漏洞報告時授舟，請認真一點
