[论文总结] Cloud Strife: Mitigating the Security Risks of Domain-Validated Certificate
作者：郭润 （清华大学）
论文作者： Kevin Borgolte(UC Santa Barbara)，Tobias Fiebig (TU Delft)， Shuang Hao （UT Dallas）
摘要：因弹性资源分配（如存储、带宽和IP地址）等特点，Amazon Web Service (AWS) 和 Microsoft Azure等IaaS架构的云平台被普通使用。然而，本文发现，互联网中存在大量的 stale DNS 域名（如过去在云端部署服务，但目前停止了服务，该类 IP 地址已经被释放回云平台），但这些DNS记录仍然指向了云平台中的可分配IP地址。攻击者可以向云平台申请并分配到这些IP地址，从而获得该DNS域名的控制权（domain takeover)。因此，攻击者可以利用分配到的 IP 来通过互联网中的一些基于域名的验证系统，如基于域名验证的SSL证书颁发机制，甚至可以进行钓鱼、收发邮件或者通过该域名分发恶意代码等（当第三方从该域名下加载如JS脚本等代码时）。
论文进一步从时间和花销上，深入分析了这种获取DNS域名指向的云端IP的实际可行性。在极端条件下，攻击者可以在 70 秒之内申请到云端 IP 并完成攻击。消耗的时间远低于普通的 DNS 记录 TTL 值，因而这种攻击可以发生在正常的云端服务迁移过程中（IP被临时释放），从而该安全问题将导致更广泛的攻击面。
随之，论文提出上述 domain takeover 问题的解决方案，也即将该域名的已有验证加入到新的验证过程中（在新申请证书时，基于申请过的证书进行认证）。同时，也针对域名所有者和云平台管理员提出了安全建议。
背景
过去的十年间，因用户可以按需申请资源，AWS 和 Azure 等云平台被广泛的用于部署各种云端服务，其中 Azure 月均增加 120,000 个用户，目前 AWS 已经有 1,000,000 个活跃用户。同时，TLS 也因为服务商对安全的重视而被广泛使用，如在HTTPS、HTTP2中提供数据传输的加密和认证。为了应对大量SSL证书的申请处理负担，SSL证书的颁发过程也引入了自动化机制，主要依赖于域名验证完成对申请者身份的验证。如，证书颁发机构 Let‘s Encrypt（2016年4月开始提供服务）提供了基于ACME协议（Automatic Certificate Management Environment protocol)的自动化证书申请工具，仅在15个月内就颁发了超过100,000,000个证书 [10]。
证书颁发机构在为对应域名颁发证书时，需要验证证书申请者是否拥有对应域名。现在大部分证书颁发结构CA采取的是基于域名的验证方法，即证书申请者需要证明其对所申请域名拥有控制权，具体方法有：
- DNS记录验证，如要求申请者加一条具有指定随机数的TXT记录；
- 邮件验证，CA向WHOIS记录中的注册邮箱或常见的“postamaster”、“sslmaster”等邮箱发送带token的验证邮件，要求申请者点击或回复；
- Web 认证，要求申请者在该域名下提供HTTP服务，并且在CA指定的URL路径下部署一个带有特定token的文件，以供 CA 进行 HTTP 访问验证。
对于Let’s Encrypt来说，为了更快促进TLS的广泛使用，Let’s Encrpyt 提供了免费的证书申请服务。同时为了减少证书私钥泄露或错误颁发等危害，Let’s Encrpyt 颁发的证书只有 90 天有效期。Let’s Encrypt 采用自动化的基于 Web 的验证方式，这迅速增加了互联网中的 SSL 证书使用率，并提高了 Let’s Encrypt 的市场占有率。
安全威胁分析
如前所述，云平台的弹性资源分配特点被广泛使用，而CA开始大量采用自动化颁发机制，但这两者结合却引入了新的安全威胁。即当陈旧或被遗弃的DNS域名记录（stale and abandoned DNS entries）指向云端的可分配 IP 时，攻击者可以通过从云端申请分配到改 IP，完成 domain takeover 攻击，并在此基础上，根据该域名的特点，可以进一步利用该域名的控制权完成：
- 分发恶意代码，当第三方从该域名下加载如 JS 脚本等代码等，攻击者可以植入恶意代码。
- 申请 SSL 证书，利用 CA 基于域名验证的特点申请证书，从而获取合法的 SSL 证书。
- 控制 NS 服务器，stale 的 NS 记录可能导致攻击者获取该域名的控制权，如某域名利用多个 DNS 服务器进行负载均衡或冗余时存在一条 stale NS 记录。
- 发送邮件等，当存在 stale MX 记录时，攻击者发送基于该域名的钓鱼邮件。
- Sub-domain 攻击，除了 top-level 域名外，sub-domain 的 stale DNS 记录也可以被利用进行攻击。
本文将这种威胁具体命名为 IP user-after-free 漏洞，可以看到，此漏洞的关键在于存在 stale DNS 记录，即域名指向了一个已释放云端 IP，而攻击者能及时从云平台申请到该 IP 地址。因而，Stale DNS 记录的存在时间决定了攻击的时间窗口，如以下四种 stale DNS 情况：
- Early Migration：域名 IP 映射已更新指向新的 IP 地址，然后释放旧的 IP 地址。此时，攻击窗口最小，取决于 DNS 记录的 cache 时间。但实际情况下存在很多 DNS 服务器并不遵守 DNS 的 TTL 时间，因而此情况依然可能被攻击。
- Delayed Migration：新的域名 IP 映射在等待权威域名服务器进行更新。虽然攻击时间窗口取决于域名的更新延迟时间，而且在域名更新成功指向新 IP 后，攻击者也将不能再 domain takeover，但攻击者依然可以利用申请到的有效 SSL 证书等进行更长期的中间人攻击。
- Auxiliary：一个域名拥有多条对应 IP 映射记录，同时指向了新、旧 IP。攻击者可以主动 DoS，使 DNS 解析到就已获取的旧 IP，或者利用 DNS round-robin 特点获取部分数据流量等。
- Abandoned：对应域名已不再使用，但该域名 IP 映射依然存在。此种情况攻击者拥有最大的攻击时间窗口，但访问该域名的受害者数量一般也很少。
可以看出，不管哪种 stale DNS 记录情况，都存在被攻击者利用的可能。当然，在攻击时间窗口内，攻击者需要及时从云平台申请到一个被攻击目标释放的IP地址，而这取决于云平台的 IP 地址池大小。因此，本文针对 Amazon Web Services（ASW）和 Microsoft Azure 云平台，详细测试了 IP 地址 use-after-free 的可行性，即针对云平台的不同部署区域，不断的循环申请并释放 IP 地址。
在不到两个月的时间中，通过 14,159,705 次申请，共分配了1,613,082 的不同的 IP 地址，而所需成本仅 $31.06。针对这些地址，作者分析了 IP 地址被重复分配所需的时间，如 Figure 1 的 boxplot 图所示（AWS平台），云平台的大部分区域只需不到一天的时间就会发生地址被重复分配的现象。
图一: 再次分配相同IP地址所需时间
同时，Figure 2 以周为单位显示了申请IP地址时的新旧情况。可以看到，大部分测量结果符合预期，刚开始申请到了大量的的新 IP 地址，随之逐渐减少，直到耗尽整个 IP 地址池。当然，其中也存在如 Figure 2(e) 这种情况，在第三周时大量的新 IP 地址被加入地址池。
总的来说，实际测量结果表明，在云平台中，IP use-after-free 的问题真实存在。
图二： 亚马逊EC2云平台下的IP地址(新、旧)翻转情况，如，各区域每天申请到新IP的比例
受影响的域名
既然云平台中存在 IP 地址 use-after-free 的问题，本文就进一步分析了是否大量存在受此问题影响的域名。基于 Farsight 在2017年4月11日至8月9日之间的 passive DNS 数据，本文提取了指向 AWS 和 Azure 等平台 IP 地址的 DNS 响应记录（包含 130,274,722 个域名），并针对这些域名测试了 IP 地址的可访问性（ping 可达或常见端口可访问等）。当未收到 IP 地址的响应时，就判断该IP地址已经被释放回云平台中（文中 argue了这个判断的合理性，至少可以获取到了上限值）。
因而，本文过滤出了720,180个域名，它们指向了已被释放的 IP 地址，这些域名即为可能受 IP 地址 use-after-free 问题影响的可攻击目标。在这些域名中，80.31%的expire domain-IP 映射由于迁移延误造成，17.24%的 Domain-IP 映射属于被遗弃未再用的，2.45%的属于域名的额外IP映射。从结果看，虽然 stale 域名的占比很小（占比0.5%），但从数量上看依然很大，它们都可能受到 domain takeover、phishing 等攻击。
Domain takeover攻击验证
在获取受影响域名列表后，论文通过从 Let’s Encrypt 获取证书来证明域名 takeover 攻击的可行性。在区域“us-west-2”中，实验仅需27分55秒就获得了被目标释放的IP地址（2IP/秒的云端IP地址分配速度），然后进一步申请获取了有效证书。
Mitigation
之前的论文描述了 IP user-after-free 的漏洞在互联网中普遍存在，并且由于基于域名验证的SSL证书颁发机制使该漏洞的安全威胁进一步加剧。因而，论文认为首先需要解决基于域名验证的证书颁发机制所引发的问题。
目前，互联网中存在多个CA，都可以颁发域名的合法证书，任何一个CA出问题都会对整个SSL证书系统带来安全威胁，如DigiNotar入侵事件[1]和Symantec CA颁发非法证书的问题[2]。针对SSL证书的安全问题，目前也已经提出了多种解决方案，如 CRLite[3]，CRLSet[4] 和 Certificate Transparency[5]，但 CRLite 还未被广泛采用，CRLset 主要用于在紧急情况下阻止特定证书，而Certificate Transparency因Google要求CA必须发布已颁发证书的Transparency Log [6]被广泛应用。所以，本文提出的解决方案修改Let’s Encrypt等采用的ACME协议[7]，通过在基于域名的认证过程中引入Certificate Transparency来确认证书申请者的身份，如 Figure 3 所示。在 Figure 3 中，CA 在收到证书申请时，额外向 CT（Certificate Transparency）日志查询是否存在已颁发证书。若存在，则在验证过程中，要求申请者利用已有证书来完成验证 challenge。
图三：缓解域接管攻击的证书申请流程
当然，这个解决方案也存在一些失败案例，如：合法域名拥有者的老证书秘钥遗失；合法证书已过期；因域名交易等的拥有者合法转移，新拥有者没有老证书私钥等情况。这些情况下都无法通过基于已有证书的 challenge 验证。针对这些案例，论文也针对性进行了论述，并建议CA需要进一步采取 DNS 记录或 Whois 邮件等验证方式。
除了 SSL 证书验证的问题，对于云平台来说，可以采取的防御措施有限制 IP 分配速度；为不同的云租户分配不同的 IP 地址池；或者监控云租户使用过的 IP 地址，并进行异常报告等。对于云租户自身来说，本文也建议了继续使用相同的 IP，或者尽量等待一周以上时间，保证旧 DNS 记录被过期清除。同时，DNS 服务器自身也应该遵守 RFC 标准，及时清除过期 DNS 记录。
总结
这篇论文描述互联网中存在大量指向了云平台中可分配IP的 stale DNS 记录，从而攻击者可以从云平台分配到这些 IP，完成 domain takeover 并进一步进行 SSL 证书申请等。从安全漏洞方面看，这篇论文讨论的问题和2016年发表于CCS的《All Your DNS Records Point to Us: Understanding the Security Threats of Dangling DNS Records》[8]是一样的，[8]中将这种现象称之为 Dare(dangling DNS record)记录。从论文内容上说，本文利用Farsight的Passive记录更全面的分析了互联网中的stale DNS记录，说明了此问题的严重性；并进一步实际验证了在云端获取目标IP的可行性，针对SSL证书颁发过程提出了更现实的解决方案。
注：论文发表于NDSS 2018
论文链接：Click Here
参考文献
[1] J. Prins and B. U. Cybercrime. DigiNotar Certificate Authority Breach Operation Black Tulip. 2011.
[2] B. Budington. Symantec Issues Rogue EV Certificate for Google.com. 2015. https:/ / www.eff.org/deeplinks/2015/09/symantec -issuesrogue-ev-certificate-googlecom.
[3] J. Larisch, D. Choffnes, D. Levin, B. M. Maggs, A. Mislove, and C.Wilson. “CRLite: A Scalable System for Pushing All TLS Revocations to All Browsers”. In: Proc. IEEE Security & Privacy . 2017.
[4] The Chromium Project. The Chromium Project: CRLSets. https://dev.chromium.org/Home/chromium-security/crlsets.
[5] B. Laurie, A. Langley, and E. Kasper. Certificate Transparency . RFC 6962 (Experimental). RFC. RFC Editor, June 2013. https://www.rfc-editor.org/rfc/rfc6962.txt
[6]Ryan Sleevi. Certificate Transparency in Chrome – Change to Enforcement Date. https://groups.google.com/a/chromium.org/forum/#!msg/ct-policy/sz_3W_xKBNY/6jq2ghJXBAAJ
[7] R. Barnes, J. Hoffman-Andrews, and J. Kasten. Automatic Certificate Management Environment(ACME). Internet-Draft. June 2017. http://www.ietf.org/internet-drafts/draft-ietf-acme-acme-07.txt.
[8] D. Liu, S. Hao, and H. Wang. “All Your DNS Records Point to Us: Understanding the Security Threats of Dangling DNS Records”. In: Proc. ACM Conference on Computer and Communications Security (CCS). 2016.
[9] Intent To Deprecate And Remove: Public Key Pinning. https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/he9tr7p3rZ8
[10] Josh Aas. Milestone: 100 Million Certificates Issued. June 2017. https://letsencrypt.org//2017/06/28/hundred-million-certs.html.
