GCP <–> Workspace Pivoting

Tip

学习和实践 AWS 黑客技术：HackTricks Training AWS Red Team Expert (ARTE)
学习和实践 GCP 黑客技术：HackTricks Training GCP Red Team Expert (GRTE) 学习和实践 Azure 黑客技术：HackTricks Training Azure Red Team Expert (AzRTE)

支持 HackTricks

查看 订阅计划!

加入 💬 Discord 群组 或 Telegram 群组 或在 Twitter 🐦 上关注我们 @hacktricks_live.

通过向 HackTricks 和 HackTricks Cloud GitHub 仓库提交 PR 来分享黑客技巧。

从 GCP 到 GWS

域范围委托基础

Google Workspace 的域范围委托允许一个身份对象，无论是来自 Google Workspace Marketplace 的 外部应用 还是内部的 GCP 服务账户，代表用户访问 Workspace 中的数据。

Note

这基本上意味着，组织内 GCP 项目中的 服务账户 可能能够 冒充同一组织的 Workspace 用户（甚至是来自不同组织的用户）。

有关此如何具体工作的更多信息，请查看：

GCP - Understanding Domain-Wide Delegation

如果攻击者 获得了对 GCP 的某些访问权限 并且 知道公司中一个有效的 Workspace 用户邮箱（最好是 超级管理员），他可以 枚举他有访问权限的所有项目，枚举项目的所有服务账户，检查他 可以访问的服务账户，并 对每个可以冒充的服务账户重复 所有这些步骤。
通过 他有访问权限的所有服务账户的列表 和 Workspace 邮箱的列表，攻击者可以尝试 用每个服务账户冒充用户。

Caution

请注意，在配置域范围委托时不需要任何 Workspace 用户，因此只需知道 一个有效的用户就足够并且是冒充所需的。
然而，被冒充用户的权限将被使用，因此如果是超级管理员，您将能够访问所有内容。如果没有任何访问权限，这将毫无用处。

GCP 生成委托令牌

这个简单的脚本将 生成一个作为被委托用户的 OAuth 令牌，您可以使用它来访问其他 Google API，无论是否使用 gcloud：

# Impersonate indicated user
python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-key-file>

# 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

基于以下 DeleFriend 工具，但增加了一些功能，如枚举域、驱动、gmail、日历并执行其他操作。

DeleFriend

这是一个可以执行攻击的工具，遵循以下步骤：

使用 Resource Manager API 枚举 GCP 项目。
遍历每个项目资源，并 枚举 GCP 服务账户资源，以获取初始 IAM 用户的访问权限，使用 GetIAMPolicy。
遍历 每个服务账户角色，并查找在目标服务账户资源上具有 serviceAccountKeys.create 权限的内置、基本和自定义角色。需要注意的是，编辑者角色本身就拥有此权限。
为每个在 IAM 策略中找到相关权限的服务账户资源创建一个 新的 KEY_ALG_RSA_2048 私钥。
遍历 每个新服务账户并为其创建一个 JWT 对象，该对象由 SA 私钥凭据和 OAuth 范围组成。创建新 JWT 对象的过程将 遍历所有现有的 OAuth 范围组合，以便找到所有的委托可能性。列表 oauth_scopes.txt 会更新所有我们发现与滥用 Workspace 身份相关的 OAuth 范围。
_make_authorization_grant_assertion 方法揭示了声明一个 目标工作区用户（称为 subject）以在 DWD 下生成 JWT 的必要性。虽然这似乎需要一个特定用户，但重要的是要意识到 DWD 影响域内的每个身份。因此，为 任何域用户 创建 JWT 会影响该域中的所有身份，这与我们的组合枚举检查一致。简单来说，一个有效的 Workspace 用户就足够继续前进。
该用户可以在 DeleFriend 的 config.yaml 文件中定义。如果目标工作区用户尚不明确，该工具通过扫描在 GCP 项目上具有角色的域用户来自动识别有效的工作区用户。需要再次注意的是，JWT 是特定于域的，并不是为每个用户生成的；因此，自动过程针对每个域的单一唯一身份。
枚举并为每个 JWT 创建一个新的承载访问令牌，并通过 tokeninfo API 验证该令牌。

Gitlab’s Python script

Gitlab 创建了这个 Python 脚本，可以做两件事 - 列出用户目录并创建一个新的管理账户，同时指明一个包含 SA 凭据和要模拟的用户的 json。以下是如何使用它的说明：

# Install requirements
pip install --upgrade --user oauth2client

# Validate access only
./gcp_delegation.py --keyfile ./credentials.json \
--impersonate steve.admin@target-org.com \
--domain target-org.com

# List the directory
./gcp_delegation.py --keyfile ./credentials.json \
--impersonate steve.admin@target-org.com \
--domain target-org.com \
--list

# Create a new admin account
./gcp_delegation.py --keyfile ./credentials.json \
--impersonate steve.admin@target-org.com \
--domain target-org.com \
--account pwned

创建新的委托（持久性）

可以在 https://admin.google.com/u/1/ac/owl/domainwidedelegation** 中** 检查域范围委托。

具有 在 GCP 项目中创建服务账户 和 GWS 超级管理员权限的攻击者可以创建新的委托，允许服务账户冒充某些 GWS 用户：

生成新的服务账户及相应的密钥对： 在 GCP 上，可以通过控制台交互式生成新的服务账户资源，或使用直接 API 调用和 CLI 工具以编程方式生成。这需要 角色 iam.serviceAccountAdmin 或任何具备 iam.serviceAccounts.create 权限的自定义角色。服务账户创建后，我们将继续生成 相关的密钥对（iam.serviceAccountKeys.create 权限）。
创建新的委托： 重要的是要理解，只有超级管理员角色具备在 Google Workspace 中设置全局域范围委托的能力，并且域范围委托 不能以编程方式设置， 只能通过 Google Workspace 控制台 手动创建和调整。

规则的创建可以在页面 API 控制 → 管理 Google Workspace 管理控制台中的域范围委托 下找到。

附加 OAuth 范围权限： 在配置新的委托时，Google 仅要求 2 个参数，即客户端 ID，这是 GCP 服务账户 资源的 OAuth ID，以及定义委托所需 API 调用的 OAuth 范围。

完整的 OAuth 范围列表 可以在这里找到，但这里有一个推荐：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

代表目标身份进行操作： 此时，我们在 GWS 中有一个功能正常的委托对象。现在，使用 GCP 服务账户私钥，我们可以执行 API 调用（在 OAuth 范围参数中定义的范围内）来触发它，并 代表 Google Workspace 中存在的任何身份进行操作。正如我们所了解到的，服务账户将根据其需求和对 REST API 应用程序的权限生成访问令牌。

请查看 上一部分 以获取一些 使用此委托的工具。

跨组织委托

OAuth SA ID 是全局的，可以用于 跨组织委托。没有实施任何限制来防止跨全球委托。简单来说，来自不同 GCP 组织的服务账户可以用于在其他 Workspace 组织上配置域范围委托。这将导致 只需对 Workspace 的超级管理员访问权限，而不需要对同一 GCP 账户的访问权限，因为对手可以在其个人控制的 GCP 账户上创建服务账户和私钥。

创建项目以枚举 Workspace

默认情况下，Workspace 用户具有 创建新项目 的权限，当创建新项目时，创建者获得所有者角色。

因此，用户可以 创建一个项目，启用其新项目中的 API 以枚举 Workspace，并尝试枚举它。

Caution

为了使用户能够枚举 Workspace，他还需要足够的 Workspace 权限（并非每个用户都能枚举目录）。

# Create project
gcloud projects create <uniq-projec-name> --name=proj-name
# Set project
gcloud config set project <uniq-projec-name>
# Enable svcs
gcloud services enable admin.googleapis.com
gcloud services enable cloudidentity.googleapis.com
# Get org ID
gcloud organizations list
# Get currents email user groups (at least you can check the groups and members of the groups you belong to)
gcloud identity groups memberships search-transitive-groups --member-email <email> --labels=cloudidentity.googleapis.com/groups.discussion_forum
gcloud identity groups memberships list --group-email=g<group-email>

# FROM HERE THE USER NEEDS TO HAVE ENOUGH WORKSPACE ACCESS
gcloud beta identity groups preview --customer <org-cust-id>

滥用 Gcloud 凭据

您可以在以下位置找到有关 gcloud 登录流程的更多信息：

GCP - Token Persistence

如上所述，gcloud 可以请求范围 https://www.googleapis.com/auth/drive，这将允许用户访问该用户的驱动器。
作为攻击者，如果您已物理入侵用户的计算机，并且 用户仍然登录 其帐户，您可以通过生成访问驱动器的令牌进行登录：

gcloud auth login --enable-gdrive-access

如果攻击者入侵了用户的计算机，他还可以修改文件 google-cloud-sdk/lib/googlecloudsdk/core/config.py，并在 CLOUDSDK_SCOPES 中添加范围 'https://www.googleapis.com/auth/drive'：

Warning

因此，下次用户登录时，他将创建一个 具有访问 drive 的令牌，攻击者可以利用该令牌访问 drive。显然，浏览器会指示生成的令牌将具有访问 drive 的权限，但由于用户将自己称为 gcloud auth login，他可能 不会怀疑任何事情。

列出 drive 文件： curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://www.googleapis.com/drive/v3/files"

https://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover