用子域名竊取客戶資料，為什麼要維護您的 DNS 紀錄

我承認，我的數位空間並不總是那麼乾淨。有時，我會快速的打開一些分頁但並未閱讀文章，或者堆積了一些寫了一半的文字檔案。在我對自己寬容時，我將其解釋為創造力的來源。但當我對自己較為嚴格時，我認為這就是草草了事的態度。

在所有這類型的數據空間中，我必須承認，我的 DNS 區域通常都在我的清理清單中排名較後面的位置。然而這件事是非常重要的，因為您沒有使用的 DNS 區域檔內的雜亂紀錄實際上可能是一個嚴重的威脅。

最糟可能面臨什麼樣的情況？

熱門乘車平台 Uber 公司在他們的域名下創建了一個子域名 – saostatic.uber.com。他們使用了 Amazon Cloudfront 的服務，這是一個內容傳遞網路，當這個網路被使用時就會在這個子域名中使用。

有一天，Uber 公司停止使用其子域名 saostatic.uber.com，而且他們將端點從 Amazon Cloudfront 中移除了。

然而，沒有人將指向 Cloudfront 的 ‘saostatic’ 的 CNAME 給移除。該 CNAME 仍留指向原本的位址。

然後有一天，一個漏洞賞金獵人發現了 saostatic 的子域名，並且注意到它仍是指向 Cloudfront，即使他試圖在 Cloudfront 上搜索，他仍然得到 “錯誤請求” 的回應。

從這裡開始，他要做的就是將 saostatic.uber.com 作為端點並將其加入他自己的 Cloudfront 帳戶中，然後他就可以完全控制 saostatic.uber.com 這個子域名。

更糟的是，由於 Uber 當時新實施的單一登錄系統來驗證 *.uber.com 的所有服務，只要將認證過的使用者瀏覽 saostatic.uber.com 就可以取得使用者的 cookie，接者就能冒用使用者的身份瀏覽所有 uber 的服務。

顯然地，我沒有要批評 Uber 的意思，系統總是會發生錯誤。關鍵是，忘記將 CNAME 從您的 DNS 區域移除這件看起來如此微小的事情，竟然可能成為重大的資安問題，並讓您的用戶身陷被有心的第三方傷害的危機之中。

還有更糟的，因為您那邊看不到任何改變，而且您的任何網路都不會受到影響，因此這種攻擊幾乎是無法偵測到的！

同樣地，由於有免費的 SSL 服務，攻擊者也可以輕易地為子域名取得一個 SSL 憑證，因此您的客戶更難以注意到這個子域名有問題。

他們還可以做什麼？

在 Uber 的例子中，漏洞賞金獵人描述了如何使用 cookies 來從中得益。然而，有些技術，像是 Oauth，具有子域名允許列表的機制，從而使得開發人員可以指示要接受的網址 (URI)。如果一個子域名允許列表被攻擊，那麼使用者的 Oauth 密鑰就可能洩漏。

攻擊者還有其它幾種方式可以利用允許列表去接管子域名。

有些密碼管理器會依照子域名的名稱來保護密碼，因此，釣魚網站可能會使用相同的子域名來觸發密碼管理器。

這是怎樣發生的？

我們上面所描述的只是一個例子，而 Amazon Cloudfront 一個常見的服務，但它絕不是唯一一個可能發生這些問題的服務。

然而，並不是說其他的乘車軟體就不會有這些問題。

讓我們以一個假設的例子為例，假設您的網站架構完整，所以 shop.example.com 可以指向您的網路商店。現在，假設您將商店移至 example.com/shop 並且將 shop.example.com 從您的主機中移除。如果您也沒有將指向 shop.example.com 的 CNAME 紀錄從您的主機供應商那邊移除，其他人就有可能可以為 shop.example.com 創建一個主機並駭進您的子域名中。

您應該考慮的是，任何主機服務都可能允許透過 CNAME 紀錄在您的子域名上創建新的主機，並採許相應的動作。

發現 Uber 的舊 CNAME 紀錄的漏洞賞金獵人可能是使用一種工具去掃描子域名，或者他們可能就是直接在 Google 上搜尋該域名並且在某個地方找到它的子域名。因此，不要以為您的子域名不像 admin.example.com 或 mail.example.com 這類型的子域名那麼顯眼就掉以輕心。