Cloud Strife：减轻域验证证书的安全风险
本文进一步从时间和花销上，分析了这种获取D N S域名指向的云端I P的实际可行性。在极端条件下，攻击者可以在70秒之内就申请到云端I P并完成攻击。这时间远低于普通的D N S记录T T L值，因而这种攻击可以发生在正常的云端服务迁移过程中（IP被临时释放），使此安全问题导致的攻击面更为广泛。随之，本文提出上述Domain Take问题的解决方案，即将该域名的已有验证加入到新的验证过程中（在新申请证书时，基于申请过的证书进行认证）。同时，也针对域名所有者和云平台管理员提供了安全建议。
过去的十年间，因用户可以按需申请资源，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采取的是基于域名的验证方法，即证书申请者需要证明其对所申请域名拥有控制权，具体方法有：
（1）DNS记录验证，如要求申请者加一条具有指定随机数的TXT记录；
（2）邮件验证，CA向WHOIS记录中的注册邮箱或常见的“postamaster”、“sslmaster”等邮箱发送带token的验证邮件，要求申请者点击或回复；
（3）Web认证，要求申请者在该域名下提供HTTP服务，并且在CA指定的URL路径下部署一个带有特定token的文件，以供CA进行HTTP访问验证。
对于Let's Encrypt来说，为了更快促进TLS的广泛使用，Let's Encrpyt提供了免费的证书申请服务。同时为了减少证书私钥泄露或错误颁发等危害，Let's Encrpyt颁发的证书只有90天有效期。因而，Let's Encrpyt采用了自动化的基于Web的验证方式，这迅速增加了互联网中的SSL证书使用率，并提高了Let's Encrpyt的市场占有率。
安全威胁分析
如前所述，云平台的弹性资源分配特点被广泛使用，而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域名外，subdomain的stale DNS记录也可以被利用进行攻击。
本文将这种威胁具体命名为IP user-after-free漏洞，可以看到，此漏洞的关键在于存在stale DNS记录，即域名指向了一个已释放云端IP，而攻击者能及时从云平台申请到该IP地址。因而，Stale DNS记录的存在时间决定了攻击的时间窗口，如以下四种stale DNS情况：
（1）Early Migration：域名IP映射已更新指向新的IP地址，然后释放旧的IP地址。此时，攻击窗口最小，取决于DNS记录的cache时间。但实际情况下存在很多DNS服务器并不遵守DNS的TTL时间，因而此情况依然可能被攻击。
（2）Delayed Migration：新的域名IP映射在等待权威域名服务器进行更新。虽然攻击时间窗口取决于域名的更新延迟时间，而且在域名更新成功指向新IP后，攻击者也将不能再domain takeover，但攻击者依然可以利用申请到的有效SSL证书等进行更长期的中间人等攻击。
（3）Auxiliary：一个域名拥有多条对应IP映射记录，同时指向了新、旧IP。攻击者可以主动DoS，使DNS解析到就已获取的旧IP，或者利用DNS round-robin特点获取部分数据流量等。
（4）Abandoned：对应域名已不再使用，但该域名IP映射依然存在。此种情况攻击者拥有最大的攻击时间窗口，但访问该域名的vitim数量一般也很少。
可以看出，不管那种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地址被重复分配所需的时间，如图1的boxplot图所示（AWS平台），云平台的大部分区域只需不到一天的时间就会发生地址被重复分配的现象。
同时，图2以周为单位显示了申请IP地址时的新旧情况，可以看到，大部分测量结果符合预期，刚开始申请到了大量的的新IP地址，随之逐渐减少，直到耗尽整个IP地址池。当然，其中也存在如图2(e)这种情况，在第三周时大量的新IP地址被加入地址池。
总的来说，实际测量结果表明，在云平台中，IP use-afterfree的问题真实存在。
图1 再次分配相同IP地址所需时间
图2 亚马逊网络服务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%的过期域名-IP映射由于迁移延误造成，17.24%的域名-IP映射属于被遗弃未再用的，2.45%的属于域名的额外IP映射。从结果看，虽然stale域名的占比很小（占比0.5%），但从数量上看依然很大，它们都可能受到domain takeover、phishing等攻击。
图3 缓解域接管攻击的证书申请流程Domain takeover攻击验证
在获取受影响域名列表后，本文通过从Let's Encrypt获取证书来证明域名takeover攻击的可行性。在区域“uswest-2”中，实验仅需 27分55秒就获得了被目标释放的I P地址（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来确认证书申请者的身份，如图3所示。在图3中，CA在收到证书申请时，额外向CT（Certificate Transparency）日志查询是否存在已颁发证书。若存在，则在验证过程中，要求申请者利用已有证书来完成验证challenge。
当然，这个解决方案也存在一些failure cases，如：合法域名拥有者的老证书秘钥遗失；合法证书已过期；因域名交易等的拥有者合法转移，新拥有者没有老证书私钥的情况。这些情况下都无法通过基于已有证书的challenge验证。针对这些cases，本文也针对性进行了论述，并建议CA 需要进一步采取DNS记录或WHOIS邮件等验证方式。
除了SSL证书验证的问题，对于云平台来说，可以采取的防御措施有限制I P分配速度；为不同的云租户分配不同的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证书颁发过程提出了更现实的解决方案。
（责编：杨洁）
（作者单位为清华大学）
参考文献
[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. http://www.ietf.org/internet-drafts/draft-ietf-acmeacme-07.txt. June 2017.
[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. https://letsencrypt.org//2017/06/28/ hundred-million-certs.html. June 2017.