如何利用域名解析提供商（digitalocean）逻辑漏洞劫持2万个域名-k8凯发天生赢家

提前声明:

本文并没有炮轰digitalocean的意思，实际上，我觉得digitalocean在这种情况下的回应完全是合理的。我希望的是digitalocean能够将这些域名从我的账户中删除，并且不要禁掉我的账号。此外， digitalocean的安全团队给我的总体印象是非常积极的,我会在未来与他们进行更主动的交流。

前言

digitalocean是类似亚马逊web服务或谷歌云的云服务提供商。云dns主机托管是他们的产品线之一，这里有一个很好的关于如何使用他们的dns的指南

https://www.digitalocean.com/community/tutorials/how-to-set-up-a-host-name-with-digitalocean

花一些时间来读读它,看你能不能发现他们域名设置过程中的潜在问题。

对该指南进行一个快速浏览,你会发现它似乎是一个非常容易使用的系统。

例如:

没有讨厌的域名验证阻碍你将任意域名添加到您的帐户

不需要记住谁在你的域名查询服务上

不需要将你的域名与特定的域名服务器关联

事实上你所要做的只是下面这些:

“在网络部分,点击添加域名,并填入你想要在后续页面连接到的服务器的域名和ip地址。”

所以,如果你愿意,你可以将我的域名thehackerblog.com添加到自己的digitalocean帐户上。不过，这也带来了一些有趣的问题:

“别人能阻止我将自己的域名导入digitalocean吗?”

“当我从digitalocean删除我的域名时忘记改变域名服务器会发生什么？”。

在回答这些问题之前，我们先看看另一个云服务提供商是如何实现的。

route53设置过程

亚马逊网络服务（aws）也提供云dns主机服务，其产品线称为route53。作为测试,我尝试了域名thehackerblog.com的设置过程。如果你想自己试试，可以查看aws的官方文档

https://docs.aws.amazon.com/gettingstarted/latest/swh/getting-started-configure-route53.html

第一步是单击route53控制面板左上角的创建托管区按钮。首先填写域名，创建完成之后，进入了我们新创建区域的dns管理面板。ns记录类型预填充了一些随机生成的域名服务器。

例如

我收到的域名服务器列表如下所示:

ns-624.awsdns-14.net.

ns-39.awsdns-04.com.

ns-1651.awsdns-14.co.uk.

ns-1067.awsdns-05.org.

上面这一步是非常重要的——如果我为域名thehackerblog.com创建了一个区域，你也做了同样的事情，那么我们将会得到不同的域名服务器。如果我从自己的aws帐户中删除该区域文件,那么没有人可以街接管我的域名，因为这个域名服务器专属于我的账户。所以,如果你想接管我删除的域名,你需要连续尝试直到你得到相同的域名服务器。否则我的域名将指向其他域名服务器而不是你控制的域名服务器。

回到digitalocean

“当我从digitalocean删除我的域名时忘记改变域名服务器会发生什么？”

这个问题的答案就变得很清晰了。如果你从自己的帐户中删除了一个域名，那么任何人都可以立即将其添加到自己的账户上，而且不需要任何所有权和接管的验证。

不过，注意到可能出现的问题是一回事,证明它会大规模发生却是另一回事。在不将所有互联网上的域名添加到我们的digitalocean帐户的情况下，如何证明这个问题是系统性的和普遍的？

首先,判断一个域名是否被添加到digitalocean帐户的一个简单的方法是：执行定期dns查询,看看digitalocean域名服务器如何回复。作为示例,我们使用.cm作为测试,它们的域名服务器设置为digitalocean，但还没有添加到任何digitalocean帐户：

mandatory@matthews-macbook-pro-4 ~> dig ns .cm @ns1.digitalocean.com.

; <<>> dig 9.8.3-p1 <<>> ns .cm @ns1.digitalocean.com.

;; global options: cmd

;; got answer:

;; ->>header<<- opcode: query, status: refused, id: 53736

;; flags: qr rd; query: 1, answer: 0, authority: 0, additional: 0

;; warning: recursion requested but not available

;; question section:

;.cm. in ns

;; query time: 51 msec

;; server: 173.245.58.51#53(173.245.58.51)

;; when: tue aug 23 23:09:00 2016

;; msg size rcvd: 26

在上面的输出中我们可以看到,digitalocean域名服务器返回了一个dns refused(rcode 5)错误，这表明域名服务器拒绝回应我们执行的ns记录查询。这给了我们一个简单的方法来区分域名是否被添加到了digitalocean账户上。

这个问题解决了,但检查互联网上的每一个域名仍然是不现实的。此外,我们怎样才能得到互联网上的所有域名列表？答案是通过各种顶级域(tlds)的域文件副本。我们使用的是.com和.net tlds的域文件,因为很容易以研究目的从verisign获得。域文件中包含存在的每个.com和.net域名及其对应的域名服务器。使用grep可以查出这些域文件中有多少.com和.net域名使用digitalocean dns主机。在撰写本文时,这两个tlds的数量如下:

.com: 170,829

.net: 17,101

加起来共有187930个域名使用digitalocean作为它们的dns提供商。现在我们可以查询这些域名然后检查返回结果，返回dns refused错误表明未添加到digitalocean账户（这意味着可以接管）。在使用一个简短的python脚本进行几个小时的dns查询之后，最终有21598个域名返回dns refused错误。将这些域名添加到digitalocean账户之后,实际的数字接近19500个。这个数字是非常惊人的！这表明我接管了将近2万个digitalocean域名。

sinkhole流量

我所接管的大部分域名其实是纯粹的垃圾域名，没有进行任何配置。sinkhole服务器是一个标准的nginx web服务器，返回一个空白的网页和web请求日志。在这些域名上启动了sinkhole服务之后，几天时间里，访问日志就增长到了1.8gb，并且请求还在源源不断地涌进。大多数都是来自搜索引擎(大约80%的流量)，也有其他合法用户导航到现在重定向的网站。不断涌入的流量是令我苦恼的地方。

digitalocean的回应

在证明这个理论是真实的之后,我与digitalocean的安全团队进行了联系，并描述了这个问题(按照他们安全页面的要求)。他们的回应如下:

“谢谢你向我们发送的这个问题描述。这是我们平台上一个已知的工作流，我们一直致力于提高我们客户的体验，并且也在分析一些方法来减少你所描述的这种行为的影响。”

所以实际上他们已经知道这个问题了,可能正在想办法在未来减轻这种行为的影响,但他们似乎并不打算做任何直接的计划。

此外，我的digitalocean账户被锁定了。这阻止我进行下一个步骤:将所有的dns指向127.0.0.1——来有效缩小流量。当我向digitalocean支持部门询问为什么我的帐户被锁定时，我收到了以下回复:

“我们检查了你的账户,我们不能为您提供进一步的服务了。我知道这可能会给您造成不便,但是我们不能继续为您提供托管服务，并且这个决定不可更改。”

没有任何理由就把我的账号禁掉了,而且表示不会有进一步的支持。这让我很不舒服，而且还要受到巨量的sinkhole流量影响。由于我不能访问我的账户改变这些域名的dns,所以每一分钟我就会收到成千上万的访问请求。虽然我停掉了所有服务器上的服务来保护不小心撞到这些网站的用户的隐私,并且清除了访问日志,但我无法阻止洪水般的流量。在这个尴尬的境地,我向digitalocean的团队寻求了帮助,看看他们是否可以帮助从我的帐户中删除这些域名，或将所有的dns设置到127.0.0.1。我收到了它们的回复，表示会对这件事情进行调查处理。

这件事情让我们意识到为什么要使用独一无二的域名服务器来导入域名，就是为了防止这个问题！值得注意的是,任何使用非唯一域名服务器导入域名的系统都有可能受到这种类型的攻击影响。

因此，希望digitalocean能够尽快解决这个问题，也提醒所有digitalocean用户一定要使用唯一的域名服务器导入域名，避免这种情况的发生。