一、引言

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

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

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

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

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

二、背景

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

三、案例研究

3.1 案例1——Google Cloud云服務漏洞

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

CloudMySQL命令執行+容器逃逸

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

圖1 MySQL導出數據庫功能界面

經過測試，研究員發現了兩個可利用點：

• 連接到MySQL做導出的用戶擁有FILE權限，在數據導出到存儲桶之前可將其暫存在’/mysql/tmp’目錄下。
• 當運行導出工具時，API實際會以某種方式調用mysqldump工具，并將數據庫以參數形式傳遞，也可傳遞其他參數

調研后發現，mysqldump的參數中有兩個似乎可以利用：--plugin-dir和—defualt-auth。其中--plugin-dir參數允許傳遞存儲客戶端插件的目錄，--default-auth指定認證插件。結合這兩個可利用點，構造了以下攻擊鏈：

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

圖2 修改導出數據庫包

最終成功反彈數據庫服務所在容器的shell。

容器逃逸

經過信息收集，發現Google Cloud SQL運行數據庫服務的容器并非特權容器，執行ifconfig的結果如圖3所示：

圖3 ifconfig結果

由此判斷容器共享了宿主機net命名空間，此種情況下可以攔截宿主機網卡上發送和接收的網絡流量。

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

CloudPostgreSQL權限提升+容器逃逸

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

Wiz Research在多家公有云廠商的PostgreSQL發現漏洞[4]，可以用于權限提升，尤其是在Google公有云環境上，當利用數據庫服務獲取容器shell時，便可以結合前文中劫持google-guest-agent流量的方式進行容器逃逸，威脅公有云環境安全。

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

圖4 Google cloudsqlsuperuser角色權限說明

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

PostgreSQL中ALTER TABLE與索引函數相結合

值得關注的是，當PostgreSQL的INSERT/UPDATE/ANALYZE命令在一個有索引函數的表中執行時，該函數被作為命令的一部分調用，且是以表擁有者的權限調用。

圖5 索引函數被執行示意

因此，可以構造以下攻擊鏈進行利用：

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

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

3.2 案例2——Microsoft Azure云服務漏洞

AzurePostgreSQL權限提升漏洞

與Coogle一樣，Microsoft Azure在提供PostgreSQL云服務時，也對其引擎做了二次修改，但Azure在PostgreSQL的權限管理方面有所不足。經過測試發現，使用Azure PostgreSQL服務的用戶被授予了CREATEROLE權限。

CREATEROLE是一個十分強大的權限，被授予該權限的用戶可以創建新用戶，并將它們與特定的角色關聯起來。PostgreSQL本身內置了一些強大的角色，如pg_read_server_files、pg_write_server_files和pg_execute_server_program，這些角色的權限如下：

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

pg_write_server_files -賦予用戶向文件系統任意寫文件的能力。

pg_execute_server_program - 最強大的角色，賦予用戶在操作系統層面執行任意命令的能力。

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

Service Fabic權限提升漏洞

2022年6月，來自Unit 42實驗室的研究員公開了Microsoft Service Fabric的漏洞——CVE-2022-30137，該漏洞允許攻擊者在容器內提升權限至主機節點root權限，且利用門檻低，危害較大。

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

一個Service Fabric集群由許多節點組成，每個節點都運行一個容器引擎，執行所需的容器化應用，其每個節點上運行的組件大致如圖6所示： 

圖6 Service Fabric Linux節點示例

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

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

圖7 FabricScape攻擊鏈

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

圖8 sfctl工具執行實例

3.3 案例3——AWS云服務漏洞 

Log4Shell熱補丁容器逃逸和權限提升漏洞

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

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

除了容器之外，熱補丁服務也以類似的方式對主機進程進行修補。因此攻擊者也可以通過創建并運行一個名為 "java "的惡意二進制文件，從普通進程權限提升至root權限。

四、總結與思考

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

站在攻擊者的角度來看，可以借鑒PostgreSQL等傳統產品上云后權限管理不當的案例，深入挖掘那些云服務中的“釘子戶”，分析其脆弱性是否在上云之后有所改善以及改善方案是否也存在一定的利用點，尤其關注官方文檔中提示的風險警告點。

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

參考文獻

[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/?