域前置水太深，偷学六娃来隐身——域前置攻击复现

前言

又是平静的一天，吉良吉影只想过平静的生活。

哦，对不起拿错剧本了。

重保期，RT 使用了多种方法来攻击资产， 其中不乏低级的方法。

1. 给客服 MM 传恶意文件，威胁不运行就投诉的，伪造<五一放假通知>钓鱼的。

2. 邮件内嵌病毒的。（以至于笔者公司真发了一个放假通知邮件，一堆人问是不是钓鱼）

我司的放假通知邮件

3. 甚至还有跟我们分析人员聊天的。（RT：世界上无聊的人那么多，为何不能算我一个）

RT 与我司分析师小哥哥的聊天记录

4. 当然高级的手法也有很多，比如像我们之前发的文章《RT 又玩新套路，竟然这样隐藏 C2》，使用云函数隐藏 IP 的，还有大范围使前两年出现的域前置攻击的，甚至还有劫持微软子域名伪造升级补丁的， 真是让人眼花缭乱，防不胜防。我们也被 RT 的思路深深折服，大呼过瘾。

本文将从防守方的视角来复现域前置攻击的细节，其中涉及到某云的一个域前置验证漏洞，我们已在第一时间反馈给该云，在本文发布之前，该漏洞已经修复。

What is 域前置

域前置（Domain fronting），是一种隐藏连接真实端点来规避互联网审查的技术。在应用层上运作时，域前置使用户能通过 HTTPS 连接到被屏蔽的服务，而表面上像是在与另一个完全不同的站点通信。

简单理解：

表面看，头部 CDN 通讯域名（我们看得到）；

实际内部，尾部真实 IP（我们看不到）。

哦，对不起，拿错图了。应该是下面这张：

很多同学曾发文说，只有 HTTPS 才算是域前置，其原理是明文的 DNS 请求。

国外也有文章认为，当听到域前置的时候，只需要认为攻击者将 HTTP Header 中的 Host 头变换为位于 CDN 后面的高信誉网站即可。

图片来源：https://malcomvetter.medium.com/simplifying-domain-fronting-8d23dcb694a0

因此，宏观定义的域前置应该也包含 80 端口的情况，即也包含 HTTP 和 HTTPS 两种情况。

在真正的应用场景中，HTTPS 在攻击中只是多了一层 TLS 验证，所以本文主要复现 HTTP 层的域前置攻击。HTTPS 其实同理，只需要在 CS 配置中填写 443 端口，以及在 CDN 厂商中设置增加证书和 443 端口即可。

就不要细抠到底属不属于域前置啦~

两个云厂商的域前置可行性实践

网上的东西都是虚拟的，把握不住，所以我们打算亲身实践一下。

只图学东西，不图挣 W。

我们以 A 和 B 两个云厂商为实践对象。

首先，来看看某 A 云的 CDN 机制。

我们先找了一个使用了 A 云 CDN 服务的域名，例子为：***gzhongshangcheng.com。

当我们直接请求的时候，很明显正常显示了这个域名的内容，标题是大家乐游戏下载。如下图所示：

然后，我们再找另一个使用了 A 云 CDN 服务的域名 g*oud.cn，同样直接请求了该域名，且标题为 301 跳转。

好的，当我们仍然请求 g*oud.cn，但将 Header 头中的 Host 字段更改为***gzhongshangcheng.com 域名，会怎么样呢？

试了一下，发现返回的竟是 Host 字段中 ***gzhongshangcheng.com 的内容。

这便是可以使用 CDN 进行域前置攻击的原因了，当我们请求一个部署了 CDN 服务的域名时，实际上也默认使用了云厂商内部的解析器。

而云厂商内部的解析器，实际会根据 Header 中的 Host 字段判断回源域名（这个概念我后面会讲），最后效果是，请求内容以Host字段为准。

这时候有读者会问了，当我们请求域名的时候，实际也是 DNS 解析成 IP 呀。

如果我们直接请求 A 云 IP，然后改 Host 为 ***gzhongshangcheng.com 呢？

Bingo！聪明的你一定也想到了，这样做确实可以，是一样的。如下图所示：

A 云尝试完了，我们来试试某 B 云呢？

先正常请求一个部署 B 云的 CDN 服务的域名。

返回是其后台管理系统内容，然后我们请求 CDN IP 并更改 Host 试一下，成功。

再试一下请求部署了 B 云 CDN 加速的域名，然后改 Host 呢？

也成功了。

经过实践发现，两者的机制是一样的，无论是请求 CDN 域名还是请求 CDN IP，只要更改 Host 为其他域名，最后返回内容就是其他域名的内容。

看到这里，各位应该已经知道了，只要我们的请求是 CDN 加速域名或 IP，云厂商就会根据我们的 Host 字段的域名进行回源，并请求 Host 字段的域名返回内容。

令人欣喜的是，在云厂商请求 Host 字段域名时，如果该域名在云厂商中使用了 CDN 加速服务，会使用内部解析器解析成 IP 并请求。

也就是说，假如在云厂商内部解析器中域名解析 IP 与实际 IP 不符，那么通过这种方法就可以返回与实际页面不同的内容。

好一手偷天换日！

这也就是为什么攻击者可以使用域前置使 Cobalt Strike（以下简称 CS）上线的原因，同时也是本次重保中我们发现一堆 CS 马请求一些高信誉域名（如 4399.com、douyu.com 等）的原因。

如何实现，试试便知

下面，我们亲自动手实现：

1. 申请 A 云、B 云的高信誉加速域名
2. 部署域前置并验证上线
3. 抓包验证实时流量隐匿

怎么样，是不是很简单呢？

云加速域名申请

A 云的验证机制基本没有漏洞，新添加的加速域名需要 DNS 验证。

看起来是修复了绕过验证添加高信誉域名进行加速的漏洞。

但是仍需要重视，部分攻击者手上还有历史上 A 云未修复时恶意添加的加速域名，例如本次重保我们掌握的 res.mall.100**.cn、goog**.com、app.sou***.com、zdhw2020***.43**.com 等。

可能有同学会问笔者，什么是未验证添加 CDN 加速域名漏洞啊 ?

这里涉及到一个验证机制漏洞，虽然 A 云已经修复了，但是想了解的同学可以看如下这篇文章 https://www.anquanke.com/post/id/195011，偷懒的同学直接看下图就可以了。

所以为了验证 A 云的域前置，笔者请我司（微步在线）的运维同学帮忙验证了一下。（运维：公司域名就是给你干这个的？）

如图所见，已经添加好的域名。

注意设置好回源策略。（具体就不讲了，莫做攻击用途。）

B 云加速域名申请

B 云就没那么幸运了，在我们上报漏洞前，仍然存在绕过域名归属权，添加域名的漏洞。

实测限制条件有两个：一个是域名未部署 CDN 服务（B 云应该是根据 cname 验证是否部署了 CDN 服务）；另一个是域名没有被其他用户添加过（还就那个先到先得）。

所以就造成，我其实可以添加这个域名作为加速域名（某 B：我把我域名给你交了)。

所以实测中发现一个有趣的现象，我们的域名已经被其他人注册添加了。

X 社区也没能幸免（社区运营兄弟骂骂咧咧退出群聊）。

看了下友商的注册情况：

看来有很多的坑已经被别人占了，某深恐成最大赢家。

笔者没办法，只能添加了一个我们自己域名的三级域名（委屈）。

至此 B 云也添加成功了。

关于添加域名的绕过漏洞已经上报该云厂商 SRC 了，如果不修复的话，预计下次重保可能什么牛鬼蛇神都出来了，又不好溯源，宝宝心里苦~~~~~

验证是否添加成功

首先，我们架设了一个自己的域名，访问之后会显示 success threatbook 字样。如下图所示：

然后 B 云加速域名的源站地址填入我们自己的域名。

我们访问 B 云的 CDN IP， 改 Host 为我们的域名，发现确实正常回显了我们域名上的内容。

然后在 A 云添加我们的域名，

验证可行。

CS 上线实践及抓包

先使用 A 云上线，配置 CS 如下图，HTTP Host 填一个 A 云的 CDN IP 或者是 CDN 域名都可以。如下图（笔者略去了具体配置图片，以免有传播攻击方法嫌疑）：

使用虚拟机运行木马，抓取上线数据包。

可以看到，通讯 IP 已经变成了 A 云的 CDN IP：122.156.134.***， 且 Host 为 test.threatbook.cn，已经找不到我们原始上线域名的痕迹了。

CS 正常上线：

正常回显数据：

刚刚使用的是 A 云的 CDN IP，下面我们使用 A 云的 CDN 域名看一下能不能上线。

HTTP Host 中填写一个使用了 A 云加速的 CDN 域名：

可以看到数据包通讯 IP 变成了：133.229.253.***。

而这个 IP 正是我们使用的 CDN 域名 g*oud.cn 的解析 IP，如图：

仍然正常上线了。

因此，正如我们之前所说，无论是使用 CDN IP 改 Host 头还是 CDN 域名改 Host，都可以实现域前置攻击，只不过使用 CDN 域名时，通讯 IP 变成了该域名的解析 IP。

然后，我们使用 B 云进行实践，监听器填写如下图：

监控（捕捉）到以下数据包：

1. Get 上线包

2. 传输主机信息 Post 包

3. 数据正常回显页面：

至此，通过两家云厂商的 CDN 服务进行域前置攻击的复现全部完成。

总结

关于域前置攻击，我们已经掌握了部分情况的溯源方法，即使使用 CDN 来隐藏 IP，我们依然有办法拿到真实 IP（这个方法此篇文章暂不讨论）。

其实所有的隐匿攻击，概括起来都可以用下图解释：

域前置？转发器换成 CDN；

云函数？转发器换成云函数转发；

代理隐藏？转发器换成代理机；

网关隐藏？转发器换成网关；

还有更多，就不一一列举了。

甚至还有多层嵌套的，实际就是给转发器这个小黑盒里面加东西就好了。

实践中提到的更多技术细节，在文中不便过多透露（以防被拿去做违法的事情）。

2021年重保结束了，回想起重保期间与攻击方的种种博弈，其实更像是一年一度的约定和重逢。

攻击方想出新的攻击思路，我们（防守方）复现并研究应对方法，我们找到防守方法，攻击方又使用新的套路，可谓是道高一尺，魔高一丈。

很多时候，一些高级的攻击手法也会令我们拍案叫绝。攻防出现新的思路，我们的分析师会几个人聚在一起讨论原理和新奇之处，去学习新的方法和套路。

这样做的目的，只是希望无限近地去攀登那座高峰，一座我们都很难逾越的高峰。

后记

很多时候，我们既掌握不了一劳永逸的、完全自动化防御的方法，也没办法做到百分百保证对每一个 IP、每一个域名都可以完全溯源。

一次次的攻防对抗，拼的似乎并不完全是实力，还有比谁的失误比较多。

比如，防守方忘记了自己的暴露资产，被攻击方利用。

比如，攻击方忘记清除自己的 Cookie，被蜜罐抓到 ID。

但人的本质就是人，是人就会有失误。

攻防转换间，防守方似乎悲观地处于不利的一方（我们似乎一直在等待着一种完全无法防御和溯源的攻击方法出现的那一天）。

尽管这样，我们只能相信，怕什么真理无穷，进一寸有进一寸的欢喜。

无论是域前置攻击，云函数转发，还是网关 API 转发，CDN 隐匿（指单纯的将自己的域名部署 CDN 服务隐匿 IP），亦或是带外通道传输（DNS、ICMP、UDP 通道这种）。

我们只能一个一个积累、复现、总结，就如同做学术一样。不复现，不做实验验证，只靠推测和 PPT，是没有办法掌握原理的，何谈防御呢？

还是希望攻击方能多爆出来一些攻击手法和思路，我们再继续跟进，攻防双方共同进步。

谢谢你读我的文章。

– END –

来源：安全客