part1
点击上方蓝字关注我们
往期推荐
将二进制空间安全设为"星标⭐️"
第一时间收到文章更新
摘要
当域名过期并重新注册时，原来的域名可能已经失效，但在一些Whois查询工具或服务中，仍然会对这个域名的Whois服务器发起查询。这种情况下，攻击者可以通过重新注册过期域名，并配置其Whois服务器的域名解析记录，使得查询请求被定向到恶意的Whois服务器，从而进行请求劫持。
劫持发现
发现该问题的安全团队的最初目的是研究通过解析来自WHOIS服务器的响应,从而利用WHOIS客户端中的漏洞来做一些事情, 这样在某些场景下可以不再需要进行中间人攻击。作为研究的一部分, 团队发现在几年前, .MOBI TLD的WHOIS服务器从whois.dotmobiregistry.net 迁移到 whois.nic.mobi, 并且域名dotmobiregistry.net将在2023年12月到期。为了研究工作顺利进行,该团队很快便将域名dotmobiregistry.net购入囊中, 并在 whois.dotmobiregistry.net主机名后面部署了一台WHOIS服务器, 这样做的最初目的仅仅是为了看看是否真的能收到主动连接请求。
自从部署后，结果非常惊人——已经识别出超过13.5万个独立系统与之通信，截至2024年9月4日，总共收到了250万次查询。对这些查询的简要分析显示，来自（但不仅限于）以下来源的请求：
-
各类 .GOV 和 .MIL 实体的邮件服务器，似乎在使用该 WHOIS 服务器查询它们接收到的域名的电子邮件来源。
-
各类网络安全工具和公司，仍然将此 WHOIS 服务器视为权威（例如 VirusTotal、URLSCAN、Group-IB 等）。
然而，2024年9月1日，团队突然意识到一个严重的问题：许多负责为域名（如 'google.mobi' 和 'microsoft.mobi'）颁发 TLS/SSL 证书的证书颁发机构（CA），通过“域名电子邮件验证”机制来验证域名的所有权，而这些机构竟然使用我们的 WHOIS 服务器来确定域名所有者并发送验证信息。
团队与 GlobalSign 进行了一次概念验证（PoC），并成功演示了对于 'microsoft.mobi'，GlobalSign 会解析我们的 WHOIS 服务器提供的响应，将 '[email protected]' 视为权威的电子邮件地址。
实际上，这次操作无意中破坏了整个 .mobi 顶级域名 (TLD) 的 CA 验证流程。
问题似乎变得很严重, 如果我们能做到这一点, 相信其它任何人都可以做到... ...
于是，我们开始在互联网中寻找可能向我们发送查询的目标位置, 以下是整理的一批域名注册商和WHOIS功能网站：
-
domain.com
-
godaddy.com
-
who.is
-
whois.ru
-
smallseo.tools smallseo.tools 工具
-
seocheki.net
-
centralops.net
-
name.com
-
webchart.org
结果每个WHOIS工具的查询返回结果都像这样:
urlscan.io - 一个url网络沙盒网站也使用了我们的.mobi WHOIS服务器, 可以通过浏览任何.mobi域的页面来查看结果,如图:
同样也包括流行的恶意软件分析网站:VirusTotal也正在访问我们的Whois服务器,如图:
VirusTotal 正在查询我们的临时 WHOIS 服务器以获取此全局 .TLD 并返回结果, 同时还惊喜的发现VirusTotal更新了他们关于谁拥有bbc.mobi的记录,如图:
劫持邮件服务器
为了进一步确认到底有多少IP会主动联系我们的Whois服务器, 在几个小时之后, 统计了一下这段时间有多少独立IP查询了Whois服务器:
显示的结果为:76000+个独立源IP地址在短短的几个小时内发送了Whois请求, 在两天后这个数字增加到130万。
将IP列表利用ZDNS进行处理, 看看有没有比较有趣的东西,例如:gov
垃圾邮件过滤器通常会对发件人的域名进行 WHOIS 查询。这里看到了很多这样的请求，范围从名副其实的 cheapsender.email 到 mail.bdcustoms.gov.bd——这似乎是孟加拉国政府基础设施的一部分。天哪！理论上，我们可以通过返回的响应表明发件域是一个已知的垃圾邮件发送者，从而引发混乱——更具破坏性的是，通过模糊测试 WHOIS 解析代码在邮件服务器上触发远程代码执行 (RCE)。
我们在日志中多次发现了巴西 - 例如，antispam.ap.gov.br 和 master.aneel.gov.br ，巴西并不孤单。同时还发现了属于（但不限于）的 .gov 地址：
-
Argentina(阿根廷)
-
Pakistan(巴基斯坦)
-
India(印度)
-
Bangladesh(孟加拉国)
-
Indonesia(印度尼西亚)
-
Bhutan(不丹)
-
Philippines(菲律宾)
-
Israel(以色列)
-
Ethiopia(埃塞俄比亚)
-
Ukraine(乌克兰)
-
USA(美国)
随着 .gov 以及其他邮件服务器在每次收到来自 .mobi 域的电子邮件时查询虚假的Whois服务器, 攻击者可以被动地确定谁可能正在进行通信。
劫持TLS/SSL证书
TLS/SSL，大家都知道，它就是地址栏中的那个友好的小锁图标，向你保证你的连接是安全的。它依赖于证书的概念——有时用于 HTTPS，有时用于签署你的恶意软件。
例如，假设你是 watchTowr.mobi 的所有者。你想通过 TLS/SSL 来保护与你的 web 服务器之间的通信，因此你去你最喜欢的证书颁发机构（CA）申请证书。
证书颁发机构会验证你是否拥有该域名——watchTowr.mobi——然后签署一个私有证书，证明你是该域名的所有者。之后，浏览器会使用这个证书来确保你的通信是安全的。
那么，这跟 WHOIS 有什么关系？跟我们又有什么关系呢？
事实证明，很多 TLS/SSL 证书颁发机构会通过解析域名的 WHOIS 数据来验证域名所有权——比如 watchTowr.mobi——并提取出定义为“管理联系人”的电子邮件地址。
接着，他们会向这个电子邮件地址发送一个验证链接——一旦点击，证书颁发机构就相信你控制了该域名，并会愉快地为你签发一个证书。
例如：
如果 TLS/SSL 证书颁发机构正在将我们的 WHOIS 服务器用于 .mobi 域，我们可能会为此“电子邮件域控制验证”方法提供我们自己的电子邮件地址。
以下是支持基于 WHOIS 的所有权验证的大型 TLS/SSL 证书颁发机构/转销商的示例:
-
Trustico
-
Comodo
-
SSLS
-
GoGetSSL
-
GlobalSign
-
DigiSign
-
Sectigo
按照正常的流程，我们小心翼翼地开始——为虚构的域名 watchTowr.mobi 生成了一个 CSR（证书签名请求）——逻辑是，只要我们的 WHOIS 服务器被查询，域名是否真实并不重要，因为我们对每个请求都积极响应，包括那些实际上不存在的域名。
这里不打算介绍每个程序, 为了便于说明, 这里将使用GoGetSSL。
将 watchTowr.mobi CSR 上传到 GoGetSSL 后，它将被解析，然后我们继续。出现这些占位符电子邮件地址表明 WHOIS 查询未成功——本应返回我们 WHOIS 服务器配置的电子邮件地址（[email protected]），但实际上只显示了 @watchtowr.mobi 的域名。
总算让人松了一口气, 证书颁发机构正确地判断出 watchTowr.mobi 域名不存在，因此，如果 WHOIS 正常工作，将不会返回任何电子邮件地址。因此得出结论：我们新设置的 WHOIS 服务器没有被服务提供商查询。
WHOIS 协议非常简单，本质上它只是一个字符串，根据提供服务的顶级域（TLD）以不同格式返回。每个提供商都会以自己的方式实现解析。也许，在否定我们的理论之前，应该确保这个验证机制确实按预期工作。
于是，我们再次开始——选择了 microsoft.mobi 作为一个看起来遵循较为典型 WHOIS 格式的 .mobi 域名（使用当前的 .mobi WHOIS 服务器）。
下方的截图显示了 microsoft.mobi 的合法 WHOIS 记录被 Entrust 正确解析，唯一可用于验证的电子邮件地址均为 microsoft.com 域名：
虽然 watchTowr.mobi 的 WHOIS 记录根本没有被解析（这表明 Entrust 使用了正确的 WHOIS 服务器，而不是我们的服务器）：
此时你认为应该不会再出现问题了吧? 事实总是会给人当头一棒。
我们直接选择了下一个提供商: GlobalSign, 据GlobalSign 报告称，他们无法解析 microsoft.mobi 的 WHOIS 记录：
在这一刻，突然意识到了什么。或许 GlobalSign 确实在查询我们新的 WHOIS 服务器，但我们 WHOIS 服务器返回的字符串与 GlobalSign 的解析不兼容？
于是将来自合法 WHOIS 服务器的 microsoft.mobi 输出复制下来，替换成我们自己的，并加载到自己的 WHOIS 服务器上，更新后看起来如下:
然后，我们屏住呼吸，重新触发了 GlobalSign 和
CSR for microsoft.mobi...
成功了!GlobalSign TLS/SSL 证书 WHOIS 域验证系统查询了我们的 WHOIS 服务器，从结果中解析 [email protected]，并将其呈现为有效的电子邮件地址以发送验证电子邮件，使我们能够完成验证并获得有效的 TLS/SSL 证书。
现在我们有能力为 .mobi 域颁发 TLS/SSL 证书，理论上可以做各种可怕的事情: 从拦截流量到冒充目标服务器。在这一点上，各种威胁模型的游戏都结束了。
防护措施
-
缓存Whois服务器的IP地址：为了避免这种劫持，Whois查询工具可以避免依赖域名进行解析，而是缓存Whois服务器的IP地址。
-
验证Whois服务器的真实性：使用安全机制验证Whois服务器的响应，例如通过加密通信或签名来确保Whois响应的真实性。
这种劫持利用了Whois查询系统的结构和域名过期后的可重新注册特性，因此在设计和使用Whois服务时应当注意这一潜在的攻击向量。
参考地址:
https://labs.watchtowr.com/we-spent-20-to-achieve-rce-and-accidentally-became-the-admins-of-mobi/
往期推荐
点个在看你最好看
原文始发于微信公众号（二进制空间安全）：利用过期域名实现劫持海量邮件服务器和TLS/SSL证书
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论