本文進一步從時間和花銷上，分析了這種獲取DNS域名指向的雲端IP的實際可行性。在極端條件下，攻擊者可以在70秒之内就申請到雲端IP并完成攻擊。這時間遠低于普通的DNS記錄TTL值，因而這種攻擊可以發生在正常的雲端服務遷移過程中（IP被臨時釋放），使此安全問題導緻的攻擊面更為廣泛。随之，本文提出上述DomainTake問題的解決方案，即将該域名的已有驗證加入到新的驗證過程中（在新申請證書時，基于申請過的證書進行認證）。同時，也針對域名所有者和雲平台管理員提供了安全建議。
過去的十年間，因用戶可以按需申請資源，AWS和Azure等雲平台被廣泛的用于部署各種雲端服務，如Azure月均增加120,000個用戶，AWS已經有1,000,000個活躍用戶。同時，TLS也因為對安全的重視而被廣泛使用，如在HTTPS、HTTP2等中用于提供數據傳輸的加密和認證。因而，為了應對大量SSL證書的申請處理負擔，SSL證書的頒發過程也引入了自動化機制，主要依賴于域名驗證完成對申請者身份的驗證。如，證書頒發機構Let'sEncrypt（2016年4月開始提供服務）提供了基于ACME協議（AutomaticCertificateManagementEnvironmentprotocol)的自動化證書申請工具，僅在15個月内就頒發了超過100,000,000個證書[10]。證書頒發機構在為對應域名頒發證書時，需要驗證證書申請者是否擁有對應域名。現在大部分證書頒發結構CA采取的是基于域名的驗證方法，即證書申請者需要證明其對所申請域名擁有控制權，具體方法有：
（1）DNS記錄驗證，如要求申請者加一條具有指定随機數的TXT記錄；
（2）郵件驗證，CA向WHOIS記錄中的注冊郵箱或常見的“postamaster”、“sslmaster”等郵箱發送帶token的驗證郵件，要求申請者點擊或回複；
（3）Web認證，要求申請者在該域名下提供HTTP服務，并且在CA指定的URL路徑下部署一個帶有特定token的文件，以供CA進行HTTP訪問驗證。
對于Let'sEncrypt來說，為了更快促進TLS的廣泛使用，Let'sEncrpyt提供了免費的證書申請服務。同時為了減少證書私鑰洩露或錯誤頒發等危害，Let'sEncrpyt頒發的證書隻有90天有效期。因而，Let'sEncrpyt采用了自動化的基于Web的驗證方式，這迅速增加了互聯網中的SSL證書使用率，并提高了Let'sEncrpyt的市場占有率。
安全威脅分析
如前所述，雲平台的彈性資源分配特點被廣泛使用，而CA開始大量采用自動化頒發機制，但這兩者結合卻引入了新的安全威脅。即當陳舊或被遺棄的DNS域名記錄（staleandabandonedDNSentries）指向雲端的可分配IP時，攻擊者可以通過從雲端申請分配到改IP，完成domaintakeover攻擊，并在此基礎上，根據該域名的特點，可以進一步利用該域名的控制權完成：
分發惡意代碼，當第三方從該域名下加載如JS腳本等代碼等，攻擊者可以植入惡意代碼。
申請SSL證書，利用CA基于域名驗證的特點申請證書，從而獲取合法的SSL證書。
控制NS服務器，stale的NS記錄可能導緻攻擊者獲取該域名的控制權，如某域名利用多個DNS服務器進行負載均衡或冗餘時存在一條staleNS記錄。
當存在staleMX記錄時，攻擊者發送基于該域名的釣魚郵件。
Sub-domain攻擊，除了top-level域名外，subdomain的staleDNS記錄也可以被利用進行攻擊。
本文将這種威脅具體命名為IPuser-after-free漏洞，可以看到，此漏洞的關鍵在于存在staleDNS記錄，即域名指向了一個已釋放雲端IP，而攻擊者能及時從雲平台申請到該IP地址。因而，StaleDNS記錄的存在時間決定了攻擊的時間窗口，如以下四種staleDNS情況：
（1）EarlyMigration：域名IP映射已更新指向新的IP地址，然後釋放舊的IP地址。此時，攻擊窗口最小，取決于DNS記錄的cache時間。但實際情況下存在很多DNS服務器并不遵守DNS的TTL時間，因而此情況依然可能被攻擊。
（2）DelayedMigration：新的域名IP映射在等待權威域名服務器進行更新。雖然攻擊時間窗口取決于域名的更新延遲時間，而且在域名更新成功指向新IP後，攻擊者也将不能再domaintakeover，但攻擊者依然可以利用申請到的有效SSL證書等進行更長期的中間人等攻擊。
（3）Auxiliary：一個域名擁有多條對應IP映射記錄，同時指向了新、舊IP。攻擊者可以主動DoS，使DNS解析到就已獲取的舊IP，或者利用DNSround-robin特點獲取部分數據流量等。
（4）Abandoned：對應域名已不再使用，但該域名IP映射依然存在。此種情況攻擊者擁有最大的攻擊時間窗口，但訪問該域名的vitim數量一般也很少。
可以看出，不管那種staleDNS記錄情況，都存在被攻擊者利用的可能。當然，在攻擊時間窗口内，攻擊者需要及時從雲平台申請到一個被攻擊目标釋放的IP地址，而這取決于雲平台的IP地址池大小。因此，本文針對AmazonWebServices（ASW）和MicrosoftAzure雲平台，詳細測試了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地址被加入地址池。
總的來說，實際測量結果表明，在雲平台中，IPuse-afterfree的問題真實存在。
圖1再次分配相同IP地址所需時間
圖2亞馬遜網絡服務EC2雲上的IP地址流失，每個地區每天新觀察的IP地址受影響的域名
既然雲平台中存在IP地址use-after-free的問題，本文就進一步分析了是否大量存在受此問題影響的域名。基于Farsight在2017年4月11日至8月9日之間的passiveDNS數據，本文提取了指向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%），但從數量上看依然很大，它們都可能受到domaintakeover、phishing等攻擊。
圖3緩解域接管攻擊的證書申請流程Domaintakeover攻擊驗證
在獲取受影響域名列表後，本文通過從Let'sEncrypt獲取證書來證明域名takeover攻擊的可行性。在區域“uswest-2”中，實驗僅需27分55秒就獲得了被目标釋放的IP地址（2IP/秒的雲端IP地址分配速度），然後進一步申請獲取了有效證書。
Mitigation
前文描述了IPuser-after-free的漏洞在互聯網中普遍存在，并且由于基于域名驗證的SSL證書頒發機制使該漏洞的安全威脅進一步加劇。因而，本文認為首先需要解決基于域名驗證的證書頒發機制所引發的問題。
目前，互聯網中存在多個CA，都可以頒發域名的合法證書，任何一個CA出問題都會對整個SSL證書系統帶來安全威脅，如DigiNotar入侵事件[1]和SymantecCA頒發非法證書的問題[2]。針對SSL證書的安全問題，目前也已經提出了多種解決方案，如CRLite[3]，CRLSet[4]和CertificateTransparency[5]，但CRLite還未被廣泛采用，CRLset主要用于在緊急情況下阻止特定證書，而CertificateTransparency因Google要求CA必須發布已頒發證書的TransparencyLog[6]被廣泛應用。所以，本文提出的解決方案修改Let'sEncrypt等采用的ACME協議[7]，通過在基于域名的認證過程中引入CertificateTransparency來确認證書申請者的身份，如圖3所示。在圖3中，CA在收到證書申請時，額外向CT（CertificateTransparency）日志查詢是否存在已頒發證書。若存在，則在驗證過程中，要求申請者利用已有證書來完成驗證challenge。
當然，這個解決方案也存在一些failurecases，如：合法域名擁有者的老證書秘鑰遺失；合法證書已過期；因域名交易等的擁有者合法轉移，新擁有者沒有老證書私鑰的情況。這些情況下都無法通過基于已有證書的challenge驗證。針對這些cases，本文也針對性進行了論述，并建議CA需要進一步采取DNS記錄或WHOIS郵件等驗證方式。
除了SSL證書驗證的問題，對于雲平台來說，可以采取的防禦措施有限制IP分配速度；為不同的雲租戶分配不同的IP地址池；或者監控雲租戶使用過的IP地址，并進行異常報告等。對于雲租戶自身來說，本文也建議繼續使用相同的IP，或者盡量等待一周以上時間，保證舊DNS記錄被過期清除。同時，DNS服務器自身也應該遵守RFC标準，及時清除過期DNS記錄。
這篇論文描述互聯網中存在大量指向了雲平台中可分配IP的staleDNS記錄，從而攻擊者可以從雲平台分配到這些IP，完成domaintakeover并進一步進行SSL證書申請等。從安全漏洞方面看，這篇論文讨論的問題和2016年發表于CCS的《AllYourDNSRecordsPointtoUs:UnderstandingtheSecurityThreatsofDanglingDNSRecords》[8]是一樣的，[8]中将這種現象稱之為Dare(danglingDNSrecord)記錄。從論文内容上說，本文利用Farsight的Passive記錄更全面的分析了互聯網中的staleDNS記錄，說明了此問題的嚴重性；并進一步實際驗證了在雲端獲取目标IP的可行性，針對SSL證書頒發過程提出了更現實的解決方案。
（責編：楊潔）
（作者單位為清華大學）
參考文獻
[1]J.PrinsandB.U.Cybercrime.DigiNotarCertificateAuthorityBreachOperationBlackTulip.2011.
[2]B.Budington.SymantecIssuesRogueEVCertificateforGoogle.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,andC.Wilson.“CRLite:AScalableSystemforPushingAllTLSRevocationstoAllBrowsers”.In:Proc.IEEESecurity&Privacy.2017.
[4]TheChromiumProject.TheChromiumProject:CRLSets.https://dev.chromium.org/Home/chromium-security/crlsets.
[5]B.Laurie,A.Langley,andE.Kasper.CertificateTransparency.RFC6962(Experimental).RFC.RFCEditor,June2013.https://www.rfc-editor.org/rfc/rfc6962.txt
[6]RyanSleevi.CertificateTransparencyinChrome-ChangetoEnforcementDate.https://groups.google/a/chromium.org/forum/#!msg/ct-policy/sz_3W_xKBNY/6jq2ghJXBAAJ
[7]R.Barnes,J.Hoffman-Andrews,andJ.Kasten.AutomaticCertificateManagementEnvironment(ACME).Internet-Draft.http://www.ietf.org/internet-drafts/draft-ietf-acmeacme-07.txt.June2017.
[8]D.Liu,S.Hao,andH.Wang.“AllYourDNSRecordsPointtoUs:UnderstandingtheSecurityThreatsofDanglingDNSRecords”.In:Proc.ACMConferenceonComputerandCommunicationsSecurity(CCS).2016.
[9]IntentToDeprecateAndRemove:PublicKeyPinning.https://groups.google/a/chromium.org/forum/#!topic/blink-dev/he9tr7p3rZ8
[10]JoshAas.Milestone:100MillionCertificatesIssued.https://letsencrypt.org//2017/06/28/hundred-million-certs.html.June2017.