# 十三、子域劫持 > 作者：Peter Yaworski > 譯者：[飛龍](https://github.com/) > 協議：[CC BY-NC-SA 4.0](http://creativecommons.org/licenses/by-nc-sa/4.0/) ## 描述 子域控制就真的是聽上去那樣，它是一種場景，惡意用戶能夠代表合法站點來申請一個子域。總之，這一類型的漏洞涉及站點為子域創建 DNS 記錄，例如，Heroku（主機商），并且從未申請過該子域。 1. `example.com`在Heroku 上注冊。 2. `example.com`創建 DNS 記錄`subdomain.example.com`，指向`unicorn457.heroku.com`。 3. `example.com`沒有申請`unicorn457.heroku.com `。 4. 惡意用戶申請了`unicorn457.heroku.com `，并復制了`example.com`。 5. 所有`subdomain.example.com`的流量都會流經惡意網站，它看上去類似`example.com`。 所以，按照這個邏輯，DNS 條目需要指向未申請的外部服務，例如 Heroku，Github 和 Amazon S3。發現它們的一個不錯的方法是使用 KnockPy，它會在工具一節中討論，它迭代了子域的常見列表來驗證是否存在。 ## 示例 1\. Ubiquiti 子域劫持 難度：低 URL：`http://assets.goubiquiti.com` 報告鏈接：`https://hackerone.com/reports/109699` 報告日期：2016.1.10 獎金：$500 描述： 就像子域劫持的描述中所述，`http://assets.goubiquiti.com`擁有指向 Amazon S3 文件存儲的 DNS 記錄，但是不存在實際的 Amazon S3 容器。這里是 HackerOne 的截圖：  因此，惡意用戶可以申請`uwn-images.s3-website-us-west-1.amazonaws.com `，并在這里部署站點。假設它可以更加類似 Ubiquiti，這里的漏洞是誘使用戶來提交個人信息，并控制賬戶。 > 重要結論 > DNS 記錄提供了全新并獨特的漏洞利用機會。使用KnockPy 來嘗試驗證子域是否存在，之后確認它們指向有效的資源，并且特別注意三方服務，例如 AWS、Github、Zendesk 以及其他。這些服務允許你注冊自定義的 URL。 ### 2\. Scan.me 的 Zendesk 指向 難度：低 URL：`support.scan.me ` 報告鏈接：`https://hackerone.com/reports/114134` 報告日期：2016.2.2 獎金：$1000 描述： 就像 Ubiquiti 的示例那樣，這里 Scan.me 擁有一個 DNS 記錄，將`support.scan.me `指向` scan.zendesk.com`。這種情況下，黑客` harry_mg `就能夠申請` scan.zendesk.com`，`support.scan.me`指向了它。 就是這樣了，獎金是 $1000。 > 重要結論 > 要注意！這個漏洞與 2016 年 2 月發現，并且完全不復雜。成功的漏洞挖掘需要敏銳的觀察。 ### 3\. Facebook 官方的訪問 Token 難度：高 URL：`facebook.com` 報告鏈接：`http://philippeharewood.com/swiping-facebook-official-access-tokens` 報告日期：2016.2.29 獎金：未公開 描述： 我不知道這是否符合子域劫持的技術定義（如果有的話），但是我覺得這是個重大的發現，讓 Philippe 能夠以最少的交互劫持任意 Facebook 賬戶。 為了理解這個漏洞，我們需要看一看 OAuth，根據他們的站點，它是一個開放協議，能夠以簡單和標準的方式來驗證 Web 移動和桌面應用的安全性。換句話說，OAuth 允許用戶授權某個應用來代表它們，而不需要向應用分享密碼。如果你曾經瀏覽器過某個站點，它讓你使用你的 Google、Facebook、Twitter 以及其他賬戶來登錄，你就使用了 OAuth。 現在，假設你注意到了這里的潛在利用。如果 OAuth 允許用戶授權，錯誤實現的影響非常之大。理解了這個過程之后，Philippe 提供了一副不錯的圖片來解釋協議是如何實現的。  Philippe Harewood - Facebook OAuth 流程 總之，我們可以在這里看到： 1. 用戶通過一些 APP 請求將 Facebook API 使用一些目的。 2. 這個 APP 將用戶重定向到 Facebook API 來授予權限。 3. Facebook API 向用戶提供代碼并將其重定向到 APP。 4. APP 接受代碼并調用 Facebook API 來獲得 Token。 5. Facebook 返回 Token 給 APP，它代表用于為調用授權。 這個流程中，你會注意到用戶在哪兒都不需要向訪問它們賬戶的 APP 提供他們的 Facebook 用戶名和密碼。這也是個概覽，這里也可能出現很多其他事情，包括可以在流程中交換的額外信息。 這里有一個重大漏洞，Facebook 在 #5 中向應用提供訪問 Token。 再回頭考慮 Philippe 的發現，它詳細解釋了如何嘗試并捕獲這些 Token，來誘使 Facebook 向他發送它們，而不是那個應用。但是，反之，它決定尋找能夠控制的，存在漏洞的 Facebook 應用。 結果，每個 Facebook 用戶都使用它們的賬戶授權的應用，但是許多都不顯式使用。根據他的 Write Up，一個例子是“Content Tab of a Page on www”，它在 Facebook 粉絲頁面加載了一些 API 調用。APP 的列表課在`https://www.facebook.com/search/me/apps-used`上獲取。 瀏覽器這個列表之后，Philippe 設法找到了一個 APP，它的配置是錯誤的，并且可用于使用請求來捕獲 Token，請求為： ``` https://facebook.com/v2.5/dialog/oauth?response_type=token&display=popup&client_id=APP_ID&redirect_uri=REDIRECT_URI ``` 這里，它所使用來獲取`APP_ID`的應用，是擁有完整權限并配置錯誤的，意思是步驟 #1 和 #2 已經完成了，用戶不會看到彈出窗口來向應用授予權限，因為它們實際上已經完成了。此外，由于 Facebook 并不持有`REDIRECT_URI`，Philippe 實際上可以持有它，準確來說就像子域那樣。因此，當用戶點擊了它的鏈接，它們會重定向到： http://REDIRECT_URI/access_token_appended_here Philippe 可以使用它來記錄所有訪問 Token，并劫持 Facebook 賬戶。更加 NB 的是，根據它的博文，一旦你擁有了官方的 Facebook 訪問 Token，你就擁有了萊斯其他 Facebook 應用的 Token，例如 Instagram。他需要做的所有事情就是調用 Facebook GraphQL（一個用于從 Facebook 獲取數據的 API），響應就會包含用于請求中 APP 的`access_token`。 > 重要結論 > 我覺得你可能想知道，為什么這個例子會包含在這本書的這個章節。對我來說，最重要的結論就是。要考慮到在滲透過程中如何利用一些遺留資源。在這一章的上一個例子中，DNS 指向了不再繼續使用的服務。這里，尋找了預先審批了不再使用的應用。當你滲透的時候，要尋找這些應用的變化，它們可能會給你留下公開的資源。 > 此外，如果你喜歡這個例子，你可以查看 Philippe 的博客（包含在資源一章，以及“ Hacking Pro Tips Interview”，這是他坐下來和我一起完成的，他提供了很多不錯的建議）。 ## 總結 當一個站點已經創建了無用的 DNS 記錄，指向三方服務提供商，子域劫持真的不難以完成。有很多方法來發現它們，包括使用 KnockPy，Google Hack（`site:*.hackerone.com`），Recon-ng，以及其他。這些東西的用法都包含在這本書的工具一章。 此外，就像前面那個 Facebook 訪問 Token 的示例那樣，當你考慮這種類型的漏洞時，擴展你的領域，并且考慮目標上存在什么過時的遺留資源。例如，` redirect_uri`和預先審批的 Facebook APP。