亚洲日本免费-啊轻点灬太粗太长了三男一女-麻豆av电影在线观看-日韩一级片毛片|www.grbbt.com

前言

又是平靜的一天，吉良吉影只想過(guò)平靜的生活。

哦，對(duì)不起拿錯(cuò)劇本了。

重保期，RT 使用了多種方法來(lái)攻擊資產(chǎn)， 其中不乏低級(jí)的方法。

1. 給客服 MM 傳惡意文件，威脅不運(yùn)行就投訴的，偽造<五一放假通知>釣魚的。

2. 郵件內(nèi)嵌病毒的。（以至于筆者公司真發(fā)了一個(gè)放假通知郵件，一堆人問(wèn)是不是釣魚）

我司的放假通知郵件

3. 甚至還有跟我們分析人員聊天的。（RT：世界上無(wú)聊的人那么多，為何不能算我一個(gè)）

RT 與我司分析師小哥哥的聊天記錄

4. 當(dāng)然高級(jí)的手法也有很多，比如像我們之前發(fā)的文章《RT 又玩新套路，竟然這樣隱藏 C2》，使用云函數(shù)隱藏 IP 的，還有大范圍使前兩年出現(xiàn)的域前置攻擊的，甚至還有劫持微軟子域名偽造升級(jí)補(bǔ)丁的，?真是讓人眼花繚亂，防不勝防。我們也被 RT 的思路深深折服，大呼過(guò)癮。

本文將從防守方的視角來(lái)復(fù)現(xiàn)域前置攻擊的細(xì)節(jié)，其中涉及到某云的一個(gè)域前置驗(yàn)證漏洞，我們已在第一時(shí)間反饋給該云，在本文發(fā)布之前，該漏洞已經(jīng)修復(fù)。

What is?域前置

域前置（Domain fronting），是一種隱藏連接真實(shí)端點(diǎn)來(lái)規(guī)避互聯(lián)網(wǎng)審查的技術(shù)。在應(yīng)用層上運(yùn)作時(shí)，域前置使用戶能通過(guò) HTTPS 連接到被屏蔽的服務(wù)，而表面上像是在與另一個(gè)完全不同的站點(diǎn)通信。

簡(jiǎn)單理解：

表面看，頭部 CDN 通訊域名（我們看得到）；

實(shí)際內(nèi)部，尾部真實(shí) IP（我們看不到）。

哦，對(duì)不起，拿錯(cuò)圖了。應(yīng)該是下面這張：

很多同學(xué)曾發(fā)文說(shuō)，只有 HTTPS 才算是域前置，其原理是明文的 DNS 請(qǐng)求。

國(guó)外也有文章認(rèn)為，當(dāng)聽到域前置的時(shí)候，只需要認(rèn)為攻擊者將 HTTP Header 中的 Host 頭變換為位于 CDN 后面的高信譽(yù)網(wǎng)站即可。

圖片來(lái)源：https://malcomvetter.medium.com/simplifying-domain-fronting-8d23dcb694a0

因此，宏觀定義的域前置應(yīng)該也包含 80 端口的情況，即也包含 HTTP 和 HTTPS 兩種情況。

在真正的應(yīng)用場(chǎng)景中，HTTPS 在攻擊中只是多了一層 TLS 驗(yàn)證，所以本文主要復(fù)現(xiàn) HTTP 層的域前置攻擊。HTTPS 其實(shí)同理，只需要在 CS 配置中填寫 443 端口，以及在 CDN 廠商中設(shè)置增加證書和 443 端口即可。

就不要細(xì)摳到底屬不屬于域前置啦~

兩個(gè)云廠商的域前置可行性實(shí)踐

網(wǎng)上的東西都是虛擬的，把握不住，所以我們打算親身實(shí)踐一下。

只圖學(xué)東西，不圖掙 W。

我們以 A 和 B 兩個(gè)云廠商為實(shí)踐對(duì)象。

首先，來(lái)看看某 A 云的 CDN 機(jī)制。

我們先找了一個(gè)使用了 A 云 CDN 服務(wù)的域名，例子為：***gzhongshangcheng.com。

當(dāng)我們直接請(qǐng)求的時(shí)候，很明顯正常顯示了這個(gè)域名的內(nèi)容，標(biāo)題是大家樂(lè)游戲下載。如下圖所示：

然后，我們?cè)僬伊硪粋€(gè)使用了 A 云 CDN 服務(wù)的域名 g*oud.cn，同樣直接請(qǐng)求了該域名，且標(biāo)題為 301 跳轉(zhuǎn)。

好的，當(dāng)我們?nèi)匀徽?qǐng)求 g*oud.cn，但將 Header 頭中的 Host 字段更改為***gzhongshangcheng.com 域名，會(huì)怎么樣呢？

試了一下，發(fā)現(xiàn)返回的竟是 Host 字段中?***gzhongshangcheng.com 的內(nèi)容。

這便是可以使用 CDN 進(jìn)行域前置攻擊的原因了，當(dāng)我們請(qǐng)求一個(gè)部署了 CDN 服務(wù)的域名時(shí)，實(shí)際上也默認(rèn)使用了云廠商內(nèi)部的解析器。

而云廠商內(nèi)部的解析器，實(shí)際會(huì)根據(jù) Header 中的 Host 字段判斷回源域名（這個(gè)概念我后面會(huì)講），最后效果是，請(qǐng)求內(nèi)容以Host字段為準(zhǔn)。

這時(shí)候有讀者會(huì)問(wèn)了，當(dāng)我們請(qǐng)求域名的時(shí)候，實(shí)際也是 DNS 解析成 IP 呀。

如果我們直接請(qǐng)求 A 云 IP，然后改 Host 為?***gzhongshangcheng.com 呢？

Bingo！聰明的你一定也想到了，這樣做確實(shí)可以，是一樣的。如下圖所示：

A 云嘗試完了，我們來(lái)試試某 B 云呢？

先正常請(qǐng)求一個(gè)部署 B 云的 CDN 服務(wù)的域名。

返回是其后臺(tái)管理系統(tǒng)內(nèi)容，然后我們請(qǐng)求 CDN IP 并更改 Host 試一下，成功。

再試一下請(qǐng)求部署了 B 云 CDN 加速的域名，然后改 Host 呢？

也成功了。

經(jīng)過(guò)實(shí)踐發(fā)現(xiàn)，兩者的機(jī)制是一樣的，無(wú)論是請(qǐng)求 CDN 域名還是請(qǐng)求 CDN IP，只要更改 Host 為其他域名，最后返回內(nèi)容就是其他域名的內(nèi)容。

看到這里，各位應(yīng)該已經(jīng)知道了，只要我們的請(qǐng)求是 CDN 加速域名或 IP，云廠商就會(huì)根據(jù)我們的 Host 字段的域名進(jìn)行回源，并請(qǐng)求 Host 字段的域名返回內(nèi)容。

令人欣喜的是，在云廠商請(qǐng)求 Host 字段域名時(shí)，如果該域名在云廠商中使用了 CDN 加速服務(wù)，會(huì)使用內(nèi)部解析器解析成 IP 并請(qǐng)求。

也就是說(shuō)，假如在云廠商內(nèi)部解析器中域名解析 IP 與實(shí)際 IP 不符，那么通過(guò)這種方法就可以返回與實(shí)際頁(yè)面不同的內(nèi)容。

好一手偷天換日！

這也就是為什么攻擊者可以使用域前置使 Cobalt Strike（以下簡(jiǎn)稱 CS）上線的原因，同時(shí)也是本次重保中我們發(fā)現(xiàn)一堆 CS 馬請(qǐng)求一些高信譽(yù)域名（如 4399.com、douyu.com 等）的原因。

如何實(shí)現(xiàn)，試試便知

下面，我們親自動(dòng)手實(shí)現(xiàn)：

1. 申請(qǐng) A 云、B 云的高信譽(yù)加速域名
2. 部署域前置并驗(yàn)證上線
3. 抓包驗(yàn)證實(shí)時(shí)流量隱匿

怎么樣，是不是很簡(jiǎn)單呢？

云加速域名申請(qǐng)

A 云的驗(yàn)證機(jī)制基本沒(méi)有漏洞，新添加的加速域名需要 DNS 驗(yàn)證。

看起來(lái)是修復(fù)了繞過(guò)驗(yàn)證添加高信譽(yù)域名進(jìn)行加速的漏洞。

但是仍需要重視，部分攻擊者手上還有歷史上 A 云未修復(fù)時(shí)惡意添加的加速域名，例如本次重保我們掌握的 res.mall.100**.cn、goog**.com、app.sou***.com、zdhw2020***.43**.com 等。

可能有同學(xué)會(huì)問(wèn)筆者，什么是未驗(yàn)證添加 CDN 加速域名漏洞啊 ?

這里涉及到一個(gè)驗(yàn)證機(jī)制漏洞，雖然 A 云已經(jīng)修復(fù)了，但是想了解的同學(xué)可以看如下這篇文章 https://www.anquanke.com/post/id/195011，偷懶的同學(xué)直接看下圖就可以了。

所以為了驗(yàn)證 A 云的域前置，筆者請(qǐng)我司（微步在線）的運(yùn)維同學(xué)幫忙驗(yàn)證了一下。（運(yùn)維：公司域名就是給你干這個(gè)的？）

如圖所見，已經(jīng)添加好的域名。

注意設(shè)置好回源策略。（具體就不講了，莫做攻擊用途。）

B 云加速域名申請(qǐng)

B 云就沒(méi)那么幸運(yùn)了，在我們上報(bào)漏洞前，仍然存在繞過(guò)域名歸屬權(quán)，添加域名的漏洞。

實(shí)測(cè)限制條件有兩個(gè)：一個(gè)是域名未部署 CDN 服務(wù)（B 云應(yīng)該是根據(jù) cname 驗(yàn)證是否部署了 CDN 服務(wù)）；另一個(gè)是域名沒(méi)有被其他用戶添加過(guò)（還就那個(gè)先到先得）。

所以就造成，我其實(shí)可以添加這個(gè)域名作為加速域名（某 B：我把我域名給你交了)。

所以實(shí)測(cè)中發(fā)現(xiàn)一個(gè)有趣的現(xiàn)象，我們的域名已經(jīng)被其他人注冊(cè)添加了。

X 社區(qū)也沒(méi)能幸免（社區(qū)運(yùn)營(yíng)兄弟罵罵咧咧退出群聊）。

看了下友商的注冊(cè)情況：

看來(lái)有很多的坑已經(jīng)被別人占了，某深恐成最大贏家。

筆者沒(méi)辦法，只能添加了一個(gè)我們自己域名的三級(jí)域名（委屈）。

至此 B 云也添加成功了。

關(guān)于添加域名的繞過(guò)漏洞已經(jīng)上報(bào)該云廠商 SRC 了，如果不修復(fù)的話，預(yù)計(jì)下次重保可能什么牛鬼蛇神都出來(lái)了，又不好溯源，寶寶心里苦~~~~~

驗(yàn)證是否添加成功

首先，我們架設(shè)了一個(gè)自己的域名，訪問(wèn)之后會(huì)顯示 success?threatbook 字樣。如下圖所示：

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

我們?cè)L問(wèn) B 云的 CDN IP， 改 Host 為我們的域名，發(fā)現(xiàn)確實(shí)正常回顯了我們域名上的內(nèi)容。

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

驗(yàn)證可行。

CS?上線實(shí)踐及抓包

先使用 A 云上線，配置 CS 如下圖，HTTP Host 填一個(gè) A 云的 CDN IP 或者是 CDN 域名都可以。如下圖（筆者略去了具體配置圖片，以免有傳播攻擊方法嫌疑）：

使用虛擬機(jī)運(yùn)行木馬，抓取上線數(shù)據(jù)包。

可以看到，通訊 IP 已經(jīng)變成了 A 云的 CDN IP：122.156.134.***， 且 Host 為 test.threatbook.cn，已經(jīng)找不到我們?cè)忌暇€域名的痕跡了。

CS 正常上線：

正常回顯數(shù)據(jù)：

剛剛使用的是 A 云的 CDN IP，下面我們使用 A 云的 CDN 域名看一下能不能上線。

HTTP Host 中填寫一個(gè)使用了 A 云加速的 CDN 域名：

可以看到數(shù)據(jù)包通訊 IP 變成了：133.229.253.***。

而這個(gè) IP 正是我們使用的 CDN 域名 g*oud.cn 的解析 IP，如圖：

仍然正常上線了。

因此，正如我們之前所說(shuō)，無(wú)論是使用 CDN IP 改 Host 頭還是 CDN 域名改 Host，都可以實(shí)現(xiàn)域前置攻擊，只不過(guò)使用 CDN 域名時(shí)，通訊 IP 變成了該域名的解析 IP。

然后，我們使用 B 云進(jìn)行實(shí)踐，監(jiān)聽器填寫如下圖：

監(jiān)控（捕捉）到以下數(shù)據(jù)包：

1. Get 上線包

2. 傳輸主機(jī)信息 Post 包

3. 數(shù)據(jù)正常回顯頁(yè)面：

至此，通過(guò)兩家云廠商的 CDN 服務(wù)進(jìn)行域前置攻擊的復(fù)現(xiàn)全部完成。

總結(jié)

關(guān)于域前置攻擊，我們已經(jīng)掌握了部分情況的溯源方法，即使使用 CDN 來(lái)隱藏 IP，我們依然有辦法拿到真實(shí) IP（這個(gè)方法此篇文章暫不討論）。

其實(shí)所有的隱匿攻擊，概括起來(lái)都可以用下圖解釋：

域前置？轉(zhuǎn)發(fā)器換成 CDN；

云函數(shù)？轉(zhuǎn)發(fā)器換成云函數(shù)轉(zhuǎn)發(fā)；

代理隱藏？轉(zhuǎn)發(fā)器換成代理機(jī)；

網(wǎng)關(guān)隱藏？轉(zhuǎn)發(fā)器換成網(wǎng)關(guān)；

還有更多，就不一一列舉了。

甚至還有多層嵌套的，實(shí)際就是給轉(zhuǎn)發(fā)器這個(gè)小黑盒里面加?xùn)|西就好了。

實(shí)踐中提到的更多技術(shù)細(xì)節(jié)，在文中不便過(guò)多透露（以防被拿去做違法的事情）。

2021年重保結(jié)束了，回想起重保期間與攻擊方的種種博弈，其實(shí)更像是一年一度的約定和重逢。

攻擊方想出新的攻擊思路，我們（防守方）復(fù)現(xiàn)并研究應(yīng)對(duì)方法，我們找到防守方法，攻擊方又使用新的套路，可謂是道高一尺，魔高一丈。

很多時(shí)候，一些高級(jí)的攻擊手法也會(huì)令我們拍案叫絕。攻防出現(xiàn)新的思路，我們的分析師會(huì)幾個(gè)人聚在一起討論原理和新奇之處，去學(xué)習(xí)新的方法和套路。

這樣做的目的，只是希望無(wú)限近地去攀登那座高峰，一座我們都很難逾越的高峰。

后記

很多時(shí)候，我們既掌握不了一勞永逸的、完全自動(dòng)化防御的方法，也沒(méi)辦法做到百分百保證對(duì)每一個(gè) IP、每一個(gè)域名都可以完全溯源。

一次次的攻防對(duì)抗，拼的似乎并不完全是實(shí)力，還有比誰(shuí)的失誤比較多。

比如，防守方忘記了自己的暴露資產(chǎn)，被攻擊方利用。

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

但人的本質(zhì)就是人，是人就會(huì)有失誤。

攻防轉(zhuǎn)換間，防守方似乎悲觀地處于不利的一方（我們似乎一直在等待著一種完全無(wú)法防御和溯源的攻擊方法出現(xiàn)的那一天）。

盡管這樣，我們只能相信，怕什么真理無(wú)窮，進(jìn)一寸有進(jìn)一寸的歡喜。

無(wú)論是域前置攻擊，云函數(shù)轉(zhuǎn)發(fā)，還是網(wǎng)關(guān) API 轉(zhuǎn)發(fā)，CDN 隱匿（指單純的將自己的域名部署 CDN 服務(wù)隱匿 IP），亦或是帶外通道傳輸（DNS、ICMP、UDP 通道這種）。

我們只能一個(gè)一個(gè)積累、復(fù)現(xiàn)、總結(jié)，就如同做學(xué)術(shù)一樣。不復(fù)現(xiàn)，不做實(shí)驗(yàn)驗(yàn)證，只靠推測(cè)和 PPT，是沒(méi)有辦法掌握原理的，何談防御呢？

還是希望攻擊方能多爆出來(lái)一些攻擊手法和思路，我們?cè)倮^續(xù)跟進(jìn)，攻防雙方共同進(jìn)步。

謝謝你讀我的文章。

– END –

來(lái)源：安全客