taibeihacker
Moderator
RSAC议题解读-云上跨租户漏洞攻击面分析
2023 年的RSAC 會議上兩位來自Wiz 的安全研究員，分享了名為《Tackling the Recent Rise of Cross-Tenant Vulnerabilities》 的議題。兩位研究員提出一個新興的攻擊方向，即跨租戶漏洞，介紹相關概念，並在現網環境中挖掘Google Cloud、AWS、Alibaba Cloud 等跨租戶漏洞，影響巨大。1 相关概念
1.1 多租户技术
多租戶技術是一種在雲計算環境中廣泛使用的架構設計方法，用於在單個應用程序或服務中同時支持多個獨立的租戶或用戶。在傳統的單租戶架構中，每個應用程序或服務只為一個租戶提供服務。而在多租戶架構中，應用程序或服務被設計成可以同時為多個租戶提供服務，而且每個租戶都被隔離在彼此之間，彼此獨立且互不干擾。
多租戶技術的關鍵特點是資源共享和隔離。多個租戶共享相同的基礎設施，包括硬件、網絡和軟件組件等，從而實現資源的高效利用。同時，每個租戶之間的數據和運行環境是相互隔離的，確保租戶之間的安全性和隱私性。
多租戶架構通常在平台即服務（PaaS）和軟件即服務（SaaS）等雲服務模型中得到廣泛應用。在這些模型中，雲提供商為多個租戶提供相同的應用程序或服務實例，而每個租戶都可以定制和管理自己的數據和配置。
1.2 跨租户漏洞
在雲上多租戶技術廣泛應用的場景下，跨租戶漏洞應運而生。跨租戶漏洞是指存在於多租戶環境中的安全漏洞，可能導致一個租戶能夠訪問或乾擾其他租戶的數據或資源。這種漏洞可能會引起嚴重的安全問題，攻擊者可以通過跨租戶漏洞獲取租戶的數據或系統控制權，嚴重破壞了租戶之間的隔離性和安全性。
2 租户隔离的实现方式
2.1 逻辑隔离
邏輯隔離是一種十分簡單的租戶隔離方式，租戶在共享數據庫實例中擁有一個專用數據庫。但是每個客戶都擁有自己的憑據，來保證不同用戶之間的隔離。
這種隔離方式在工業實踐中有良好的可操作性，軟件架構簡單且易於實現，成本較低。但是一旦出現單點故障，將影響數據庫實例下的所有租戶。
此外，當一個數據庫被攻擊者攻破後，比如攻擊者從當前租戶權限提升到管理員權限，攻擊者就可以訪問其它租戶的數據。此外，對於一些運維人員來說，在配置數據庫實例的時候，很容易出現配置不當的問題。在這種情況下，攻擊者甚至不必利用0-day 提升權限，通過只是濫用某些錯誤配置，就可以達到訪問其它用戶數據的目的。
2.2 基于容器的隔离
基於容器的隔離相比於上面的隔離方法具有一定優勢。在這種隔離方法中，不再是多個客戶共享同一個數據庫實例，每個客戶都有自己的數據庫實例，在相對獨立的容器內運行， 並且多個客戶可能共享同一個虛擬機。
這種隔離方式同樣相對便宜且易於實施。當攻擊者想要突破隔離時，需要打破兩層安全邊界，即：第一層數據庫，與上一種方式相同；第二層容器。一旦攻擊者從容器中逃逸出來，就可以在虛擬機上執行任意代碼，在虛擬機中，可以看到其它租戶的容器，並能夠訪問他們的數據。
雖然這種隔離方式看上去是一個更好的方法，與前面的方法相比，它仍有其缺點。正如一些安全研究人員所認為的那樣，容器不被認為是一個非常強大的安全屏障，每隔一段時間Linux 都會發布一些內核漏洞，部分漏洞通過武器化，可以被用來容器逃逸。
Wiz 團隊針對阿里雲數據庫披露了一個報告，具體細節在第三章節進行闡述。
2.3 基于虚拟机的隔离
第三種隔離租戶的方法，也是大多數服務提供商傾向於做的，即：基於虛擬機的隔離。在這種隔離方法中，每個租戶都有自己的數據庫實例，在單獨的專用虛擬機中運行。因此，客戶現在共享的是物理計算資源，而不是像之前的隔離方法那樣，共享一個虛擬機。
如圖所示，攻擊者想要打破這種隔離方式，需要打破兩到三層安全邊界，第一層然需要數據庫漏洞，能夠執行任意代碼。第二層可能需要進行容器逃逸，第三層虛擬機漏洞。通常來說，VM 逃逸漏洞更難挖掘。
當每一個租戶都有自己專用的虛擬機，雲服務提供商的成本變得相當昂貴。與此同時，架構也開始變得很難維護，隔離服務越強，越難實際調試服務，並解決服務中的問題。
3 真实环境中的漏洞案例
租戶隔離不僅僅是要實現隔離計算資源。還有有其它資源和其它資產。首先來看，在一個常見的租戶隔離系統中，有哪些風險暴露面：
比如像Kubernetes 或service Fabric 這樣的編排器、內部API。此外通常託管服務運行在共享網絡環境中，數據可以通過共享網絡進行交互。另外存儲、身份認證設施等也同樣需要考慮隔離。
3.1 阿里云 AnalyticDB for PostgreSQL
雲原生數據倉庫AnalyticDB PostgreSQL版是一種大規模並行處理（MPP）數據倉庫服務，可提供海量數據在線分析服務。針對AnalyticDB for PostgreSQL 的攻擊鏈大致如下：
利用cronjob 定時任務提權至容器內的root 權限。
利用Pod 內容器共享PID 命名空間的特性橫向移動到Pod 中的相鄰特權容器。
利用特權容器逃逸至宿主機。
利用宿主機上的kubelet 憑證訪問敏感資源，包括密鑰、serviceaccount 和Pod。
利用收集到的憑證訪問阿里雲私有容器鏡像倉庫，查看憑證權限。
經測試發現憑據具有容器鏡像倉庫的讀取和寫入權限，允許發起供應鏈攻擊。
已有相關文章分析該漏洞，在此不做贅述。
3.2 Azure Database for PostgreSQL
在Azure Database for PostgreSQL 中，不同租戶間的數據庫並沒有做網絡隔離，也就是說兩個租戶間是有網絡聯通的。 Wiz 的研究人員首先通過漏洞獲得了對自己數據庫的訪問權，又因為當前機器能夠與其它數據庫通信，並通過偽造SSL 證書，並繞過對其它數據庫的身份驗證，獲取對其它租戶數據的完全讀取權限。微軟對此漏洞的修復是對租戶間的網絡進行隔離，來保證租戶間的相對獨立。
3.3 IBM Managed Databases
IBM Managed Databases 這個案例比較有趣，在這個案例中，IBM 服務的架構比較完善，資源分離也設計得很好，每個租戶有專門的Kubernetes 命名空間：
但是研究人員在容器中發現了K8S API 的網絡連接，同時，由於K8S 本身配置不當，將高權限service account 掛在到當前pod 中，因此可以利用該Token 向K8S API 直接發送請求，執行K8S 相關操作。經過研究人員的測試，該Token 有在私有倉庫拉取鏡像的權限：
因此，攻擊者可以拿到鏡像倉庫的所有鏡像：
鏡像中包含大量數據，包括源碼、配置等。通過對鏡像內容進行分析，找到內部CI/CD 服務器憑證，具有讀寫權限，可以實施供應鏈攻擊。
3.4 其它案例
筆者在公司內部某產品線做安全測試時，也曾遇到過類似的安全問題，由於租戶間未做好隔離，導致獲取大量租戶權限與數據的問題。以其中一個為例：
在某站點創建遠程計算資源（在線IDE）時，用戶會收到一封接入內網的VPN 配置連接郵件，在撥入VPN 後，發現內網並未做隔離，租戶間網絡互通。
直接在內網申請的資源主機上掃10.208.0.0/16 網段，發現做了隔離。但是，嘗試在本機上對VPN 網段172.36.0.0/16 進行掃描，發現未做隔離，結果如下：
以內網一台租戶申請的機器為例，由於在線IDE 具有Terminal 功能，且未對用戶權限做校驗，因此可以執行命令，在線IDE 中的用戶為devkit 普通用戶：
經過信息收集，發現此類主機均為雲上統一下發的機器，查看查詢ECS 的用戶自定義數據找到初始化SSH 登錄密鑰：
1
curl http://169.254.169.254/openstack/latest/user_data
在user_data 記錄了SSH 的明文密碼，可以直接利用該密碼切換到root:
通過這種方式，可以批量橫向到各個租戶，獲取大量租戶資源機器的root 權限，並登錄SSH，獲取機器內存放的各種資源文件。