一、引言

近年來，云計(jì)算的模式逐漸被業(yè)界認(rèn)可和接受。越多來多的企業(yè)將其業(yè)務(wù)遷移上云，業(yè)務(wù)上云的模式多種多樣，包括公有云、私有云、混合云和社區(qū)云。其中公有云以其低成本、靈活性等優(yōu)勢備受中小企業(yè)的青睞。企業(yè)只需承擔(dān)一定的費(fèi)用，專注于自身業(yè)務(wù)，將底層設(shè)施的安裝和維護(hù)工作交給云服務(wù)提供商即可。但如今網(wǎng)絡(luò)安全形勢嚴(yán)峻，業(yè)務(wù)的安全性也是企業(yè)必須考慮的重點(diǎn)。

那么公有云的安全性如何？站在攻擊方的角度，參考《云上攻防：Red Teaming for Cloud》[1]的思路，公有云環(huán)境面臨的威脅主要分為兩大類：

• 利用公有云上租戶的不安全的應(yīng)用和服務(wù)配置為突破口
• 利用公有云本身的服務(wù)的自身問題為突破口

本文主要探討第二種——以云廠商提供的云服務(wù)為突破口，最終導(dǎo)致公有云環(huán)境淪陷的攻擊技術(shù)。技術(shù)本身可能受限于平臺和環(huán)境，但其中的思路和技巧值得借鑒和思考。希望讀者在了解相關(guān)攻擊技術(shù)之后能意識到：公有云安全需要云服務(wù)提供商和云上租戶共同維護(hù)，缺一不可。

文中涉及到的技術(shù)僅供教學(xué)、研究使用，禁止用于非法用途。

二、背景

公有云廠商提供的云服務(wù)種類較多，涵蓋計(jì)算、容器、數(shù)據(jù)庫、存儲、無服務(wù)器等類別，不同的云廠商提供的云服務(wù)也不盡相同。值得注意的是，其中一些云服務(wù)可能是將傳統(tǒng)產(chǎn)品云化之后提供給客戶使用，如數(shù)據(jù)庫類的產(chǎn)品，雖然最終對用戶提供的服務(wù)大致相同，但不同的云廠商可能會為了適配云環(huán)境對產(chǎn)品做二次修改，這對用戶來說是難以察覺的，然而卻可能成為攻擊者的突破口。接下來將通過一些案例來具體說明不同云廠商的云服務(wù)存在的真實(shí)風(fēng)險（文中提及的風(fēng)險皆已公開且已修復(fù)）。

三、案例研究

3.1 案例1——Google Cloud云服務(wù)漏洞

Google Cloud SQL是一個全代管式的關(guān)系型數(shù)據(jù)庫服務(wù)，用戶無需自行管理，即可部署一個SQL Server、PostgreSQL或MySQL服務(wù)器。這些Cloud SQL數(shù)據(jù)庫可以通過特定的命令行工具或應(yīng)用程序進(jìn)行訪問。云廠商為了保證公有云環(huán)境中多租戶的隔離安全，會對用戶權(quán)限和應(yīng)用程序權(quán)限進(jìn)行限制，以防止出現(xiàn)不受控制的隔離風(fēng)險。但權(quán)限控制并非一項(xiàng)簡單的工作，一些研究員已經(jīng)在Google Cloud中的MySQL、PostgreSQL和Google Guest Agent中發(fā)現(xiàn)了相關(guān)漏洞，可以用來進(jìn)行命令執(zhí)行和容器逃逸，從而威脅其他租戶的云環(huán)境。下面將分別簡單介紹漏洞利用鏈。

CloudMySQL命令執(zhí)行+容器逃逸

該漏洞由研究員Ezequiel Pereira發(fā)現(xiàn)[2]。在MySQL中，SUPER權(quán)限用于系統(tǒng)管理的相關(guān)任務(wù)，F(xiàn)ILE權(quán)限用于在運(yùn)行MySQL守護(hù)進(jìn)程的服務(wù)器上進(jìn)行文件讀寫。一旦擁有這些權(quán)限，便可輕易對服務(wù)器造成破壞，因此正常情況下只享受數(shù)據(jù)庫服務(wù)的用戶不應(yīng)被賦予上述權(quán)限。研究員在Google Cloud控制臺界面管理MySQL實(shí)例時發(fā)現(xiàn)了從存儲桶導(dǎo)入和導(dǎo)出數(shù)據(jù)庫的功能，該功能支持一個自定義的SQL查詢，如圖1所示：

圖1 MySQL導(dǎo)出數(shù)據(jù)庫功能界面

經(jīng)過測試，研究員發(fā)現(xiàn)了兩個可利用點(diǎn)：

• 連接到MySQL做導(dǎo)出的用戶擁有FILE權(quán)限，在數(shù)據(jù)導(dǎo)出到存儲桶之前可將其暫存在’/mysql/tmp’目錄下。
• 當(dāng)運(yùn)行導(dǎo)出工具時，API實(shí)際會以某種方式調(diào)用mysqldump工具，并將數(shù)據(jù)庫以參數(shù)形式傳遞，也可傳遞其他參數(shù)

調(diào)研后發(fā)現(xiàn)，mysqldump的參數(shù)中有兩個似乎可以利用：--plugin-dir和—defualt-auth。其中--plugin-dir參數(shù)允許傳遞存儲客戶端插件的目錄，--default-auth指定認(rèn)證插件。結(jié)合這兩個可利用點(diǎn)，構(gòu)造了以下攻擊鏈：

制作一個具有反彈shell功能的evil_plugin.so插件，將其插入至數(shù)據(jù)庫并上傳至存儲桶內(nèi)，然后利用MySQL從存儲桶導(dǎo)出數(shù)據(jù)的功能，自定義SQL查詢語句為“SELECT * FROM data INTO DUMPFILE '/mysql/tmp/evil_plugin.so' #”，并修改數(shù)據(jù)包如圖2所示：

圖2 修改導(dǎo)出數(shù)據(jù)庫包

最終成功反彈數(shù)據(jù)庫服務(wù)所在容器的shell。

容器逃逸

經(jīng)過信息收集，發(fā)現(xiàn)Google Cloud SQL運(yùn)行數(shù)據(jù)庫服務(wù)的容器并非特權(quán)容器，執(zhí)行ifconfig的結(jié)果如圖3所示：

圖3 ifconfig結(jié)果

由此判斷容器共享了宿主機(jī)net命名空間，此種情況下可以攔截宿主機(jī)網(wǎng)卡上發(fā)送和接收的網(wǎng)絡(luò)流量。

當(dāng)使用Google提供的公共鏡像啟動虛擬機(jī)時，系統(tǒng)會自動在虛擬機(jī)實(shí)例上安裝google-guest-agent。該代理的作用是監(jiān)控元數(shù)據(jù)的變化，其中數(shù)據(jù)之一便是SSH公鑰。當(dāng)在元數(shù)據(jù)中發(fā)現(xiàn)一個新的SSH公鑰時，google-guest-agent會將這個公鑰寫入用戶的.authorized_key文件中，必要時會創(chuàng)建一個新的用戶并將其加入sudoer。結(jié)合google-guest-agent代理的功能和容器共享宿主機(jī)net命名空間的特點(diǎn)，研究員通過定制的工具rshijack[3]進(jìn)行流量劫持，成功在虛擬機(jī)上創(chuàng)建指定SSH用戶，連接至虛擬機(jī)完成容器逃逸。

CloudPostgreSQL權(quán)限提升+容器逃逸

PostgreSQL作為最流行的數(shù)據(jù)庫之一，也被公有云廠商云化改造用來提供服務(wù)。因?yàn)镻ostgreSQL有一套非常有限的權(quán)限模型，基本上不允許用戶只有某些管理能力，所以云廠商不得不對權(quán)限模型進(jìn)行改造，在保證用戶有某些管理功能的同時，限制一些不安全的操作。不同的云廠商改造的方式有所差別，一些通過引入擴(kuò)展或自定義配置來修改，還有一些通過修改PostgreSQL引擎代碼進(jìn)行改造，但這種改造很有可能會帶來意想不到的安全問題。

Wiz Research在多家公有云廠商的PostgreSQL發(fā)現(xiàn)漏洞[4]，可以用于權(quán)限提升，尤其是在Google公有云環(huán)境上，當(dāng)利用數(shù)據(jù)庫服務(wù)獲取容器shell時，便可以結(jié)合前文中劫持google-guest-agent流量的方式進(jìn)行容器逃逸，威脅公有云環(huán)境安全。

Google提供PostgreSQL服務(wù)時的賬戶為postgres，屬于cloudsqlsuperuser角色的一部分。通過查看官方文檔，查詢該角色擁有的權(quán)限如圖4所示：

圖4 Google cloudsqlsuperuser角色權(quán)限說明

該角色并非PostgreSQL的默認(rèn)行為，而是Google對其進(jìn)行了修改。觀察文檔發(fā)現(xiàn)，該角色允許改變表的所有權(quán)給數(shù)據(jù)庫中的任何用戶和角色，本意是將一些高權(quán)限的能力授予給低權(quán)限的用戶，但卻給了攻擊者可乘之機(jī)。

PostgreSQL中ALTER TABLE與索引函數(shù)相結(jié)合

值得關(guān)注的是，當(dāng)PostgreSQL的INSERT/UPDATE/ANALYZE命令在一個有索引函數(shù)的表中執(zhí)行時，該函數(shù)被作為命令的一部分調(diào)用，且是以表擁有者的權(quán)限調(diào)用。

圖5 索引函數(shù)被執(zhí)行示意

因此，可以構(gòu)造以下攻擊鏈進(jìn)行利用：

• 創(chuàng)建一個新的表
• 在表中插入一下任意內(nèi)容
• 在表中創(chuàng)建一個惡意的索引函數(shù)（包含具有反彈shell功能的惡意代碼）
• 更改表的所有者為cloudsqladmin（Google云平臺的超級用戶角色，僅用于維護(hù)和管理CloudSQL數(shù)據(jù)庫）
• 對表執(zhí)行ANALYZE命令，使得索引函數(shù)以cloudsqladmin權(quán)限調(diào)用，從而執(zhí)行惡意代碼

最終成功獲得容器的shell，權(quán)限為postgres用戶。然后，在擁有可寫權(quán)限的目錄下，發(fā)現(xiàn)了一個由root賬戶擁有的文件，利用符號鏈接攻擊提升權(quán)限至root（本文不再詳述，感興趣的可以閱讀原文），最終利用前文提到的劫持google-guest-agent流量的方式完成容器逃逸，獲得宿主機(jī)上的SSH登錄權(quán)限。

3.2 案例2——Microsoft Azure云服務(wù)漏洞

AzurePostgreSQL權(quán)限提升漏洞

與Coogle一樣，Microsoft Azure在提供PostgreSQL云服務(wù)時，也對其引擎做了二次修改，但Azure在PostgreSQL的權(quán)限管理方面有所不足。經(jīng)過測試發(fā)現(xiàn)，使用Azure PostgreSQL服務(wù)的用戶被授予了CREATEROLE權(quán)限。

CREATEROLE是一個十分強(qiáng)大的權(quán)限，被授予該權(quán)限的用戶可以創(chuàng)建新用戶，并將它們與特定的角色關(guān)聯(lián)起來。PostgreSQL本身內(nèi)置了一些強(qiáng)大的角色，如pg_read_server_files、pg_write_server_files和pg_execute_server_program，這些角色的權(quán)限如下：

pg_read_server_files -賦予用戶從文件系統(tǒng)中任意讀取文件的能力。

pg_write_server_files -賦予用戶向文件系統(tǒng)任意寫文件的能力。

pg_execute_server_program - 最強(qiáng)大的角色，賦予用戶在操作系統(tǒng)層面執(zhí)行任意命令的能力。

PostgreSQL的官方文檔也警告說，CREATEROLE角色幾乎為“超級用戶”。然而Azure在引入該角色時并未做修改和限制，導(dǎo)致用戶可以結(jié)合PostgreSQL的COPY功能在系統(tǒng)上任意執(zhí)行命令，從而獲取容器的權(quán)限。

Service Fabic權(quán)限提升漏洞

2022年6月，來自Unit 42實(shí)驗(yàn)室的研究員公開了Microsoft Service Fabric的漏洞——CVE-2022-30137，該漏洞允許攻擊者在容器內(nèi)提升權(quán)限至主機(jī)節(jié)點(diǎn)root權(quán)限，且利用門檻低，危害較大。

Server Fabric是一款分布式系統(tǒng)平臺，可方便用戶輕松打包、部署和管理可縮放的可靠微服務(wù)和容器。產(chǎn)品定位類似于Kubernetes，但又有所不同。Service Fabric目前為許多微軟服務(wù)提供支持，包括Azure SQL數(shù)據(jù)庫、Azure Cosmos DB、Cortana、Microsoft Power BI以及許多Azure核心服務(wù)。

一個Service Fabric集群由許多節(jié)點(diǎn)組成，每個節(jié)點(diǎn)都運(yùn)行一個容器引擎，執(zhí)行所需的容器化應(yīng)用，其每個節(jié)點(diǎn)上運(yùn)行的組件大致如圖6所示： 

圖6 Service Fabric Linux節(jié)點(diǎn)示例

Service Fabric支持將應(yīng)用程序部署為容器，在每個容器初始化期間，會創(chuàng)建一個新的日志目錄，并以讀寫權(quán)限加載到每個容器中。所有容器對應(yīng)的目錄都集中在每個節(jié)點(diǎn)的同一個路徑上。例如，在Azure Service Fabric產(chǎn)品中，這些目錄在/mnt/sfroot/log/Containers。

Data Collection Agent（DCA）是Service Fabric集群中的一個組件，負(fù)責(zé)從這些目錄中收集日志，以便后續(xù)處理。為了訪問這些目錄，它需要很高的權(quán)限，因此在每個節(jié)點(diǎn)上該組件都以root身份運(yùn)行。通過挖掘DCA的舊源代碼，研究員在函數(shù)GetIndex（PersistedIndex.cs:48）中有一個潛在的競爭條件的任意寫入。攻擊者可通過創(chuàng)建符號鏈接的方式，利用惡意內(nèi)容覆蓋節(jié)點(diǎn)文件系統(tǒng)中的文件，最終獲得節(jié)點(diǎn)上的代碼執(zhí)行權(quán)限，其攻擊鏈大致如圖7所示：

圖7 FabricScape攻擊鏈

• 利用GetIndex的競爭條件的引起任意寫入和DCA在主機(jī)上以root身份運(yùn)行的特點(diǎn)，創(chuàng)建符號鏈接覆蓋主機(jī)上的/etc/environment文件。
• 利用ServiceFabric節(jié)點(diǎn)上默認(rèn)運(yùn)行的CronJob的特點(diǎn)，在執(zhí)行作業(yè)時導(dǎo)入/etc/environment文件。
• 在Cronjob啟動進(jìn)程初始化時，加載/etc/environment文件中的LD_PRELOAD環(huán)境變量指向自定義的共享對象。
• 最終成功執(zhí)行共享對象中的反彈shell代碼，獲取到節(jié)點(diǎn)root權(quán)限。
• 在/var/lib/waagent/目錄下發(fā)現(xiàn)ServiceFabric集群管理工具sfctl所需的證書，利用sfctl工具接管整個集群，如圖8所示：

圖8 sfctl工具執(zhí)行實(shí)例

3.3 案例3——AWS云服務(wù)漏洞 

Log4Shell熱補(bǔ)丁容器逃逸和權(quán)限提升漏洞

Log4Shell（CVE-2021-44228）是2021年最嚴(yán)重的漏洞之一。AWS為了幫助用戶防御這個漏洞，針對不同的環(huán)境開源了幾個熱補(bǔ)丁解決方案。熱補(bǔ)丁是向有漏洞的運(yùn)行中的應(yīng)用程序注入一個修復(fù)程序的過程。它的目的是作為一個短期的解決方案，直到新的固定版本的應(yīng)用程序被部署。

但研究人員發(fā)現(xiàn)這些補(bǔ)丁可以被利用來進(jìn)行容器逃逸和權(quán)限提升[5]。為了修補(bǔ)容器內(nèi)的Java進(jìn)程，熱補(bǔ)丁調(diào)用了容器的 "java "二進(jìn)制文件兩次：一次是檢索Java版本，另一次是注入熱補(bǔ)丁。問題出現(xiàn)在調(diào)用容器二進(jìn)制文件時沒有正確地將其容器化，而是以主機(jī)root用戶運(yùn)行。因此，攻擊者可以通過在惡意容器內(nèi)運(yùn)行一個名為 "java "的惡意二進(jìn)制文件，讓熱補(bǔ)丁識別并以高權(quán)限調(diào)用，最終逃離容器并宿主機(jī)。

除了容器之外，熱補(bǔ)丁服務(wù)也以類似的方式對主機(jī)進(jìn)程進(jìn)行修補(bǔ)。因此攻擊者也可以通過創(chuàng)建并運(yùn)行一個名為 "java "的惡意二進(jìn)制文件，從普通進(jìn)程權(quán)限提升至root權(quán)限。

四、總結(jié)與思考

綜合文中提及的案例可知，公有云在提供便利的云服務(wù)的同時，也有可能帶來意想不到的風(fēng)險。即使是AWS、Google這樣的頭部廠商，也可能在設(shè)計(jì)和管理云服務(wù)時出現(xiàn)紕漏，給攻擊者以可乘之機(jī)。

站在攻擊者的角度來看，可以借鑒PostgreSQL等傳統(tǒng)產(chǎn)品上云后權(quán)限管理不當(dāng)?shù)陌咐钊胪诰蚰切┰品?wù)中的“釘子戶”，分析其脆弱性是否在上云之后有所改善以及改善方案是否也存在一定的利用點(diǎn)，尤其關(guān)注官方文檔中提示的風(fēng)險警告點(diǎn)。

站在防御者的角度來看，攻擊者在攻擊利用公有云服務(wù)時，大多情況下無法看到其代碼邏輯，只能通過黑盒的方式進(jìn)行攻擊測試，因此公有云廠商應(yīng)加強(qiáng)公有云環(huán)境中的入侵檢測系統(tǒng)，案例1中的研究員們在利用MySQL和PostgreSQL逃逸到宿主機(jī)之后均第一時間被Google員工發(fā)現(xiàn)并嘗試聯(lián)系，其他云廠商也應(yīng)如此。公有云環(huán)境作為黑客的一個“主戰(zhàn)場”，防御能力需要實(shí)時升級。

參考文獻(xiàn)

[1] http://avfisher.win/archives/1175

[2] https://www.ezequiel.tech/2020/08/dropping-shell-in.html

[3] https://github.com/kpcyrd/rshijack

[4] https://www.wiz.io/blog/the-cloud-has-an-isolation-problem-postgresql-vulnerabilities

[5] https://unit42.paloaltonetworks.com/aws-log4shell-hot-patch-vulnerabilities/?