用子域名窃取客户资料，为什麽要维护您的 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 这类型的子域名那麽显眼就掉以轻心。