模拟攻击者利用“域前置”(Domain Fronting)技术逃避审查(重定向、CDN)
前情提要
今年3月份,FireEye公司曾發表過一篇報道:《APT29 Domain Fronting with TOR》,里邊描述了一種攻擊者經常使用的逃避審查機制的技術 Domain Fronting。本文重點介紹一下“域前置”(Domain Fronting,也被意譯為“域名幌子”)技術的基本原理和適用場景,國內在這方面的資料不多,拋磚引玉,歡迎大家交流討論。
“域前置”技術的工作原理
“域前置”技術是一種審查規避技術,主要用于隱蔽通信中的遠程端點。“域前置”發生在應用層,主要適用了HTTPS協議進行通信,通信中的遠程端點原本是被禁止的,通過使用“域前置”技術,讓檢測器誤認為是一個其他的合法地址,進而繞過檢測。核心思想是在不同的通信層使用了不一樣的域名。在一個HTTPS請求中,通信外層使用了一個域名:DNS請求和TLS SNI (Server Name Indication);而在通信內層,則使用了另一個域名:HTTP Host Header,這個域名由于在HTTPS加密之下,所以對檢測器而言是不可見的。如下圖所示:
圖1:域前置在通信的不同層使用了不同的域名:對于檢測器可見的明文層(DNS請求和TLS SNI)中使用了一個被允許的域名(allowed.example);對于檢測器不可見的HTTP層,使用了一個真實的、隱蔽的域名(forbidden.example)。
對于檢測器而言,很難在通信流量中判斷一個域名是否使用了“域前置/域名幌子”,要么放行、要么完全禁止,只能二選一,這就導致了昂貴的附帶損害。域前置技術易于部署和使用,并不需要特殊的網絡中介。研究人員發現,域前置技術在CDN等重要的基礎設施和Google的各類網絡服務中尤其適用。
“ Cobalt Strike + Google host”
接下來,重點解釋一下如何使用 Cobalt Strike 實施基于 Google hosts (如 google.com, mail.google.com 等)的“域前置” 攻擊。攻擊者早在幾年前就開始利用 google.com 實施“域前置” 攻擊,利用高信譽的網站將通信中的遠程終端隱蔽化,這對于攻擊者而言很有價值,因為它能夠高效的破壞現有的網絡分析能力。
盡管有辦法對域前置采集指紋,但是終端的惡意軟件在通信時會使用一些高信譽的域名(例如https://www.google.com)與C2服務器進行通信。
根據我們的了解,目前針對域前置的最常見的檢測方法是在配置一個中間人HTTPS 代理,通常被稱為 “SSL Termination”,它的作用是解密和檢測通信中所有的加密流量。當然了這種方法也存在一定的風險。此外,Google的域名支持 HSTS 協議,只有個別幾個廠商才有能力針對目標為Google 域名進行SSL通信的解密。(有關HSTS協議的含義,請查閱文末的「名詞解釋」)。最常用的Google產品(包括但不限于)的域名信息如下:
圖2:常用的Google域名信息
添加 Cobalt Strike 監聽器
我們假定使用 Cobalt strike 作為一個C2 服務器,當然了也可以使用其他的攻擊平臺(如 Metasploit, Empire, Pupy 等)。
首先,我們需要添加一個 Cobalt Strike 監聽器
-
為監聽器選擇 “windows/beacon_https/reverse_https” 有效載荷;
-
設置Host 值;
-
設置端口號;
圖3: 配置一個 Cobalt Strike 監聽器
設置Google域名地址為用于任務中的前置地址:
圖4:設置前置域名的信息
部署 GAE
Google 應用程序引擎(Google App Engine,GAE)是一個云平臺,允許用戶構建和部署自制的Web 和 移動應用程序,它相當于一個介于應用程序和云基礎設施之間的抽象層。
我們將使用 GAE 作為C2服務器和受害者主機之前的轉向器,使用 Google 前置域名重定向發往 google.com 域名的請求,這一過程的示意圖如下所示:
圖5:利用 GAE 作為攻擊中的轉向器
接下來,需要將一些代碼部署到 GAE中(注冊地址:https://cloud.google.com/appengine/)。創建了一個項目,然后新建一個目錄來存儲改項目。
$. mkdir myproject
$. cd myproject
這時候,App引擎目錄下會包含兩個文件:app.yaml 和 main.py。其中,App.yaml文件的信息如下所示:
圖6:App.yaml文件代碼信息
Main.py的代碼如下所示:
圖7:Main.py文件代碼(https://gist.github.com/redteam-cyberark/90fe4a3bc0caa582fc563ec503e5444c)
其中,有幾點內容需要重點解釋一下。
首先,頂部的一個變量可以用于設置你的CobaltStrike IP 地址或域名,這個CobaltStrike IP 地址對終端分析器而言是隱藏的。
圖8:設置CobaltStrike IP 地址或域名
需要指出的是,可以在 Cobaltstrike 和 Google App之間添加第二個轉向器,但是它的設置更為復雜,對攻擊者而言并沒有什么實用價值,只有Google 員工才能查看從 GAE到 C2之間的流量。
Main.py文件末尾的APP路由信息比較容易理解。
任何發往 APPSpot 域名的保護 URI的請求都會被發送到 CobaltStrike,在流量過濾(比如基于User-Agent, originating IP, or URI)方面不太理想,這些對于防御方而言都是阻礙。
最后一點需要指出的是應用程序處理請求的方式。包括 GET 和 POST兩類,詳情參見圖7(Main.py文件代碼)中間的部分。
這部分代碼實現的功能,包括確保發送到appspot應用程序的請求都被轉發到 CobaltStrike 實例上,還確保請求中的 HTTP header 信息和 POST 請求的 body信息都被轉發。這使得應用程序具有足夠的通用性,可以適用于不同配置的 C2 服務器。
部署的代碼:
$. gcloud app deploy
驗證重定向
在部署完代碼并設置好監聽器之后,可以通過運行一個快速測試來驗證是否能夠正常工作。
在 CobaltStrike 上打開Web Log (View > Web Log),向 GAE app 發送一個 eURL 請求,代碼示例如下:
$. curl -i –H “Host: [appname].appengine.com” –user-agent “Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0)” https://mail.google.com/hi_there
…
驗證上述請求是否顯示在 Web View 日志中,正常的話,您應該會收到一個 200 OK 的空返回,CobaltStrike 上有一個 404 錯誤。
圖9:驗證重定向測試中CobaltStrike上收到的信息
至此,表明重定向的工作可以正常執行了。
更新 C2 的配置文件
最后一步是設置 C2 服務器的配置文件。這里我們提供了一個簡單的例子:
圖10、圖11: C2配置文件的示例(https://github.com/redteam-cyberark/Google-Domain-fronting/blob/master/webbug_getonly_GAE.profile)
這里,有幾個關鍵問題值得特別關注一下:
-
在上圖中標紅的部分(header )那一行中,修改“Host”為你自己的appspot 域名;
-
不需要在配置中添加任何證書信息,應用程序的通信使用Google的HTTPS證書,應用程序到C2之間的HTTPS通信將被代理;
-
元數據 http-get部分和 http-post client/server的輸出部分被轉化成了url編碼,雖然不確定這樣做是否是必須的。Netbios最好也使用適當的編碼。
重啟CobaltStrike使新配置生效。
從現在開始,你可以嘗試拿 www.google.com, mail.google.com 或 docs.google.com 這些域名做幌子了。
【更多資料】
域前置技術并不是一個新型的技術,本文的編寫也是建立在其他人辛勤工作的基礎上,對此感興趣的可以閱讀以下文獻:
https://www.bamsoftware.com/papers/fronting/
https://blog.cobaltstrike.com/2017/02/06/high-reputation-redirectors-and-domain-fronting/
https://www.securityartwork.es/2017/01/24/camouflage-at-encryption-layer-domain-fronting/
https://www.securityartwork.es/2017/01/24/camouflage-at-encryption-layer-domain-fronting/
https://www.securityartwork.es/2017/01/31/simple-domain-fronting-poc-with-gae-c2-server/
【名詞解釋】
*資料來自網絡
HSTS代表HTTP Strict Transport Security ,是國際互聯網工程組織IETE正在推行一種新的Web安全協議,它是一種幫助網站將用戶從不安全的HTTP版本重定向到安全的HTTPS版本的機制。如果你訪問的網站啟用了HSTS,那么瀏覽器將會記住這一標記,確保未來每次訪問該網站都會自動定向到HTTPS,不會在無意中訪問不安全的HTTP。
HSTS可以很大程度上解決SSL剝離攻擊,因為只要瀏覽器曾經與服務器創建過一次安全連接,之后瀏覽器會強制使用HTTPS,即使鏈接被換成了HTTP。
另外,如果中間人使用自己的自簽名證書來進行攻擊,瀏覽器會給出警告,但是許多用戶會忽略警告。HSTS解決了這一問題,一旦服務器發送了HSTS字段,用戶將不再允許忽略警告。
總結
以上是生活随笔為你收集整理的模拟攻击者利用“域前置”(Domain Fronting)技术逃避审查(重定向、CDN)的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 接口文档下的渗透测试(Swagger)
- 下一篇: 洛谷 P1417 烹调方案