mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-02-05 03:16:37 -08:00
Translated ['src/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting
This commit is contained in:
@@ -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 特权访问权限的组。
|
||||
|
||||
### 参考
|
||||
|
||||
|
||||
Reference in New Issue
Block a user