一文搞明白 Domain Borrowing

Posted 2021-08-30 思源湖的鱼

目录

• 前言
• 一、概述
• • 1、理想目标
  • 2、历史研究
  • • （1）Domain Fronting
    • （2）Domain Hiding
  • 3、Domain Borrowing
• 二、原理
• • 1、HTTPS 在CDN上的流程
  • 2、抛弃DNS
  • 3、CDN
  • 4、获取HTTPS证书
  • • （1）通过漏洞获取证书
    • （2）利用CDN特性获取证书
  • 小结
• 三、应用
• • 1、Palo Alto防火墙简介
  • 2、攻击
• 四、其他
• • 1、对比
  • 2、防御
• 结语

前言

在Black Hat Asia 2021上，腾讯安全玄武实验室发表了《Domain Borrowing: 一种基于CDN的新型隐蔽通信方法》，利用CDN的一些特性隐藏C2通信流量

本文对Domain Borrowing进行一个学习

一、概述

1、理想目标

对攻击者来说，一个理想的C2通信流量需要满足以下几个条件：

• 拥有大量IP地址供C2 agent连接
• 使用高信誉的的域名和合法的HTTPS证书
• 即使HTTPS流量可以被解密，解密后的流量也应该与正常流量高度相似，特别是SNI==Host
• 通信协议不依赖于特殊协议标准
• 通信方式不在特殊地区受限制

2、历史研究

（1）Domain Fronting

Fifield David等研究人员在2015年提出的一种基于CDN的隐蔽通信方法，该方法至今仍被广泛应用于真实APT攻击和红蓝对抗中，详情参见一文搞明白域前置（Domain Fronting）技术

局限：

• SNI和Host不相等，企业的防守方可以部署HTTPS流量解密设备，并对比流量中的SNI和Host是否相等来检测
• 云厂商逐渐意识到了Domain Fronting的危害，目前Cloudflare、AWS CloudFront、Google Cloud CDN等厂商也都纷纷禁用了这种隐蔽通信方法

（2）Domain Hiding

Erik Hunstad在DEFCON28上提出的隐蔽通信方法，这种方法主要依赖于TLSv1.3和ESNI

局限：

• 原先只有Cloudflare CDN支持ESNI，现在Cloudflare也已经不支持Client Hello里同时出现SNI和ESNI
• 为了进行流量审查，很多企业甚至国家级防火墙会直接禁止使用ESNI通信

3、Domain Borrowing

按笔者理解，关键点是利用CDN的特性或者说漏洞和配置不当问题，获取他人合法的HTTPS证书，来隐藏自己的攻击流量，详细原理和应用见下。

二、原理

1、HTTPS 在CDN上的流程

网站admin先把自己的网站和private key以及证书上传到CDN，然后将CNAME记录给DNS：

用户访问过程如下：

2、抛弃DNS

在HTTPS CDN的工作流程中，DNS只是用于寻找CDN边缘节点，并不直接参与HTTPS通信

所以客户端可以直接抛弃DNS解析流程，或者使用另一个加速域名cdn.b.com做DNS解析, 然后使用cdn.a.com作为SNI/Host与CDN边缘节点通信

3、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上任意注册高信誉度域名的加速服务

4、获取HTTPS证书

以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连接来说这仍然是一个非法的证书

（1）通过漏洞获取证书

如果攻击者可以获取目标站点的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证书使用的是我们上传的该域名的合法证书

（2）利用CDN特性获取证书

首先考虑正确的证书分发流程：

• 当用户使用cdn.example.com作为SNI进行HTTPS请求时，CDN会从他的数据库中查找cdn.example.com的证书

• 查询逻辑类似 select certificate from db where domain_name = "cdn.example.com"

• 表中的第一行数据符合查询条件, *.example.com.crt 会被select出来，并返回给客户端

问题与利用：

• 攻击者在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证书

StackPath和CDN77都存在这个特性，所以我们可以借用用户上传到StackPath和CDN77上的通配符HTTPS证书，且StackPath和CDN77上有很多高信誉度的域名：

以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的合法通信流量

小结

归纳下就是这么几步：

• 在CDN上注册高信誉域名
• 获取有效的HTTPS证书：来自易受攻击网站的证书；来自其他CDN用户的通配符证书
• 将它们结合起来，隐藏C2流量以规避审查

三、应用

玄武实验室的github如下：

• https://github.com/Dliv3/DomainBorrowing
• https://github.com/cobbr/Covenant

此外，还展示了一个案例：绕过Palo Alto防火墙

1、Palo Alto防火墙简介

Palo Alto Firewall PAN-VM是Palo Alto的下一代防火墙产品，支持很多优秀的特性，比如SSLv3.0-TLSv1.3的流量解密和Anti-Spyware功能。对SSL解密功能支持的算法如下图所示：

Anti-Spyware功能内置了各类恶意软件通信流量的检测规则和一些通用的检测逻辑比如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的

2、攻击

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的检测

四、其他

1、对比

2、防御

对于企业防守方来说，最简单有效的Domain Borrowing防御方法：

• 在防火墙检测HTTPS SNI的DNS解析结果是否与通信的目标IP地址相同, 并且建议配合DNS Proxy一起使用以减少误报

对于CDN厂商来说，可以采取以下方法禁用Domain Borrowing：

• 用户在CDN上注册加速域名时，严格校验域名归属权
• 客户端连接CDN时，正确地分发HTTPS证书

对于网站管理员来说，可以通过下列方式缓解网站证书被滥用的问题：

• 被入侵之后吊销现有证书，防止证书被攻击者窃取和滥用
• 通过证书透明度检查攻击者是否申请了该网站域名的新的证书

结语

学习了Domain Borrowing，利用CDN特性隐藏C2流量

参考：

• Domain Borrowing: 一种基于CDN的新型隐蔽通信方法
• Domain Borrowing: Catch My C2 Traffic if You Can
• Black Hat Asia ppt
• https://github.com/Dliv3/DomainBorrowing
• https://github.com/cobbr/Covenant