域前置水太深，偷學六娃來隱身——域前置攻擊復現
責編：gltian ｜2021-06-22 11:31:20前言
又是平靜的一天，吉良吉影只想過平靜的生活。
哦，對不起拿錯劇本了。
重保期，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 等）的原因。
如何實現，試試便知
下面，我們親自動手實現：
- 申請 A 云、B 云的高信譽加速域名
- 部署域前置并驗證上線
- 抓包驗證實時流量隱匿
怎么樣，是不是很簡單呢？
云加速域名申請
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 –
來源：安全客