十三敏弃、子域劫持
作者：Peter Yaworski
譯者：飛龍
協(xié)議：CC BY-NC-SA 4.0
描述
子域控制就真的是聽(tīng)上去那樣卦羡，它是一種場(chǎng)景，惡意用戶能夠代表合法站點(diǎn)來(lái)申請(qǐng)一個(gè)子域麦到÷潭總之，這一類型的漏洞涉及站點(diǎn)為子域創(chuàng)建 DNS 記錄瓶颠，例如拟赊，Heroku（主機(jī)商），并且從未申請(qǐng)過(guò)該子域粹淋。
example.com在Heroku 上注冊(cè)吸祟。example.com創(chuàng)建 DNS 記錄subdomain.example.com，指向unicorn457.heroku.com桃移。example.com沒(méi)有申請(qǐng)unicorn457.heroku.com屋匕。惡意用戶申請(qǐng)了
unicorn457.heroku.com，并復(fù)制了example.com借杰。所有
subdomain.example.com的流量都會(huì)流經(jīng)惡意網(wǎng)站过吻，它看上去類似example.com。
所以蔗衡，按照這個(gè)邏輯纤虽，DNS 條目需要指向未申請(qǐng)的外部服務(wù)，例如 Heroku粘都，Github 和 Amazon S3。發(fā)現(xiàn)它們的一個(gè)不錯(cuò)的方法是使用 KnockPy刷袍，它會(huì)在工具一節(jié)中討論翩隧，它迭代了子域的常見(jiàn)列表來(lái)驗(yàn)證是否存在。
示例
1. Ubiquiti 子域劫持
難度：低
URL：http://assets.goubiquiti.com
報(bào)告鏈接：https://hackerone.com/reports/109699
報(bào)告日期：2016.1.10
獎(jiǎng)金：$500
描述：
就像子域劫持的描述中所述呻纹，http://assets.goubiquiti.com擁有指向 Amazon S3 文件存儲(chǔ)的 DNS 記錄堆生，但是不存在實(shí)際的 Amazon S3 容器。這里是 HackerOne 的截圖：
因此雷酪，惡意用戶可以申請(qǐng)uwn-images.s3-website-us-west-1.amazonaws.com淑仆，并在這里部署站點(diǎn)。假設(shè)它可以更加類似 Ubiquiti哥力，這里的漏洞是誘使用戶來(lái)提交個(gè)人信息蔗怠，并控制賬戶墩弯。
重要結(jié)論
DNS 記錄提供了全新并獨(dú)特的漏洞利用機(jī)會(huì)。使用KnockPy 來(lái)嘗試驗(yàn)證子域是否存在寞射，之后確認(rèn)它們指向有效的資源渔工，并且特別注意三方服務(wù)，例如 AWS桥温、Github引矩、Zendesk 以及其他。這些服務(wù)允許你注冊(cè)自定義的 URL侵浸。
2. Scan.me 的 Zendesk 指向
難度：低
URL：support.scan.me
報(bào)告鏈接：https://hackerone.com/reports/114134
報(bào)告日期：2016.2.2
獎(jiǎng)金：$1000
描述：
就像 Ubiquiti 的示例那樣旺韭，這里 Scan.me 擁有一個(gè) DNS 記錄，將support.scan.me指向scan.zendesk.com掏觉。這種情況下区端，黑客harry_mg就能夠申請(qǐng)scan.zendesk.com，support.scan.me指向了它履腋。
就是這樣了珊燎，獎(jiǎng)金是 $1000。
重要結(jié)論
要注意遵湖！這個(gè)漏洞與 2016 年 2 月發(fā)現(xiàn)悔政，并且完全不復(fù)雜。成功的漏洞挖掘需要敏銳的觀察延旧。
3. Facebook 官方的訪問(wèn) Token
難度：高
URL：facebook.com
報(bào)告鏈接：http://philippeharewood.com/swiping-facebook-official-access-tokens
報(bào)告日期：2016.2.29
獎(jiǎng)金：未公開(kāi)
描述：
我不知道這是否符合子域劫持的技術(shù)定義（如果有的話）谋国，但是我覺(jué)得這是個(gè)重大的發(fā)現(xiàn)，讓 Philippe 能夠以最少的交互劫持任意 Facebook 賬戶迁沫。
為了理解這個(gè)漏洞芦瘾，我們需要看一看 OAuth，根據(jù)他們的站點(diǎn)集畅，它是一個(gè)開(kāi)放協(xié)議近弟，能夠以簡(jiǎn)單和標(biāo)準(zhǔn)的方式來(lái)驗(yàn)證 Web 移動(dòng)和桌面應(yīng)用的安全性。換句話說(shuō)挺智，OAuth 允許用戶授權(quán)某個(gè)應(yīng)用來(lái)代表它們祷愉，而不需要向應(yīng)用分享密碼。如果你曾經(jīng)瀏覽器過(guò)某個(gè)站點(diǎn)赦颇，它讓你使用你的 Google二鳄、Facebook、Twitter 以及其他賬戶來(lái)登錄媒怯，你就使用了 OAuth订讼。
現(xiàn)在，假設(shè)你注意到了這里的潛在利用扇苞。如果 OAuth 允許用戶授權(quán)欺殿，錯(cuò)誤實(shí)現(xiàn)的影響非常之大寄纵。理解了這個(gè)過(guò)程之后，Philippe 提供了一副不錯(cuò)的圖片來(lái)解釋協(xié)議是如何實(shí)現(xiàn)的祈餐。
Philippe Harewood - Facebook OAuth 流程
總之擂啥，我們可以在這里看到：
用戶通過(guò)一些 APP 請(qǐng)求將 Facebook API 使用一些目的。
這個(gè) APP 將用戶重定向到 Facebook API 來(lái)授予權(quán)限帆阳。
Facebook API 向用戶提供代碼并將其重定向到 APP哺壶。
APP 接受代碼并調(diào)用 Facebook API 來(lái)獲得 Token。
Facebook 返回 Token 給 APP蜒谤，它代表用于為調(diào)用授權(quán)山宾。
這個(gè)流程中，你會(huì)注意到用戶在哪兒都不需要向訪問(wèn)它們賬戶的 APP 提供他們的 Facebook 用戶名和密碼鳍徽。這也是個(gè)概覽资锰，這里也可能出現(xiàn)很多其他事情，包括可以在流程中交換的額外信息阶祭。
這里有一個(gè)重大漏洞绷杜，F(xiàn)acebook 在 #5 中向應(yīng)用提供訪問(wèn) Token。
再回頭考慮 Philippe 的發(fā)現(xiàn)濒募，它詳細(xì)解釋了如何嘗試并捕獲這些 Token鞭盟，來(lái)誘使 Facebook 向他發(fā)送它們，而不是那個(gè)應(yīng)用瑰剃。但是齿诉，反之，它決定尋找能夠控制的晌姚，存在漏洞的 Facebook 應(yīng)用粤剧。
結(jié)果，每個(gè) Facebook 用戶都使用它們的賬戶授權(quán)的應(yīng)用挥唠，但是許多都不顯式使用抵恋。根據(jù)他的 Write Up，一個(gè)例子是“Content Tab of a Page on www”宝磨，它在 Facebook 粉絲頁(yè)面加載了一些 API 調(diào)用弧关。APP 的列表課在https://www.facebook.com/search/me/apps-used上獲取。
瀏覽器這個(gè)列表之后懊烤，Philippe 設(shè)法找到了一個(gè) APP梯醒，它的配置是錯(cuò)誤的宽堆，并且可用于使用請(qǐng)求來(lái)捕獲 Token腌紧，請(qǐng)求為：
https://facebook.com/v2.5/dialog/oauth?response_type=token&display=popup&client_id=APP_ID&redirect_uri=REDIRECT_URI
這里，它所使用來(lái)獲取APP_ID的應(yīng)用畜隶，是擁有完整權(quán)限并配置錯(cuò)誤的壁肋，意思是步驟 #1 和 #2 已經(jīng)完成了号胚，用戶不會(huì)看到彈出窗口來(lái)向應(yīng)用授予權(quán)限，因?yàn)樗鼈儗?shí)際上已經(jīng)完成了浸遗。此外猫胁，由于 Facebook 并不持有REDIRECT_URI，Philippe 實(shí)際上可以持有它跛锌，準(zhǔn)確來(lái)說(shuō)就像子域那樣弃秆。因此，當(dāng)用戶點(diǎn)擊了它的鏈接髓帽，它們會(huì)重定向到：
http://REDIRECT_URI/access_token_appended_here
Philippe 可以使用它來(lái)記錄所有訪問(wèn) Token菠赚，并劫持 Facebook 賬戶。更加 NB 的是郑藏，根據(jù)它的博文衡查，一旦你擁有了官方的 Facebook 訪問(wèn) Token，你就擁有了萊斯其他 Facebook 應(yīng)用的 Token必盖，例如 Instagram拌牲。他需要做的所有事情就是調(diào)用 Facebook GraphQL（一個(gè)用于從 Facebook 獲取數(shù)據(jù)的 API），響應(yīng)就會(huì)包含用于請(qǐng)求中 APP 的access_token歌粥。
重要結(jié)論
我覺(jué)得你可能想知道塌忽，為什么這個(gè)例子會(huì)包含在這本書(shū)的這個(gè)章節(jié)。對(duì)我來(lái)說(shuō)阁吝，最重要的結(jié)論就是砚婆。要考慮到在滲透過(guò)程中如何利用一些遺留資源。在這一章的上一個(gè)例子中突勇，DNS 指向了不再繼續(xù)使用的服務(wù)装盯。這里，尋找了預(yù)先審批了不再使用的應(yīng)用甲馋。當(dāng)你滲透的時(shí)候埂奈，要尋找這些應(yīng)用的變化，它們可能會(huì)給你留下公開(kāi)的資源定躏。
此外账磺，如果你喜歡這個(gè)例子，你可以查看 Philippe 的博客（包含在資源一章痊远，以及“ Hacking Pro Tips Interview”垮抗，這是他坐下來(lái)和我一起完成的，他提供了很多不錯(cuò)的建議）碧聪。
總結(jié)
當(dāng)一個(gè)站點(diǎn)已經(jīng)創(chuàng)建了無(wú)用的 DNS 記錄冒版，指向三方服務(wù)提供商，子域劫持真的不難以完成逞姿。有很多方法來(lái)發(fā)現(xiàn)它們辞嗡，包括使用 KnockPy捆等，Google Hack（site:*.hackerone.com），Recon-ng续室，以及其他栋烤。這些東西的用法都包含在這本書(shū)的工具一章。
此外挺狰，就像前面那個(gè) Facebook 訪問(wèn) Token 的示例那樣明郭，當(dāng)你考慮這種類型的漏洞時(shí)，擴(kuò)展你的領(lǐng)域丰泊，并且考慮目標(biāo)上存在什么過(guò)時(shí)的遺留資源达址。例如，redirect_uri和預(yù)先審批的 Facebook APP趁耗。
