域名注册时间查询工具_利用过期域名实现劫持海量邮件服务器和TLS/SSL证书

先前的建议

将二进制空间安全性设置为“星号”⭐️

尽快收到文章更新

概括

当域名过期重新注册时，原域名可能已经失效，但在某些Whois查询工具或服务中，仍然会向该域名的Whois服务器发起查询。此时攻击者可以通过重新注册过期域名，并配置其Whois服务器的域名解析记录，使查询请求指向恶意的Whois服务器，从而劫持该请求。

劫持发现

发现该问题的安全团队最初的目的是研究如何通过解析 WHOIS 服务器的响应并利用 WHOIS 客户端中的漏洞来做一些事情，这样在某些情况下，中间人攻击就不再是必要的了。作为研究的一部分，该团队发现几年前，.MOBI TLD 的 WHOIS 服务器已从 whois.nic.mobi 迁移而来，该域名将于 2023 年 12 月到期。为了顺利开展研究工作，该团队迅速购买了该域名，并在主机名后面部署了一个 WHOIS 服务器。这样做的最初目的只是为了看看是否真的可以收到主动连接请求。

自部署以来，其成果相当惊人——已发现有超过 135,000 个独特系统与其进行通信，截至 2024 年 9 月 4 日，共收到 250 万个查询。对这些查询的简要分析表明，请求来自（但不限于）以下来源：

然而在2024年9月1日，团队突然意识到一个严重的问题：许多负责为域名（例如“ .mobi”和“ .mobi”）颁发TLS/SSL证书的证书颁发机构（CA）通过“域名电子邮件验证”机制来验证域名的所有权，而这些机构居然使用我们的WHOIS服务器来确定域名所有者并发送验证信息。

该团队进行了概念验证 (PoC)，并成功证明，对于“ .mobi”，它将解析我们的 WHOIS 服务器提供的响应并将“ ”视为权威电子邮件地址。

事实上，这一举动无意中破坏了整个.mobi顶级域名（TLD）的CA验证流程。

问题似乎越来越严重了。如果我们能做到这一点，我相信任何人都可以做到……

因此，我们开始在互联网上寻找可能向我们发送查询的目标位置。以下是一些域名注册商和 WHOIS 功能网站：

因此，每个 WHOIS 工具查询都会返回以下结果：

.io——一个 URL 网络沙盒网站，也使用我们的 .mobi WHOIS 服务器，可以通过浏览任何 .mobi 域名页面来查看，如下所示：

其中还包括流行的恶意软件分析网站：该网站也正在访问我们的Whois服务器，如图所示：

我们的临时 WHOIS 服务器正在查询这个全球 .TLD，并返回结果，令人惊讶的是，关于谁拥有 bbc.mobi 的记录已经更新，如下所示：

劫持邮件服务器

为了进一步确认有多少IP会主动联系我们的Whois服务器，在几个小时之后，我们统计了在此期间有多少个独立IP查询了Whois服务器：

结果显示，短短几个小时内，就有 76,000 多个唯一源 IP 地址发送了 Whois 请求，两天后这一数字增加到了 130 万个。

使用 ZDNS 处理 IP 列表，看看是否有任何有趣的内容，例如：gov

垃圾邮件过滤器通常会对发件人的域名执行 WHOIS 查询。我们在这里看到了很多这样的请求，从恰如其名的 .email 到 .bd——这似乎是孟加拉国政府基础设施的一部分。天哪！理论上，我们可以通过返回一个响应来造成混乱，表明发送域名是一个已知的垃圾邮件发送者——或者更具破坏性的是，通过模糊 WHOIS 解析代码在邮件服务器上触发远程代码执行 (RCE)。

我们在日志中多次发现巴西 - 例如 .br 和 .br，巴西并不是唯一一个。我们还发现了属于以下国家的 .gov 地址（但不限于）：

每次收到来自 .mobi 域名的电子邮件时，.gov 和其他邮件服务器都会查询假的 Whois 服务器，因此攻击者可以被动地确定谁可能正在通信。

劫持 TLS/SSL 证书

众所周知，TLS/SSL 是地址栏中友好的小锁图标，可确保您的连接安全。它依赖于证书的概念 - 有时用于 HTTPS，有时用于签署恶意软件。

例如，假设您是 .mobi 网站的所有者。您希望通过 TLS/SSL 保护与 Web 服务器的通信，因此您前往您最喜欢的证书颁发机构 (CA) 并申请证书。

证书颁发机构会验证您是否拥有域名 .mobi，然后签署一份私人证书，证明您拥有该域名。然后，您的浏览器会使用此证书确保您的通信安全。

那么这与 WHOIS 有什么关系？与我们又有什么关系？

事实证明，许多 TLS/SSL 证书颁发机构通过解析域名（例如 .mobi）的 WHOIS 数据并提取定义为“管理联系人”的电子邮件地址来验证域名所有权。

然后，他们会向该电子邮件地址发送一个验证链接 - 一旦点击，证书颁发机构就会相信您控制了该域名，并很乐意向您颁发证书。

例如：

如果 TLS/SSL 证书颁发机构正在将我们的 WHOIS 服务器用于 .mobi 域名，我们可能会为此“电子邮件域名控制验证”方法提供我们自己的电子邮件地址。

以下是支持基于 WHOIS 的所有权验证的大型 TLS/SSL 证书颁发机构/经销商的示例：

按照正常程序，我们开始谨慎行事 - 为虚构域名 .mobi 生成 CSR（证书签名请求） - 逻辑是，只要我们的 WHOIS 服务器被查询，域名是否真实并不重要，因为我们对每个请求都做出了积极的回应，包括那些实际上不存在的域名的请求。

这里不打算介绍每个程序，为了说明起见，我们将在这里使用它。

一旦您将 .mobi CSR 上传到 ，它就会被解析，我们就可以继续了。这些占位符电子邮件地址的存在表明 WHOIS 查询失败 - 它应该返回在我们的 WHOIS 服务器 ( ) 上配置的电子邮件地址，但它只显示了 @.mobi 域名。

让我们松了一口气的是，CA 正确地确定了 .mobi 域名不存在，因此，如果 WHOIS 正常工作，则不会返回任何电子邮件地址。这说明我们新设置的 WHOIS 服务器没有受到服务提供商的查询。

WHOIS 协议非常简单，本质上它只是一个字符串，根据提供服务的顶级域名 (TLD) 以不同的格式返回。每个提供商都会以自己的方式实现解析。也许，在驳斥我们的理论之前，我们应该确保这种验证机制确实按预期工作。

因此，我们重新开始 - 选择 .mobi 作为 .mobi 域名，该域名似乎遵循相当典型的 WHOIS 格式（使用当前的 .mobi WHOIS 服务器）。

下面的截图显示.mobi 的合法 WHOIS 记录被正确解析，并且唯一可以用来验证的电子邮件地址是域名：

但 .mobi 的 WHOIS 记录根本没有被解析（这表明正在使用正确的 WHOIS 服务器，而不是我们的）：

你以为到现在为止不会再有任何问题了，对吧？但事实总是出乎意料。

我们直接联系了下一个提供商：，据报道其无法解析 .mobi 的 WHOIS 记录：

这时，我突然明白了。也许我们确实在查询新的 WHOIS 服务器，但 WHOIS 服务器返回的字符串与我们的解析不兼容？

因此，我们从合法的 WHOIS 服务器复制了 .mobi 输出，将其替换为我们自己的输出，然后将其加载到我们自己的 WHOIS 服务器上。更新后，它看起来像这样：

然后，我们屏住呼吸，重新触发

.mobi 的 CSR...

成功！TLS/SSL 证书 WHOIS 域验证系统查询了我们的 WHOIS 服务器，解析了结果，并将其作为有效的电子邮件地址发送验证电子邮件，使我们能够完成验证并获得有效的 TLS/SSL 证书。

现在我们有能力为 .mobi 域名颁发 TLS/SSL 证书，理论上我们可以做各种可怕的事情：从拦截流量到冒充目标服务器。此时，各种威胁模型都完蛋了。

保护措施

缓存Whois服务器的IP地址：为了避免这种劫持，Whois查询工具可以避免依赖域名进行解析，而是缓存Whois服务器的IP地址。

验证 Whois 服务器的真实性：使用安全机制验证来自 Whois 服务器的响应，例如加密通信或签名，以确保 Whois 响应的真实性。

这种劫持利用了Whois查询系统的结构和域名过期后重新注册的特性，因此在设计和使用Whois服务时应该考虑到这种潜在的攻击媒介。

参考地址：

先前的建议

点击观看你是最棒的