Domain Fronting --在CDN加速中的域前置

域前置（DomainFronting）的设计初衷是逃避网络审查，但因其良好的网络穿透性，很适合应用于APT/malware远控中，用来隐藏metasploit、cobalt strike等团队控制服务器流量，以此来一定程度上绕过检查器或防火墙检测的技术，一些大型厂商会提供域前端技术服务（Google后于2018年4月禁用域前置；亚马逊公司也在不久后决定停用CloudFront上的域前置支持。在其他博文看的，不知道对不对，毕竟我都不能注册）。他是基于https的通用规避技术。

我们可以先看到我们的网络请求：

• 用户在浏览器中输入一个包含主机名的URL

• 操作系统对主机名进行DNS查询

• 查到ip后，在两台主机之间建立连接

最基本的HTTP/1.1请求如下：

GET /HTTP/1.1

Host:phelaine.xyz

正常情况下，URL中的主机名，应该与主机头中的主机名相匹配，但是并没有任何措施来避免不是这样。我们可以用curl来做一个演示：curl -v -H "Host: phelaine.xyz" https://www.baidu.com

我们将与baidu.com建立网络连接，但是通过主机头，最终会请求phelaine.xyz这个网站，但是baidu并不知道phelaine.xyz的虚拟主机，因此我们会得到一个报错。

图中连接建立过程解释：

连接百度的443端口。

握手环节：

• 客户端发出client_hello消息。发出建立https的请求

• 服务器端发出server_hello消息、服务器端发出certificate消息、服务器端发出server_key_exchange消息、服务器端发出server_done消息。

• 客户端发出client_key_exchange消息。客户端发出加密后的client_hello消息。客户端发出client_done消息。

握手结束。

SSL连接采用ECDHE-RSA-AES128-GCM-SHA256密码套件。

ECDHE表示密钥交换方法采用椭圆曲线迪菲-赫尔曼交换方法；RSA表示密钥交换中使用的签名方式。AES-256-GCM表示的是对称加密算法；SHA-256表示的是内容完整性校验使用的哈希算法。

下面是关于证书的内容，包括有效时间、常用名、证书签发机构等。

常用名是baidu.com，域名和证书的域名相匹配。签发者是GlobalSign

可以看到一旦tcp连接建立成功，TLS就开始协商，并且全都是基于发起连接的主机名，没有警告，因为证书有效，在HTTP请求中发送主机头之前没有涉及到phelaine，主机头是在应用层的流量中，在所有底层连接建立之前不会查看（SSL/TLS属于运输层协议）。

好了，了解了基础知识，我们可以想象一个场景，当我们攻入对方系统，想要其回连到我们本地，但是对方系统应用对出站规则把握得很严格，例如仅仅允许tcp 80及443通过代理离开网络，而且还会有许多设备在应用层来检查这个流量，如果检测到恶意的payload，则进行拦截并报警。绕过这些解决方案，这时候可以采用我们的domain fronting来绕过。

很多博文都以amazon的cloudfront作为CDN的利用演示，而我没有信用卡，注册不了，更别说用他们的服务了。但是我这儿就口头演示一下。

首先，注册后，建立一个cloudfront，将我们自己控制的服务器域名（如：phelaine.xyz）写入origin domain name，配置好参数，使其生成一个能访问到我们真实服务器的缓存节点。如：d289wv3b5uz3me.cloudfront.net，访问这个域名可以解析到phelaine.xyz的IP。

接下来，我们需要选择一个该目标应用能访问高信誉的白名单域名且同样使用cloudfront服务域名，充当我们前置域名。如：https://docs.telemetry.mozilla.org，规则如下：

docs.telemetry.mozilla.org31 CNAME d289wv3b5uz3me.cloudfront.net

d289wv3b5uz3me.cloudfront.net 31 A 233.23.23.23

前置域名因为使用了合法的前置域名做诱饵，在使用https链接时，DNS请求的也都是合法域名，而在host中修改请求指向为我们控制的服务器，相当于请求合法域名之后，将流量转发到了中转web上。

此时，利用docs.telemetry.mozilla.org白名单域名来隐藏真实的恶意流量（若我们服务器下面有一个test.txt）：

curl-v -H "Host: d289wv3b5uz3me.cloudfront.net" docs.telemetry.mozilla.org/test.txt

在实际应用中，（没有实践，但还是做个记录）如使用cobaltstrike，修改其配置文件来控制流量传输，修改cobalt strike中的profile：./c2link Malleable-C2-profiles/normal/webbug.profile，修改header中的Host指定我们的节点，注意http-get、http-post里面的都要改，比如这儿我们改为header "Host","d289wv3b5uz3me.cloudfront.net"

启动cobalt strike的服务端，./teamserver [ip] [修改的profile文件地址]

启动客户端，创建beacon监听，host中填入cdn分发的域名，生成powershell命令，对方运行后监听上线。用wireshark查看流量发现并没有我们的真实域名而只有节点地址，而解析的DNS地址是高信誉域名的地址。

现在，我们可以来总结一下这个技术的原理，它在于在不同通信层使用不同的域名。

在明文的DNS请求和TLS服务器名称指示（SNI）中使用无害的域名来初始化连接、公布给审查者，而实际要连接的被封锁域名仅在创建加密的HTTPS连接后发出，使其不以明文暴露给网络审查者，在Host头中携带了另一个恶意域名。

此技术利用审查者通常很难区分被伪装流量与合法流量的特点，迫使审查者选择放行所有看似无害的流量，或者选择彻底封锁此域的流量。而彻底封锁可能带来显著的附加损害。