mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-28 22:51:09 -07:00
Translated ['src/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting
This commit is contained in:
Translator
@@ -11,7 +11,7 @@ Google Workspace 的域范围委托允许一个身份对象，无论是来自 Go
|
||||
> [!NOTE]
|
||||
> 这基本上意味着 **GCP 项目** 中的 **服务账户** 可能能够 **冒充同一组织的 Workspace 用户**（甚至是来自不同组织的用户）。
|
||||
|
||||
有关此如何具体工作的更多信息，请查看：
|
||||
有关这如何具体工作的更多信息，请查看：
|
||||
|
||||
{{#ref}}
|
||||
gcp-understanding-domain-wide-delegation.md
|
||||
@@ -19,12 +19,12 @@ gcp-understanding-domain-wide-delegation.md
|
||||
|
||||
### 破坏现有委托
|
||||
|
||||
如果攻击者 **获得了对 GCP 的某些访问权限** 并且 **知道公司一个有效的 Workspace 用户邮箱**（最好是 **超级管理员**），他可以 **枚举所有他有访问权限的项目**，**枚举项目的所有服务账户**，检查他 **可以访问的服务账户**，并 **对每个他可以冒充的服务账户重复** 所有这些步骤。\
|
||||
如果攻击者 **获得了对 GCP 的某些访问权限** 并且 **知道公司中一个有效的 Workspace 用户邮箱**（最好是 **超级管理员**），他可以 **枚举他有访问权限的所有项目**，**枚举项目的所有服务账户**，检查他 **可以访问的服务账户**，并 **对每个可以冒充的服务账户重复** 所有这些步骤。\
|
||||
通过 **他有访问权限的所有服务账户的列表** 和 **Workspace 邮箱** 的列表，攻击者可以尝试 **用每个服务账户冒充用户**。
|
||||
|
||||
> [!CAUTION]
|
||||
> 请注意，在配置域范围委托时不需要任何 Workspace 用户，因此只需知道 **一个有效的用户就足够并且是冒充所需的**。\
|
||||
> 然而，**将使用被冒充用户的权限**，因此如果是超级管理员，您将能够访问所有内容。如果没有任何访问权限，这将毫无用处。
|
||||
> 然而，**被冒充用户的权限将被使用**，因此如果是超级管理员，您将能够访问所有内容。如果没有任何访问权限，这将毫无用处。
|
||||
|
||||
#### [GCP 生成委托令牌](https://github.com/carlospolop/gcp_gen_delegation_token)
|
||||
|
||||
@@ -40,18 +40,18 @@ python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-ke
|
||||
|
||||
这是一个可以执行以下步骤的工具：
|
||||
|
||||
1. **枚举 GCP 项目** 使用 Resource Manager API。
|
||||
2. 迭代每个项目资源，并 **枚举 GCP 服务账户资源**，以获取初始 IAM 用户可以访问的资源，使用 _GetIAMPolicy_。
|
||||
3. 迭代 **每个服务账户角色**，并查找在目标服务账户资源上具有 _**serviceAccountKeys.create**_ 权限的内置、基本和自定义角色。需要注意的是，Editor 角色本身就具备此权限。
|
||||
4. 为在 IAM 策略中找到的每个服务账户资源创建一个 **新的 `KEY_ALG_RSA_2048`** 私钥。
|
||||
5. 迭代 **每个新服务账户并为其创建一个 `JWT`** **对象**，该对象由 SA 私钥凭据和 OAuth 范围组成。创建新 _JWT_ 对象的过程将 **迭代所有现有的 OAuth 范围组合**，来自 **oauth_scopes.txt** 列表，以找到所有的委托可能性。列表 **oauth_scopes.txt** 更新了我们发现的所有与滥用 Workspace 身份相关的 OAuth 范围。
|
||||
6. `_make_authorization_grant_assertion` 方法揭示了声明一个 **目标工作区用户**（称为 _subject_）以在 DWD 下生成 JWT 的必要性。虽然这似乎需要一个特定用户，但重要的是要意识到 **DWD 影响域内的每个身份**。因此，为 **任何域用户** 创建 JWT 会影响该域中的所有身份，这与我们的组合枚举检查一致。简单来说，一个有效的 Workspace 用户就足够继续。\
|
||||
该用户可以在 DeleFriend 的 _config.yaml_ 文件中定义。如果目标工作区用户尚不明确，该工具通过扫描在 GCP 项目上具有角色的域用户来自动识别有效的工作区用户。需要再次注意的是，JWT 是特定于域的，并不是为每个用户生成的；因此，自动过程针对每个域的唯一身份。
|
||||
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 范围。
|
||||
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 +77,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 应用程序的权限生成访问令牌。
|
||||
- 检查 **上一部分** 以获取一些 **工具** 来使用此委托。
|
||||
- 请查看 **上一部分** 以获取一些 **使用此委托的工具**。
|
||||
|
||||
#### 跨组织委托
|
||||
|
||||
OAuth SA ID 是全局的，可以用于 **跨组织委托**。没有实施任何限制来防止跨全球委托。简单来说，**来自不同 GCP 组织的服务帐户可以用于在其他 Workspace 组织上配置域范围委托**。这将导致 **只需要对 Workspace 的超级管理员访问权限，而不需要访问相同的 GCP 账户，因为对手可以在其个人控制的 GCP 账户上创建服务帐户和私钥**。
|
||||
OAuth SA ID 是全局的，可以用于 **跨组织委托**。没有实施任何限制来防止跨全球委托。简单来说，**来自不同 GCP 组织的服务帐户可以用于在其他 Workspace 组织上配置域范围委托**。这将导致 **只需对 Workspace 的超级管理员访问权限，而不需要对同一 GCP 账户的访问权限，因为对手可以在其个人控制的 GCP 账户上创建服务帐户和私钥**。
|
||||
|
||||
### 创建项目以枚举 Workspace
|
||||
|
||||
默认情况下，Workspace **用户** 具有 **创建新项目** 的权限，当创建新项目时，**创建者获得所有者角色**。
|
||||
默认情况下，Workspace **用户** 具有 **创建新项目** 的权限，当创建新项目时，**创建者获得对其的所有者角色**。
|
||||
|
||||
因此，用户可以 **创建一个项目**，**启用** **API** 以在其新项目中枚举 Workspace，并尝试 **枚举** 它。
|
||||
|
||||
> [!CAUTION]
|
||||
> 为了使用户能够枚举 Workspace，他还需要足够的 Workspace 权限（并非每个用户都能枚举目录）。
|
||||
> 为了使用户能够枚举 Workspace，他还需要足够的 Workspace 权限（并非每个用户都能够枚举目录）。
|
||||
```bash
|
||||
# Create project
|
||||
gcloud projects create <uniq-projec-name> --name=proj-name
|
||||
@@ -122,16 +122,16 @@ gcloud beta identity groups preview --customer <org-cust-id>
|
||||
../gcp-services/gcp-iam-and-org-policies-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### 滥用 Gcloud 凭据
|
||||
### 滥用 Gcloud 凭证
|
||||
|
||||
您可以在以下位置找到有关 `gcloud` 登录流程的更多信息：
|
||||
|
||||
{{#ref}}
|
||||
../gcp-persistence/gcp-non-svc-persistance.md
|
||||
../gcp-persistence/gcp-non-svc-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
如上所述，gcloud 可以请求范围 **`https://www.googleapis.com/auth/drive`**，这将允许用户访问用户的驱动器。\
|
||||
作为攻击者，如果您 **物理上** 入侵了用户的计算机，并且 **用户仍然登录** 其帐户，您可以使用以下方式生成访问驱动器的令牌进行登录：
|
||||
如上所述，gcloud 可以请求范围 **`https://www.googleapis.com/auth/drive`**，这将允许用户访问该用户的驱动器。\
|
||||
作为攻击者，如果您已 **物理** 入侵用户的计算机并且 **用户仍然登录** 其帐户，您可以通过生成访问驱动器的令牌进行登录：
|
||||
```bash
|
||||
gcloud auth login --enable-gdrive-access
|
||||
```
|
||||
@@ -148,13 +148,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/) 中检查您的组）。
|
||||
默认情况下，用户可以 **自由加入组织的 Workspace 组**，这些组 **可能具有分配的 GCP 权限**（在 [https://groups.google.com/](https://groups.google.com/) 中检查您的组）。
|
||||
|
||||
通过滥用 **google groups privesc**，您可能能够升级到具有某种 GCP 特权访问权限的组。
|
||||
通过滥用 **google groups privesc**，您可能能够升级到具有某种特权访问 GCP 的组。
|
||||
|
||||
### 参考
|
||||
|
||||
|
||||
@@ -10,7 +10,7 @@ https://book.hacktricks.wiki/en/generic-methodologies-and-resources/phishing-met
|
||||
|
||||
## Google Groups Phishing
|
||||
|
||||
显然，默认情况下，在workspace成员[**可以创建群组**](https://groups.google.com/all-groups) **并邀请人们加入**。然后，您可以修改将发送给用户的电子邮件，**添加一些链接**。该**电子邮件将来自谷歌地址**，因此看起来**合法**，人们可能会点击链接。
|
||||
显然，默认情况下，在workspace成员[**可以创建群组**](https://groups.google.com/all-groups) **并邀请人加入**。然后，您可以修改将发送给用户的电子邮件，**添加一些链接**。该**电子邮件将来自谷歌地址**，因此看起来**合法**，人们可能会点击链接。
|
||||
|
||||
还可以将**发件人**地址设置为**Google群组电子邮件**，以向**群组内的用户发送更多电子邮件**，如以下图像所示，其中创建了群组**`google--support@googlegroups.com`**，并向该群组的**所有成员**发送了**电子邮件**（这些成员是在没有任何同意的情况下添加的）
|
||||
|
||||
@@ -18,7 +18,7 @@ https://book.hacktricks.wiki/en/generic-methodologies-and-resources/phishing-met
|
||||
|
||||
## Google Chat Phishing
|
||||
|
||||
您可能能够仅通过拥有他们的电子邮件地址**开始与某人聊天**或发送**邀请进行对话**。此外，可以**创建一个空间**，可以有任何名称（例如“Google支持”）并**邀请**成员加入。如果他们接受，他们可能会认为自己正在与Google支持进行对话：
|
||||
您可能能够仅通过拥有他们的电子邮件地址**开始与某人的聊天**或发送**邀请进行对话**。此外，可以**创建一个空间**，可以有任何名称（例如“Google支持”）并**邀请**成员加入。如果他们接受，他们可能会认为自己正在与Google支持进行对话：
|
||||
|
||||
<figure><img src="../../../images/image (6).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -86,14 +86,14 @@ gws-app-scripts.md
|
||||
|
||||
**Google** 允许创建可以 **代表用户与多个 Google 服务** 交互的应用：Gmail、Drive、GCP...
|
||||
|
||||
在创建一个 **代表其他用户操作** 的应用时，开发者需要在 **GCP 内创建一个 OAuth 应用** 并指明该应用需要访问用户数据的范围（权限）。\
|
||||
在创建一个 **代表其他用户操作** 的应用时，开发者需要在 **GCP 中创建一个 OAuth 应用** 并指明该应用需要访问用户数据的范围（权限）。\
|
||||
当 **用户** 想要 **使用** 该 **应用** 时，他们将被 **提示** **接受** 该应用将访问其在范围中指定的数据。
|
||||
|
||||
这是一种非常诱人的方式来 **钓鱼** 非技术用户使用 **访问敏感信息的应用**，因为他们可能不理解后果。然而，在组织账户中，有方法可以防止这种情况发生。
|
||||
|
||||
### 未验证应用提示
|
||||
|
||||
正如前面提到的，Google 始终会向用户 **提示接受** 他们代表应用授予的权限。然而，如果该应用被认为是 **危险的**，Google 将 **首先** 显示一个 **提示**，指示它是 **危险的**，并 **使用户更难** 授予该应用权限。
|
||||
如前所述，Google 始终会向用户 **提示接受** 他们代表应用授予的权限。然而，如果该应用被认为是 **危险的**，Google 将 **首先** 显示一个 **提示**，指示它是 **危险的**，并 **使用户更难** 授予该应用权限。
|
||||
|
||||
此提示出现在以下应用中：
|
||||
|
||||
@@ -104,7 +104,7 @@ gws-app-scripts.md
|
||||
|
||||
[**这里**](https://developers.google.com/identity/protocols/oauth2/scopes) 您可以找到所有 Google OAuth 范围的列表。
|
||||
|
||||
- **cloud-platform**：查看和管理您在 **Google Cloud Platform** 服务中的数据。您可以在 GCP 中模拟用户。
|
||||
- **cloud-platform**：查看和管理您在 **Google Cloud Platform** 服务中的数据。您可以在 GCP 中冒充用户。
|
||||
- **admin.directory.user.readonly**：查看和下载您组织的 GSuite 目录。获取所有用户的姓名、电话、日历 URL。
|
||||
|
||||
### 创建 OAuth 应用
|
||||
@@ -128,7 +128,7 @@ gws-app-scripts.md
|
||||
- 您可以在两者中设置类似 **`http://localhost:8000/callback`** 的内容进行测试
|
||||
4. 获取您的应用 **凭据**
|
||||
|
||||
最后，让我们 **运行一个将使用 OAuth 应用凭据的 Web 应用**。您可以在 [https://github.com/carlospolop/gcp_oauth_phishing_example](https://github.com/carlospolop/gcp_oauth_phishing_example) 找到一个示例。
|
||||
最后，让我们 **运行一个将使用 OAuth 应用凭据的 Web 应用**。您可以在 [https://github.com/carlospolop/gcp_oauth_phishing_example](https://github.com/carlospolop/gcp_oauth_phishing_example) 中找到示例。
|
||||
```bash
|
||||
git clone ttps://github.com/carlospolop/gcp_oauth_phishing_example
|
||||
cd gcp_oauth_phishing_example
|
||||
@@ -142,7 +142,7 @@ python3 app.py --client-id "<client_id>" --client-secret "<client_secret>"
|
||||
该应用程序将显示 **访问和刷新令牌**，可以轻松使用。有关 **如何使用这些令牌的更多信息，请查看**：
|
||||
|
||||
{{#ref}}
|
||||
../../gcp-security/gcp-persistence/gcp-non-svc-persistance.md
|
||||
../../gcp-security/gcp-persistence/gcp-non-svc-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
#### 使用 `glcoud`
|
||||
|
||||
Reference in New Issue
Block a user