Google Workspace全域委派功能的關鍵安全問題剖析

寫在前面的話

近期，Unit 42的研究人員在Google Workspace的全域委派功能中發現了一個關鍵安全問題，攻擊者將能夠利用該安全問題從Google Cloud Platform（GCP）中獲取Google Workspace域數據的訪問權。

根據研究人員的發現，一個具有必要權限的GCP角色可以為委派用戶生成訪問令牌，惡意內部攻擊者或竊取到憑證數據的外部攻擊者將能夠使用此訪問令牌來冒充 Google Workspace用戶，從而授予對目標數據未經授權的訪問權限，或直接代表合法用戶執行操作。

在這篇文章中，我們將重點討論Google Workspace全域委派功能中存在的關鍵安全問題，并分析攻擊者利用該問題的相關技術和方法，以及該問題對Google Workspace數據安全的影響。

全域委派功能濫用概述

下圖所示的潛在攻擊路徑為惡意內部攻擊者可能執行的操作，他們可以通過利用Google Workspace中被授予全域委派權限的服務帳號來實現這一目的，且內部人員有權為同一GCP項目內的服務帳戶生成訪問令牌：

啟用了全域委派權限后，惡意內部人員可以冒充Google Workspace域中的用戶并使用訪問令牌來驗證API請求。通過在適當的范圍利用API訪問權限，內部人員可以訪問和檢索Google Workspace的敏感數據，從而可能會泄露存儲在Google Workspace中的電子郵件、文檔和其他敏感信息。

如果獲得了跟計算引擎實例綁定的GCP服務帳戶令牌，則情況將更加嚴重。此時，攻擊者將可能利用全域委派功能來產生更大的影響。如果在同一項目中存在具有全域委派權限的服務帳號，這可能會導致攻擊者冒充委派的服務帳號并基于GCP實現橫向移動，并獲取對目標Google Workspace環境的訪問權限。

Google Workspace

在深入分析安全風險之前，我們先了解一下跟Google Workspace相關的基礎內容。

Google Workspace應用是一組基于云的協作工具，各組織可以使用Google Workspace并通過以下各種工具來提高工作效率和溝通能力：

1、電子郵件

2、日歷

3、文件存儲與共享

4、團隊溝通

5、工作流程自動化

6、安全

7、管理

Google Workspace提供基于角色的訪問控制（RBAC）功能，允許管理員向用戶分配特定角色，并根據他們的職責和需求向他們授予預定義的權限集。這些角色包括：

1、超級管理員

2、群組管理員

3、用戶管理管理員

每個角色都對組織的Google Workspace環境的不同方面擁有特定的權限和控制權。Google Workspace超級管理員擁有更高的權限和更廣泛的域管理職責，包括向服務帳號授予全域委派權限的能力。Google Workspace管理員還可以定義特定于應用程序的權限并限制共享和公開范圍，比如說，管理員可以強制執行策略，阻止用戶公開共享文件并限制共享選項，以確保文件始終限制在授權范圍內。

GCP和Google Workspace之間鏈接的一種常見場景，就是一個托管在GCP中的應用程序需要跟Google Workspace中的某個服務進行交互時，這些服務包括：

1、Gmail；

2、Calendar；

3、Drive；

4、Docs；

這種集成允許應用程序訪問和操作特定于用戶的數據、代表用戶執行操作或利用Google Workspace的協作和生產力功能。

需要委派的 GCP 服務帳戶才能創建與 Google 服務交互、訪問 Google API、處理用戶數據或代表用戶執行操作的應用程序。

什么是服務賬戶？

服務帳戶是GCP中的一種特殊類型帳戶，代表非人類實體，例如應用程序或虛擬機。服務賬戶將允許這些應用程序進行身份驗證并于Google API交互。服務帳戶與應用程序本身相關聯，而不是與單個最終用戶相關聯。

與用戶帳號的不同之處在于，服務帳號不是Google Workspace域的成員。它們不受Google Workspace管理員設置的域策略約束，且如果授予了全域委派權限，也只能訪問用戶的數據。

什么是全域委派？

全域委派是Google Workspace中的一項功能，它允許GCP服務帳號訪問Google Workspace用戶的數據，并在特定域內代表這些用戶來執行操作。

在使用全域委派功能時，應用程序可以代表Google Workspace域中的用戶執行操作，且無需單個用戶對應用程序進行身份驗證和授權。

只有Google Workspace超級用戶才能授權應用程序作為服務帳號代表域中的用戶訪問數據，這種授權被稱為服務賬號的“全域委派授權”。

全域委派的工作機制

如需使用全域委派功能，需要按照一下步驟設置和執行操作：

1、啟用全域委派：Google Workspace超級用戶為服務帳號授予全域委派權限，并設置可以訪問的OAuth范圍集合。這些范圍詳細說明了服務帳戶將有權訪問哪些特定服務和特定操作。比如說，如果授權范圍僅是/auth/gmail.readonly，則服務帳戶在代表用戶執行操作時將有權讀取用戶的Gmail郵件該用戶的數據，但不包括其其他工作區數據，例如對云端硬盤中文件的訪問權限；

2、請求Google Workspace訪問令牌：應用程序使用適當的憑證數據向Google Workspace令牌節點發送請求。其中包括服務帳戶的客戶端ID和客戶端密鑰，以及訪問用戶數據所需的范圍。如果請求有效并且服務帳戶已被授予必要的全域委派權限，則令牌節點將使用訪問令牌進行響應，應用程序可以使用此訪問令牌在請求的范圍限制內跨域訪問用戶數據；

3、API訪問：應用程序在 API 請求中包含訪問令牌作為身份認證Header，并代表服務帳戶充當身份驗證和授權的證明；

下圖顯示的是全域委派操作流程：

獲得全域委派權限后，Google Workspace中的服務賬戶將能夠訪問用戶數據，并代表用戶向Google API發送身份認證請求。具體可使用的功能和可訪問的數據需要取決于策略定義的范圍。

全域委派存在的安全風險和影響

一旦將全域委派權限授予了GCP服務賬戶，具有必要權限的GCP角色就可以為委派用戶生成訪問令牌，惡意內部攻擊者或竊取到憑證數據的外部攻擊者將能夠使用此訪問令牌來冒充 Google Workspace用戶，從而授予對目標數據未經授權的訪問權限，或直接代表合法用戶執行操作。

這種情況將導致全域委派權限的敏感程度與GCP平臺上管理的權限模型之間不匹配。

Google也在其官方文檔中就全域委派功能的授權問題標記了警告聲明，Google提到：“只有超級管理員才能管理全域委派功能，并且必須要指定每一個應用程序可以訪問的每一個API的范圍，并減少授予過多的權限。”

使用審計日志識別潛在的利用行為

如果不分析GCP和Google Workspace這兩個平臺的審計日志，就無法了解潛在利用活動的全貌并識別全域委派功能的任何親啊在濫用情況。其中，服務帳號密鑰日志將顯示在GCP日志中，而Google密鑰生成和API調用執行日志將顯示在Google Workspace日志中。

在下圖中，顯示了一個Cortex Web接口的XQL查詢，該查詢可以在GCP審計日志中搜索服務賬號的密鑰創建行為：

等價的Prisma Cloud RQL語句：

下圖顯示的是查詢服務賬號授權日志的XQL查詢：

等價的Prisma Cloud RQL語句：

下圖中，我們嘗試檢測是誰以及何時給目標服務賬號授予了全域委派權限：

等價的Prisma Cloud RQL語句：

下圖顯示的是Cortex Web接口中觸發的“Google Workspace管理員已啟用對GCP服務帳戶的全域委派，并授予其對敏感范圍的訪問權限”警報：

緩解方案

為了緩解潛在的安全風險問題，最佳的安全實踐是將具備全域委派權限的服務賬號設置在GCP層次結構中更高級別的文件夾處，因為GCP層次模型中，訪問控制是層次化的。

設置在更高級別的權限和策略并不會自動給低級別文件夾或項目授予訪問權限。訪問控制不會在層次結構中向下繼承，這意味著較低級別的文件夾或項目無法自動訪問較高級別的文件夾或項目：

這樣一來，也就降低了惡意內部人員利用該安全問題的可能性。除此之外，我們也可以阻止較低級別區域中的實體獲取服務賬號的訪問令牌，確保只有相同或更高級別文件夾或項目中的實體才能生成委派服務帳戶的訪問令牌。

參考資料

https://cloud.google.com/iam/docs/understanding-roles

https://developers.google.com/identity/protocols/oauth2/scopes

https://workspace.google.com/blog/product-announcements/introducing-google-workspace

https://developers.google.com/identity/protocols/oauth2/service-account

https://cloud.google.com/iam/docs/service-account-overview

參考來源

https://unit42.paloaltonetworks.com/critical-risk-in-google-workspace-delegation-feature/