看我如何接管55000個子域名
一、前言
本文介紹了我們識別Shopify平臺上的子域名接管漏洞的具體過程，該漏洞影響超過55,000個子域名。
首先我們得澄清一下，這個問題並不僅限於Shopify平臺，對其他常見的雲服務提供商來說也很常見。在過去幾周/幾天內，我們聯絡了幾個不同的雲服務提供商來解決這個問題，我們對Shopify的安全運維小夥伴們印象很好：他們響應快速、對問題高度負責並且溝通起來非常順暢。非常感謝他們，因為他們知道如何與網路安全研究社群保持良好的溝通。
先來介紹一下Shopify，維基百科上的描述如下圖所示。
簡而言之，Shopify是一個雲服務提供商，允許使用者以非常簡單的方式建立電子商務網站。
如果大家對Shopify上的子域名接管漏洞比較熟悉，可以直接跳到本文末尾，瞭解如何大規模利用這個漏洞。
二、Shopify子域名接管漏洞
在漏洞獎勵計劃或者滲透測試過程中，如果我們遇到如下兩個網頁，則表明目標可能存在子域名接管漏洞。
接下來看一下如何確定漏洞是否存在。
首先，我們可以使用如下兩類DNS記錄來接管Shopify上的子域名：
1、使用應用名進行對映（CNAMES指向 myshopname.myshopify.com ）；
2、使用DNS進行對映（CNAMES指向 shops.myshopify.com ）。
可能還有其他方法（比如歷史遺留域名），後續我們會進一步研究這些方法。
案例1：使用應用名進行對映
在這個例子中，我們為 shop.buckhacker.com 設定了一個CNAME記錄，指向 buckhacker.shopify.com ：
現在如果Shopify上不存在 buckhacker 這個商店名稱，我們就可以宣告該名稱來接管子域名。
那麼如何判斷某個商店名是否已存在？
在賬戶註冊階段，我們必須選擇一個商店名。如果我們利用如下頁面，很容易就能知道商店名是否可用：
如果我們使用Burp來觀察，可以看到瀏覽器會發起一個REST API請求，並且會收到兩種型別的響應：
1 商店名不可用時的響應為：
({“status”:”unavailable”,”message”:null,”host”:”buckhacker.myshopify.com”})
2 商店名可用時的響應為：
({“status”:”available”,”message”:null,”host”:”buckhacker2.myshopify.com”})
我們可以開發一個指令碼來判斷某個域名是否可用，為節省大家時間，這裡我們直接在 ofollow,noindex" target="_blank">GitHub 上公開了這個指令碼。
此時如果我們發現商店名可用，那麼只需在Shopify網站中連線（connect）該名字即可，來看看具體步驟。
登入Shopify網站後，在左側選單處依次選擇“Online Store”以及“Domains”：
接下來點選“Connect existing domain”（連線已有域名）：
在下一個表單處填入存在漏洞的域名：
點選“Next”，然後點選“Verify Connection”。
現在如果上述步驟操作正確，我們會被重定向到如下頁面：
此時我們已成功接管子域名。
這種情況尋找起來比較麻煩，因為我們需要在賬戶建立過程中選擇目標商店名。因此，為了使該名字可用，使用者需要刪除整個賬戶或者改變賬戶設定。在調查過程中，我們發現2%的網站存在這種錯誤配置情況。
案例2：使用DNS進行對映
在第二種案例中，子域名為指向 shops.myshopify.com 的一個CNAME。
我們建立的域名如下圖所示：
這是Shopify上最常見的子域名接管場景。在這種情況下，我們基本上可以建立具有任意名稱的商店，只需要按照上文所述在Shopify網站中進行連線即可。
接管過程的部分截圖如下：
驗證結果如下圖所示：
也可以通過如下介面驗證接管結果：
三、大規模利用
我們在之前一些文章中已經介紹過如何使用Sonar以及FDNS資料集來識別漏洞。
FDNS資料集中包含CNAMES記錄。基本上我們要做的就是在這個資料集中尋找CNAME指向 shop.myshopify.com 或者 myshopname.shopify.com 的子域名，然後檢查是否可以接管子域名即可。
我們只需要使用前文提到的指令碼，用一行命令就可以完成這個任務：
zcat $FDNS_DATASET | strings | grep shopify.com | cut -d “”” -f 8 | grep -v “shopify.com” | while read subdomain; do python3 ShopifySubdomainTakeoverCheck.py $subdomain; done
首先我們需要解釋一下，為什麼在別人已開發了一些指令碼的情況下，我們還要開發一個新的指令碼來判斷Shopify是否存在子域名接管漏洞。現在可用的其他指令碼大多數是基於Shopify的錯誤資訊頁面來檢測是否存在子域名接管漏洞，但這種方法容易得到許多假陽性結果。我們檢查過存在這類錯誤資訊的許多頁面，只有少部分的確存在子域名接管漏洞。我們開發的簡單指令碼只執行了3步檢查操作：頁面錯誤資訊、CNAME以及發起REST API請求（可根據具體情況再執行API請求）。我們希望未來的子域名接管工具可以採用類似技術來減少誤報率。
如果我們在FDNSv2資料集（從2017年至今，新增了部分資料）上執行指令碼，那麼得到的結果非常可觀：大約有超過55,000個子域名存在子域名接管漏洞。
現在我們就可以使用這個資料來判斷漏洞獎勵相關域名或者客戶的相關域名是否位於這個大名單上。
顯然，我們也可以在其他雲服務提供商使用這種技術。
四、總結
我們認為這項研究成果可以讓人們瞭解子域名接管漏洞的影響程度及具體規模。我們認為，在雲端計算的大背景下，我們面對的是漏洞研究的新時代，不能侷限於分析程序堆疊情況，而應提高思維廣度（比如分析DNS記錄對映情況）來分析漏洞。可能我們需要將雲平臺甚至網際網路本身當成一個大型作業系統來考慮。
五、時間線
- 2018年8月21日 — 通過HackerOne將漏洞報告給Shopify
- 2018年8月21日 — Shopify初步反饋
- 2018年8月23日 — Shopify再次反饋
- 2018年9月10日 — 漏洞公開