Translated ['src/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting

This commit is contained in:
Translator
2025-05-17 05:01:02 +00:00
parent 9c38e2c503
commit cae6f7ee54
2 changed files with 156 additions and 130 deletions

View File

@@ -9,9 +9,9 @@
Google Workspace 的域范围委托允许一个身份对象,无论是来自 Google Workspace Marketplace 的 **外部应用** 还是内部的 **GCP 服务账户****代表用户访问 Workspace 中的数据**。
> [!NOTE]
> 这基本上意味着 **GCP 项目** 中的 **服务账户** 可能能够 **冒充同一组织的 Workspace 用户**(甚至是来自不同组织的用户)。
> 这基本上意味着,组织内 GCP 项目中的 **服务账户** 可能能够 **冒充同一组织的 Workspace 用户**(甚至是来自不同组织的用户)。
有关如何具体工作的更多信息,请查看:
有关如何具体工作的更多信息,请查看:
{{#ref}}
gcp-understanding-domain-wide-delegation.md
@@ -20,7 +20,7 @@ gcp-understanding-domain-wide-delegation.md
### 破坏现有委托
如果攻击者 **获得了对 GCP 的某些访问权限** 并且 **知道公司中一个有效的 Workspace 用户邮箱**(最好是 **超级管理员**),他可以 **枚举他有访问权限的所有项目****枚举项目的所有服务账户**,检查他 **可以访问的服务账户**,并 **对每个可以冒充的服务账户重复** 所有这些步骤。\
通过 **他有访问权限的所有服务账户的列表****Workspace 邮箱** 的列表,攻击者可以尝试 **用每个服务账户冒充用户**
通过 **他有访问权限的所有服务账户的列表****Workspace** **邮箱的列表**,攻击者可以尝试 **用每个服务账户冒充用户**
> [!CAUTION]
> 请注意,在配置域范围委托时不需要任何 Workspace 用户,因此只需知道 **一个有效的用户就足够并且是冒充所需的**。\
@@ -36,22 +36,26 @@ python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-ke
# Impersonate indicated user and add additional scopes
python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-key-file> --scopes "https://www.googleapis.com/auth/userinfo.email, https://www.googleapis.com/auth/cloud-platform, https://www.googleapis.com/auth/admin.directory.group, https://www.googleapis.com/auth/admin.directory.user, https://www.googleapis.com/auth/admin.directory.domain, https://mail.google.com/, https://www.googleapis.com/auth/drive, openid"
```
#### [**DelePwn**](https://github.com/n0tspam/delepwn)
基于以下 DeleFriend 工具但增加了一些功能如枚举域、驱动、gmail、日历并执行其他操作。
#### [**DeleFriend**](https://github.com/axon-git/DeleFriend)
这是一个可以执行以下步骤的工具
这是一个可以执行攻击的工具,遵循以下步骤:
1. **使用资源管理器 API 枚举 GCP 项目**
2. 迭代每个项目资源,并使用 _GetIAMPolicy_ **枚举 GCP 服务账户资源**,以确定初始 IAM 用户的访问权限。
3. 迭代 **每个服务账户角色**,并查找在目标服务账户资源上具有 _**serviceAccountKeys.create**_ 权限的内置、基本和自定义角色。需要注意的是,编辑者角色本身就具备此权限。
4. 为在 IAM 策略中找到相关权限的每个服务账户资源创建一个 **新的 `KEY_ALG_RSA_2048`** 私钥。
5. 迭代 **每个新服务账户并为其创建一个 `JWT`** **对象**,该对象由 SA 私钥凭和 OAuth 范围组成。创建新 _JWT_ 对象的过程将 **迭代所有现有的 OAuth 范围组合**,以查找所有的委托可能性。列表 **oauth_scopes.txt** 会更新所有我们发现与滥用 Workspace 身份相关的 OAuth 范围。
1. **使用 Resource Manager API 枚举 GCP 项目**
2. 遍历每个项目资源,并 **枚举 GCP 服务账户资源**,以获取初始 IAM 用户的访问权限,使用 _GetIAMPolicy_
3. 遍历 **每个服务账户角色**,并查找在目标服务账户资源上具有 _**serviceAccountKeys.create**_ 权限的内置、基本和自定义角色。需要注意的是,编辑者角色本身就拥有此权限。
4.每个在 IAM 策略中找到相关权限的服务账户资源创建一个 **新的 `KEY_ALG_RSA_2048`** 私钥。
5. 遍历 **每个新服务账户并为其创建一个 `JWT`** **对象**,该对象由 SA 私钥凭和 OAuth 范围组成。创建新 _JWT_ 对象的过程将 **遍历所有现有的 OAuth 范围组合**,以便找到所有的委托可能性。列表 **oauth_scopes.txt** 会更新所有我们发现与滥用 Workspace 身份相关的 OAuth 范围。
6. `_make_authorization_grant_assertion` 方法揭示了声明一个 **目标工作区用户**(称为 _subject_)以在 DWD 下生成 JWT 的必要性。虽然这似乎需要一个特定用户,但重要的是要意识到 **DWD 影响域内的每个身份**。因此,为 **任何域用户** 创建 JWT 会影响该域中的所有身份,这与我们的组合枚举检查一致。简单来说,一个有效的 Workspace 用户就足够继续前进。\
该用户可以在 DeleFriend 的 _config.yaml_ 文件中定义。如果目标工作区用户尚不明确,该工具通过扫描在 GCP 项目上具有角色的域用户来自动识别有效的工作区用户。需要再次注意的是JWT 是特定于域的,并不是为每个用户生成的;因此,自动过程针对每个域的单一唯一身份。
7. **枚举并为每个 JWT 创建一个新的承载访问令牌**,并通过 tokeninfo API 验证该令牌。
#### [Gitlab's Python script](https://gitlab.com/gitlab-com/gl-security/threatmanagement/redteam/redteam-public/gcp_misc/-/blob/master/gcp_delegation.py)
Gitlab 创建了 [这个 Python 脚本](https://gitlab.com/gitlab-com/gl-security/gl-redteam/gcp_misc/blob/master/gcp_delegation.py),可以做两件事 - 列出用户目录并创建一个新的管理账户,同时指明一个包含 SA 凭和要模拟的用户的 json。以下是使用方法
Gitlab 创建了 [这个 Python 脚本](https://gitlab.com/gitlab-com/gl-security/gl-redteam/gcp_misc/blob/master/gcp_delegation.py),可以做两件事 - 列出用户目录并创建一个新的管理账户,同时指明一个包含 SA 凭和要模拟的用户的 json。以下是如何使用它的说明
```bash
# Install requirements
pip install --upgrade --user oauth2client
@@ -77,28 +81,28 @@ pip install --upgrade --user oauth2client
可以在 [**https://admin.google.com/u/1/ac/owl/domainwidedelegation**](https://admin.google.com/u/1/ac/owl/domainwidedelegation)** 中** **检查域范围委托**
具有 **在 GCP 项目中创建服务****GWS 超级管理员权限的攻击者可以创建新的委托,允许服务户冒充某些 GWS 用户:**
具有 **在 GCP 项目中创建服务****GWS 超级管理员权限的攻击者可以创建新的委托,允许服务户冒充某些 GWS 用户:**
1. **生成新的服务户及相应的密钥对:** 在 GCP 上,可以通过控制台交互式或使用直接 API 调用和 CLI 工具以编程方式生成新的服务帐户资源。这需要 **角色 `iam.serviceAccountAdmin`** 或任何配备有 **`iam.serviceAccounts.create`** **权限** 的自定义角色。服务户创建后,我们将继续生成 **相关的密钥对****`iam.serviceAccountKeys.create`** 权限)。
1. **生成新的服务户及相应的密钥对:** 在 GCP 上,可以通过控制台交互式生成新的服务账户资源,或使用直接 API 调用和 CLI 工具以编程方式生成。这需要 **角色 `iam.serviceAccountAdmin`** 或任何具备 **`iam.serviceAccounts.create`** **权限** 的自定义角色。服务户创建后,我们将继续生成 **相关的密钥对****`iam.serviceAccountKeys.create`** 权限)。
2. **创建新的委托:** 重要的是要理解,**只有超级管理员角色具备在 Google Workspace 中设置全局域范围委托的能力**,并且域范围委托 **不能以编程方式设置,** 只能通过 Google Workspace **控制台** 手动创建和调整。
- 规则的创建可以在页面 **API 控制 → Google Workspace 管理控制台中管理域范围委托** 下找到。
3. **附加 OAuth 范围权限:** 在配置新的委托时Google 仅要求 2 个参数,即客户端 ID这是 **GCP 服务** 资源的 **OAuth ID**,以及定义委托所需 API 调用的 **OAuth 范围**
- 规则的创建可以在页面 **API 控制 → 管理 Google Workspace 管理控制台中域范围委托** 下找到。
3. **附加 OAuth 范围权限:** 在配置新的委托时Google 仅要求 2 个参数,即客户端 ID这是 **GCP 服务** 资源的 **OAuth ID**,以及定义委托所需 API 调用的 **OAuth 范围**
- **完整的 OAuth 范围列表** 可以在 [**这里**](https://developers.google.com/identity/protocols/oauth2/scopes) 找到,但这里有一个推荐:`https://www.googleapis.com/auth/userinfo.email, https://www.googleapis.com/auth/cloud-platform, https://www.googleapis.com/auth/admin.directory.group, https://www.googleapis.com/auth/admin.directory.user, https://www.googleapis.com/auth/admin.directory.domain, https://mail.google.com/, https://www.googleapis.com/auth/drive, openid`
4. **代表目标身份进行操作:** 此时,我们在 GWS 中有一个有效的委托对象。现在,**使用 GCP 服务户私钥,我们可以执行 API 调用**(在 OAuth 范围参数中定义的范围内)来触发它并 **代表 Google Workspace 中存在的任何身份进行操作**。正如我们所了解到的,服务户将根据其需求和对 REST API 应用程序的权限生成访问令牌。
4. **代表目标身份进行操作:** 此时,我们在 GWS 中有一个功能正常的委托对象。现在,**使用 GCP 服务户私钥,我们可以执行 API 调用**(在 OAuth 范围参数中定义的范围内)来触发它**代表 Google Workspace 中存在的任何身份进行操作**。正如我们所了解到的,服务户将根据其需求和对 REST API 应用程序的权限生成访问令牌。
- 请查看 **上一部分** 以获取一些 **使用此委托的工具**
#### 跨组织委托
OAuth SA ID 是全局的,可以用于 **跨组织委托**。没有实施任何限制来防止跨全球委托。简单来说,**来自不同 GCP 组织的服务户可以用于在其他 Workspace 组织上配置域范围委托**。这将导致 **只需对 Workspace 的超级管理员访问权限,而不需要对同一 GCP 账户的访问权限,因为对手可以在其个人控制的 GCP 账户上创建服务户和私钥**
OAuth SA ID 是全局的,可以用于 **跨组织委托**。没有实施任何限制来防止跨全球委托。简单来说,**来自不同 GCP 组织的服务户可以用于在其他 Workspace 组织上配置域范围委托**。这将导致 **只需对 Workspace 的超级管理员访问权限,而不需要对同一 GCP 账户的访问权限,因为对手可以在其个人控制的 GCP 账户上创建服务户和私钥**
### 创建项目以枚举 Workspace
默认情况下Workspace **用户** 具有 **创建新项目** 的权限,当创建新项目时,**创建者获得对其的所有者角色**。
默认情况下Workspace **用户** 具有 **创建新项目** 的权限,当创建新项目时,**创建者获得所有者角色**。
因此,用户可以 **创建一个项目****启用** **API**在其新项目中枚举 Workspace并尝试 **枚举** 它。
因此,用户可以 **创建一个项目****启用** 其新项目中的 **API** 以枚举 Workspace并尝试 **枚举** 它。
> [!CAUTION]
> 为了使用户能够枚举 Workspace他还需要足够的 Workspace 权限(并非每个用户都能枚举目录)。
> 为了使用户能够枚举 Workspace他还需要足够的 Workspace 权限(并非每个用户都能枚举目录)。
```bash
# Create project
gcloud projects create <uniq-projec-name> --name=proj-name
@@ -122,7 +126,7 @@ gcloud beta identity groups preview --customer <org-cust-id>
../gcp-services/gcp-iam-and-org-policies-enum.md
{{#endref}}
### 滥用 Gcloud 凭
### 滥用 Gcloud 凭
您可以在以下位置找到有关 `gcloud` 登录流程的更多信息:
@@ -131,7 +135,7 @@ gcloud beta identity groups preview --customer <org-cust-id>
{{#endref}}
如上所述gcloud 可以请求范围 **`https://www.googleapis.com/auth/drive`**,这将允许用户访问该用户的驱动器。\
作为攻击者,如果您已 **物理** 入侵用户的计算机并且 **用户仍然登录** 其帐户,您可以通过生成访问驱动器的令牌进行登录:
作为攻击者,如果您已 **物理** 入侵用户的计算机并且 **用户仍然登录** 其帐户,您可以通过生成访问驱动器的令牌进行登录:
```bash
gcloud auth login --enable-gdrive-access
```
@@ -148,13 +152,13 @@ gcloud auth login --enable-gdrive-access
### 访问特权 GCP 用户
如果攻击者完全访问 GWS他将能够访问具有 GCP 特权访问权限的组或甚至用户,因此从 GWS 转移到 GCP 通常更“简单”,仅仅因为 **GWS 中的用户 GCP 具有高权限**
如果攻击者完全访问 GWS他将能够访问具有 GCP 特权访问权限的组或甚至用户,因此从 GWS 转移到 GCP 通常更“简单”,因为 **GWS 中的用户 GCP 具有高权限**
### Google Groups 特权升级
默认情况下,用户可以 **自由加入组织的 Workspace 组**,这些组 **可能具有分配的 GCP 权限**(在 [https://groups.google.com/](https://groups.google.com/) 中检查您的组)。
通过滥用 **google groups privesc**,您可能能够升级到具有某种特权访问 GCP 的组。
通过滥用 **google groups privesc**,您可能能够升级到具有某种 GCP 特权访问权限的组。
### 参考