Domain Borrowing: 一种基于 CDN 的新型隐蔽通信方法（全程干货！）
0x00 背景简介
CDN(Content Delivery Network) 是云服务厂商提供的一种 Web 内容加速分发服务。
对于攻击者来说，CDN 提供了大量分布于全球各地的边缘节点 IP，并且可以将源服务器隐藏在 CDN 节点之后，所以 CDN 非常适合被用于保护 C2 的通信。
本文介绍了我们在某些 CDN 实现中发现的一些特性，以及如何利用这些特性隐藏 C2 通信流量，我们将这种新型的基于 CDN 的隐蔽通信方法称为 Domain Borrowing。
该研究已经发表在 Black Hat Asia 2021。
0x01 历史研究
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 通信。
0x02 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 的合法通信流量。
0x03 防御方法
对于企业防守方来说，最简单有效的 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。
0x05 Covenant Implant Template
我们实现了一个使用 Domain Borrowing 通信的 Covenant[5] Implant Template，希望帮助攻击方在红蓝对抗中应用 Domain Borrowing 技术，也希望能够帮助防守方加强对此类通信流量的检测能力。
Github Repo: https://github.com/Dliv3/DomainBorrowing
0x06 参考资料
[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
最后在多说几句：我是一名网络安全工程师，也是刚开始做自媒体
为了感谢读者们，我想把我收藏的一些网络安全/渗透测试学习干货贡献给大家，回馈每一个读者，希望能帮到你们。
干货主要有：
① 2000 多本网安必看电子书（主流和经典的书籍应该都有了）
② PHP 标准库资料（最全中文版）
③ 项目源码（四五十个有趣且经典的练手项目及源码）
④ 网络安全基础入门、Linux 运维，web 安全、渗透测试方面的视频（适合小白学习）
⑤ 网络安全学习路线图（告别不入流的学习）
各位朋友们可以关注+评论一波 然后私信 备注：网安学习 即可免费获取
还未添加个人签名 2021.03.28 加入
需要获取网络安全/渗透测试学习资料工具的朋友可联系V：machinegunjoe666 免费索取
评论