背景簡介
CDN(Content Delivery Network) 是雲服務廠商提供的一種Web內容加速分發服務。
對於攻擊者來說，CDN提供了大量分佈於全球各地的邊緣節點IP，並且可以將源服務器隱藏在CDN節點之後，所以CDN非常適合被用於保護C2的通信。
本文介紹了我們在某些CDN實現中發現的一些特性，以及如何利用這些特性隱藏C2通信流量，我們將這種新型的基於CDN的隱蔽通信方法稱為Domain Borrowing。
該研究已經發表在Black Hat Asia 2021。
歷史研究
Domain Fronting
Domain Fronting[1]是Fifield David等研究人員在2015年提出的一種基於CDN的隱蔽通信方法，該方法至今仍被廣泛應用於真實APT攻擊和紅藍對抗中。
Domain Fronting的工作原理如下圖所示，主要利用了CDN轉發HTTPS請求時的特性。
在處理HTTPS請求時，CDN會首先將它解密，並根據HTTP Host的值做請求轉發。
如果客戶端想要訪問一個非法網站forbidden.com，它可以使用一個CDN上的合法的域名allow.com作為SNI, 然後使用forbidden.com作為HTTP Host與CDN進行HTTPS通信。之後，CDN會將HTTP請求重新封裝，並發往forbidden.com的源服務器。
這種情況下，客戶端實際通信的對像是forbidden.com，但在流量監控設備看來，客戶端是在與allow.com通信，即客戶端將流量成功偽裝成了與allow.com通信的流量。
Domain Fronting也有一些局限性。
Domain Fronting流量的一個顯著特點是SNI和Host不相等。企業的防守方可以部署HTTPS流量解密設備，並對比流量中的SNI和Host是否相等，如果不相等則說明是該流量是Domain Fronting流量。這也是MITRE ATT&CK[2]中建議的檢測方式。
並且，隨著該技術不斷在真實網絡攻擊中被使用，雲廠商也逐漸意識到了Domain Fronting的危害，目前Cloudflare、AWS CloudFront、Google Cloud CDN等廠商也都紛紛禁用了這種隱蔽通信方法。
Domain Hiding
Domain Hiding[2]是Erik Hunstad在DEFCON28上提出的隱蔽通信方法，這種方法主要依賴於TLSv1.3和ESNI。
ESNI是IETF的一個草案，目前只有Cloudflare CDN支持該標準。
通信的客戶端可以從_esni.forbidden.com的TXT記錄中獲取密鑰，並使用該密鑰加密SNI，在HTTPS Client Hello中即可使用加密後的SNI即ESNI與CDN進行通信。
因為DNS查詢可以通過DNS over TLS/HTTPS進行，所以整個HTTPS通信流量中不會出現明文的forbidden.com。流量監控設備也就無法識別該流量是否為非法流量。
Erik Hunstad還發現Cloudflare處理ESNI的一個特性，如果Client Hello裡同時出現SNI和ESNI， Cloudflare會忽略SNI字段，使用ESNI完成接下來的通信過程。這樣攻擊者在使用ESNI通信時，就可以將SNI設置為一個高信譽的的域名來偽裝通信流量。
Domain Hiding也存在一些局限性。一方面，Cloudflare現在已經不支持Client Hello裡同時出現SNI和ESNI。另一方面，為了進行流量審查，很多企業甚至國家級防火牆會直接禁止使用ESNI通信。
Domain Borrowing
對攻擊者來說，一個理想的C2通信流量需要滿足以下幾個條件
擁有大量IP地址供C2 agent連接使用高信譽的的域名和合法的HTTPS證書即使HTTPS流量可以被解密，解密後的流量也應該與正常流量高度相似，特別是SNI==Host通信協議不依賴於特殊協議標準通信方式不在特殊地區受限制下面將詳細介紹我們在某些CDN實現中發現的一些特性，以及如何利用這些特性滿足一個理想C2的隱蔽通信需求。
在HTTPS CDN的工作流程中，DNS只是用於尋找CDN邊緣節點，並不直接參與HTTPS通信。
所以客戶端可以直接拋棄DNS解析流程，或者使用另一個加速域名cdn.b.com做DNS解析, 然後使用cdn.a.com作為SNI/Host與CDN邊緣節點通信。
為了偽裝C2通信流量，需要保證流量中SNI和Host為高信譽度域名，也就需要我們具備在CDN上註冊高信譽度域名的能力。
我們調研了國外常見CDN加速域名註冊時的域名歸屬認證機制，結果如下圖所示。
Azure CDN使用DNS CNAME記錄驗證域名歸屬，Cloudflare使用DNS NS記錄驗證域名歸屬，使用者配置相應的DNS記錄後才可以使用CDN服務。
AWS CloudFront使用域名的HTTPS證書來驗證域名歸屬權，使用者需要提供域名的合法HTTPS證書才可使用CDN服務。
Google Cloud CDN的AnyCast機制需要使用者直接將加速域名解析配置為Google Cloud CDN指定的某個固定IP，雖然AnyCast機制的目的不是為了進行域名歸屬驗證，但是確實達到了歸屬驗證的效果。
Fastly，StackPath，KeyCDN，CDN77和CDNSun則不存在域名歸屬驗證，攻擊者可以在這些CDN上任意註冊高信譽度域名的加速服務, 如下圖所示。
以www.blackhat.com為例，雖然我們可以在上述CDN中註冊該域名的CDN加速服務，但是我們並沒有這個域名的合法HTTPS證書
當CDN無法找到SNI中的域名對應的證書時，通常有兩種處理邏輯
大多數CDN會返回一個默認的證書給客戶端少數CDN會直接斷開與客戶端的TCP連接如下圖所示，Fastly CDN會返回default.ssl.fastly.net的證書給客戶端
在這種情況下，客戶端可以選擇忽略HTTPS證書驗證並與CDN邊緣節點進行HTTPS通信
這時HTTPS流量中SNI == Host == www.blackhat.com，可以繞過對Domain Fronting的檢測
雖然default.ssl.fastly.net證書比自簽名證書可信度要高，但是對於這個HTTPS連接來說這仍然是一個非法的證書
那麼應該如何獲取高信譽度域名的合法的證書？最簡單的方法就是通過漏洞
如果攻擊者可以獲取目標站點的RCE或者任意文件下載，攻擊者可以直接獲得域名的證書和私鑰
如果攻擊者發現了目標站點的RCE、subdomain takeover、任意文件上傳（尤其是雲存儲的任意文件上傳）等漏洞，攻擊者可以通過HTTP驗證（.well-known）的方式申請目標站點域名的新的證書
並且由於證書的有效期比較長，在站點漏洞被修復後，攻擊者申請的證書可能仍然是有效的
ppe.verify.microsoft.com的subdomain takeover漏洞（該漏洞由作者一個朋友發現）已經被修復，但是申請下來的證書仍然有效
因為AWS CloudFront僅通過HTTPS證書來做域名歸屬驗證，所以我們拿到一個合法的證書之後就可以在AWS CloudFront上註冊該域名的CDN服務
成功註冊之後，C2 agent就可以使用這個域名上線
C2 agent可以使用blogs.aws.amazon.com進行DNS解析尋找CDN邊緣節點，HTTPS請求中的SNI和HTTP Host都可以設置為ppe.verify.microsoft.com, 並且HTTPS證書使用的是我們上傳的該域名的合法證書。
是否有辦法在不利用目標站點漏洞的情況下獲取高信譽度域名的合法證書？
我們在研究各個CDN廠商的HTTPS證書分發流程時發現了部分CDN廠商的實現存在一些特性，我們可以利用這些特性借用其他CDN用戶上傳的合法證書
首先來看一下正確的證書分發流程
當用戶使用cdn.example.com作為SNI進行HTTPS請求時，CDN會從他的數據庫中查找cdn.example.com的證書
查詢邏輯類似select certificate from db where domain_name = “cdn.example.com”
（真實情況會更加複雜，這裡只是用一個簡單的數據庫操作來演示CDN的處理邏輯）
很明顯，表中的第一行數據符合查詢條件, *.example.com.crt 會被select出來，並返回給客戶端
但是部分CDN的實現存在問題
攻擊者在CDN上註冊加速域名static.example.com，但是攻擊者並沒有該域名的證書。CDN會在數據庫中新增一條數據，如下圖所示。
客戶端使用static.example.com作為SNI向CDN發送HTTPS請求，CDN從數據庫中查詢static.example.com的證書
與正確的證書分發流程不同的是，這裡的查詢邏輯類似select certificate from db where certificate matches “static.example.com”
第一行數據中的通配符證書*.example.com.crt可以匹配到static.example.com
但是這個證書是Alice上傳的，也就是說Alice上傳的通配符證書*.example.com.crt匹配到了攻擊者註冊的CDN加速域名static.example.com
之後CDN會將Alice上傳的證書返回給客戶端，於是客戶端便獲得了一個對於當前HTTPS連接來說合法的通配符HTTPS證書
通過CDN的這個特性，攻擊者就可以藉用其他用戶上傳到CDN的通配符HTTPS證書，並與CDN建立合法的HTTPS連接
我們發現StackPath和CDN77都存在這個特性，所以我們可以藉用用戶上傳到StackPath和CDN77上的通配符HTTPS證書
並且StackPath和CDN77上有很多高信譽度的域名
尤其是StackPath是JS Foundation的CDN服務提供商, 有一些非常知名的前端項目比如Bootstrap和FontAwesome將他們的靜態資源部署在StackPath上
作為知名前端項目，Bootstrap和FontAwesome在Alex top 1k網站上使用率非常高
攻擊者可以藉用他們的子域名和合法的HTTPS證書將C2通信偽造成Bootstrap和FontAwesome的通信流量
以Bootstrap為例，攻擊者可以在CDN上註冊任意bootstrapcdn.com的子域名，甚至是一個並不存在的子域名，比如static.bootstrapcdn.com
使用curl去測試，可以發現，當使用static.bootstrapcdn.com作為SNI進行HTTPS通信時，CDN會將*.bootstrapcdn.com返回給客戶端
於是攻擊者就可以將static.bootstrapcdn.com作為SNI和Host，借用StackPath上合法的通配符HTTPS證書*.bootstrapcdn.com進行C2通信。
無論是通信的HTTPS流量還是解密之後的HTTP流量，看起來都是一個高信譽度域名static.bootstrapcdn.com的合法通信流量。
防禦方法
對於企業防守方來說，最簡單有效的Domain Borrowing防禦方法是在防火牆檢測HTTPS SNI的DNS解析結果是否與通信的目標IP地址相同, 並且建議配合DNS Proxy一起使用以減少誤報。
對於CDN廠商來說，可以採取以下方法禁用Domain Borrowing。
用戶在CDN上註冊加速域名時，嚴格校驗域名歸屬權客戶端連接CDN時，正確地分發HTTPS證書對於網站管理員來說，可以通過下列方式緩解網站證書被濫用的問題。
被入侵之後吊銷現有證書，防止證書被攻擊者竊取和濫用通過證書透明度檢查攻擊者是否申請了該網站域名的新的證書0x04 案例：繞過Palo Alto防火牆
Palo Alto Firewall PAN-VM是Palo Alto的下一代防火牆產品，支持很多優秀的特性，比如SSLv3.0-TLSv1.3的流量解密和Anti-Spyware功能。
對SSL解密功能支持的算法如下圖所示
Anti-Spyware功能內置了各類惡意軟件通信流量的檢測規則和一些通用的檢測邏輯比如Anti-Spyware Evasion Signatures[4]。
Anti-Spyware Evasion Signatures包含兩條檢測規則Suspicious HTTP Evasion Found和Suspicious TLS Evasion Found
Suspicious HTTP Evasion Found用於檢測HTTP Host的DNS解析結果是否與通信目的IP地址相同
Suspicious HTTPS Evasion Found用於檢測HTTPS SNI的DNS解析結果是否與通信目的IP地址相同
所以理論上Anti-Spyware Evasion Signatures是可以檢測Domain Borrowing的。但是我們研究發現，Palo Alto Firewall在這個功能的實現上存在問題。
如果防火牆無法解析出SNI和Host域名的IP地址，則這條通信流量會直接通過檢測。
對於Domain Borrowing來說，SNI和Host可以被設置為一個不存在的域名（即該域名沒有IP地址），這樣就可以繞過Palo Alto Firewall的檢測。
以img.fontawesome.com為例
該域名不是一個真實存在的域名，它沒有任何的DNS記錄
攻擊者可以在StackPath上註冊img.fontawesome.com的CDN加速服務，並使用img.fontawesome.com作為SNI和Host，借用StackPath上合法的通配符HTTPS證書*.fontawesome.com進行C2通信。
在檢測設備看來，攻擊者的通信流量就是一個完全合法的高信譽度域名img.fontawesome.com的HTTPS通信流量，並且可以繞過Anti-Spyware Evasion Signatures的檢測。
該繞過方法已經報告給Palo Alto PSIRT。
Covenant Implant Template
我們實現了一個使用Domain Borrowing通信的Covenant[5] Implant Template，希望幫助攻擊方在紅藍對抗中應用Domain Borrowing技術，也希望能夠幫助防守方加強對此類通信流量的檢測能力。
Github Repo: https://github.com/Dliv3/DomainBorrowing
參考資料
[1] https://www.icir.org/vern/papers/meek-PETS-2015.pdf[2] https://attack.mitre.org/techniques/T1090/004/[3] https://media.defcon.org/DEF%20CON%2028/DEF%20CON%20Safe%20Mode%20presentations/DEF%20CON%20Safe%20Mode%20-%20Erik%20Hunstad%20-%20Domain%20Fronting%20is%20Dead%20Long%20Live%20Domain%20Fronting.pdf[4] https://docs.paloaltonetworks.com/pan-os/10-0/pan-os-admin/threat-prevention/enable-evasion-signatures.html[5] https://github.com/cobbr/Covenant
