Last updated
学习与实践 AWS 黑客技术：HackTricks 培训 AWS 红队专家 (ARTE) 学习与实践 GCP 黑客技术：HackTricks 培训 GCP 红队专家 (GRTE)
Google Workspace 的域范围委派允许身份对象，无论是来自 Google Workspace 市场的 外部应用 还是内部的 GCP 服务账户，代表用户访问 Workspace 中的数据。
这基本上意味着 GCP 项目 中的 服务账户 可能能够 冒充同一组织的 Workspace 用户（甚至是来自不同组织的用户）。
有关此如何具体工作的更多信息，请查看：
GCP - Understanding Domain-Wide Delegation如果攻击者 获得了对 GCP 的某些访问权限 并且 知道公司一个有效的 Workspace 用户邮箱（最好是 超级管理员），他可以 枚举他有访问权限的所有项目，枚举项目的所有服务账户，检查他 可以访问的服务账户，并 对每个他可以冒充的服务账户重复 所有这些步骤。 通过 他有访问权限的所有服务账户的列表 和 Workspace 邮箱的列表，攻击者可以尝试 用每个服务账户冒充用户。
请注意，在配置域范围委派时不需要任何 Workspace 用户，因此只需知道 一个有效的用户就足够并且是冒充所需的。 然而，将使用被冒充用户的权限，因此如果是超级管理员，您将能够访问所有内容。如果没有任何访问权限，这将毫无用处。
这个简单的脚本将 生成一个作为被委派用户的 OAuth 令牌，您可以使用它来访问其他 Google API，无论是否使用 gcloud：
这是一个可以执行以下步骤的工具：
使用资源管理器 API 枚举 GCP 项目。
迭代每个项目资源，并使用 GetIAMPolicy 枚举 GCP 服务账户资源，以确定初始 IAM 用户可以访问的资源。
迭代 每个服务账户角色，并查找在目标服务账户资源上具有 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 创建了 这个 Python 脚本，可以做两件事 - 列出用户目录并创建一个新的管理账户，同时指明一个包含 SA 凭据和要模拟的用户的 json。以下是使用方法：
可以在 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 用户 具有 创建新项目 的权限，当创建新项目时，创建者获得对其的所有者角色。
因此，用户可以 创建一个项目，启用 API 以在其新项目中枚举 Workspace，并尝试 枚举 它。
为了使用户能够枚举 Workspace，他还需要足够的 Workspace 权限（并非每个用户都能枚举目录）。
检查更多枚举信息：
GCP - IAM, Principals & Org Policies Enum您可以在以下位置找到有关 gcloud 登录流程的更多信息：
正如那里所解释的，gcloud 可以请求范围 https://www.googleapis.com/auth/drive，这将允许用户访问该用户的驱动器。
作为攻击者，如果您物理上入侵了用户的计算机，并且用户仍然登录其帐户，您可以通过生成一个访问驱动器的令牌来登录：
如果攻击者入侵了用户的计算机，他还可以修改文件 google-cloud-sdk/lib/googlecloudsdk/core/config.py，并在 CLOUDSDK_SCOPES 中添加范围 'https://www.googleapis.com/auth/drive'：
因此，下次用户登录时，他将创建一个 具有访问 drive 的令牌，攻击者可以利用该令牌访问 drive。显然，浏览器会指示生成的令牌将具有访问 drive 的权限，但由于用户会自己调用 gcloud auth login，他可能 不会怀疑任何事情。
要列出 drive 文件： curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://www.googleapis.com/drive/v3/files"
如果攻击者完全访问 GWS，他将能够访问具有 GCP 特权访问权限的组或用户，因此从 GWS 转移到 GCP 通常更“简单”，因为 GWS 中的用户对 GCP 具有高权限。
默认情况下，用户可以 自由加入组织的 Workspace 组，这些组 可能具有 GCP 权限（在 https://groups.google.com/ 中检查您的组）。
通过滥用 google groups privesc，您可能能够提升到具有某种 GCP 特权访问权限的组。
学习和实践 AWS 黑客技术：HackTricks Training AWS Red Team Expert (ARTE) 学习和实践 GCP 黑客技术： HackTricks Training GCP Red Team Expert (GRTE)
