Translated ['', 'src/pentesting-cloud/gcp-security/gcp-privilege-escalat

This commit is contained in:
Translator
2025-11-15 11:48:24 +00:00
parent 6a3219aecb
commit 634b5a7ba0
2 changed files with 51 additions and 11 deletions
@@ -1,25 +1,42 @@
# GCP - 通用权限提升
# GCP - Generic Permissions Privesc
{{#include ../../../banners/hacktricks-training.md}}
## 通用有趣权限
## 通用有趣权限
### \*.setIamPolicy
如果您拥有一个在资源中具有 **`setIamPolicy`** 权限的用户,您可以 **在该资源中提升权限**,因为您将能够更改该资源的 IAM 策略并给予自己更多的权限。\
此权限还可以允许 **提升到其他主体**,如果资源允许执行代码并且不需要 iam.ServiceAccounts.actAs。
If you owns a user that has the **`setIamPolicy`** permission in a resource you can **escalate privileges in that resource** because you will be able to change the IAM policy of that resource and give you more privileges over it.\
如果你拥有一个在某个资源上具有 **`setIamPolicy`** 权限的用户,你可以在该资源上 escalate privileges in that resource,因为你可以更改该资源的 IAM 策略并授予自己对此资源的更多权限。\
This permission can also allow to **escalate to other principals** if the resource allow to execute code and the `iam.ServiceAccounts.actAs` is not necessary.
如果该资源允许执行代码且不需要 `iam.ServiceAccounts.actAs`,此权限还可能允许你 **escalate to other principals**
- _cloudfunctions.functions.setIamPolicy_
- 修改 Cloud Function 的策略以允许调用它。
- 修改 Cloud Function 的策略以允许你自己调用它。
有数十种资源类型具有这种权限,您可以在 [https://cloud.google.com/iam/docs/permissions-reference](https://cloud.google.com/iam/docs/permissions-reference) 中搜索 setIamPolicy 找到它们。
There are tens of resources types with this kind of permission, you can find all of them in [https://cloud.google.com/iam/docs/permissions-reference](https://cloud.google.com/iam/docs/permissions-reference) searching for setIamPolicy.
有数十种资源类型具有此类权限,你可以在 [https://cloud.google.com/iam/docs/permissions-reference](https://cloud.google.com/iam/docs/permissions-reference) 中搜索 setIamPolicy 来查找所有这些资源。
### \*.create, \*.update
这些权限可以非常有用,以尝试通过 **创建一个新资源或更新一个新资源** 来提升权限。如果您还拥有对服务帐户的 **iam.serviceAccounts.actAs** 权限,并且您拥有 .create/.update 权限的资源可以附加服务帐户,这些权限特别有用。
These permissions can be very useful to try to escalate privileges in resources by **creating a new one or updating a new one**.
这些权限在通过**创建新资源或更新现有资源**来尝试 escalate privileges in resources 时非常有用。
These can of permissions are specially useful if you also has the permission **iam.serviceAccounts.actAs** over a Service Account and the resource you have .create/.update over can attach a service account.
如果你还对某个 Service Account 拥有 **iam.serviceAccounts.actAs** 权限,且你拥有 .create/.update 权限的资源可以附加服务账户,这类权限尤其有用。
### \*ServiceAccount\*
此权限通常允许您 **访问或修改某个资源中的服务帐户**(例如:compute.instances.setServiceAccount)。这 **可能导致权限提升** 向量,但这将取决于每种情况。
This permission will usually let you **access or modify a Service Account in some resource** (e.g.: compute.instances.setServiceAccount). This **could lead to a privilege escalation** vector, but it will depend on each case.
该权限通常允许你**访问或修改某个资源中的 Service Account**(例如:compute.instances.setServiceAccount)。这可能导致 privilege escalation 向量,但要视具体情况而定。
### iam.ServiceAccounts.actAs
This permission will let you attach a Service Account to a resource that supports it (e.g.: Compute Engine VM, Cloud Function, Cloud Run, etc).\
该权限允许你将一个 Service Account 附加到支持该功能的资源(例如:Compute Engine VM、Cloud Function、Cloud Run 等)。\
If you can attach a Service Account that has more privileges than your user to a resource that can execute code, you will be able to escalate your privileges by executing code with that Service Account.
如果你能够将一个权限高于你的用户的 Service Account 附加到能够执行代码的资源上,你就可以通过使用该 Service Account 执行代码来 escalate your privileges。
Search in Cloud Hacktricks for `iam.ServiceAccounts.actAs` to find several examples of how to escalate privileges with this permission.
在 Cloud Hacktricks 中搜索 `iam.ServiceAccounts.actAs`,可以找到多个如何使用此权限来 escalate privileges 的示例。
{{#include ../../../banners/hacktricks-training.md}}
@@ -6,7 +6,7 @@
### `orgpolicy.policy.set`
利用 **orgpolicy.policy.set** 的攻击者可以操纵组织政策,这将允许他移除某些限制,从而阻碍特定操作。例如,约束 **appengine.disableCodeDownload** 通常会阻止下载 App Engine 源代码。然而,通过使用 **orgpolicy.policy.set**,攻击者可以停用约束,从而获得下载源代码的权限,尽管它最初是受保护的。
利用 **orgpolicy.policy.set** 的攻击者可以操纵组织策略,从而移除阻碍特定操作的某些限制。例如,约束 **appengine.disableCodeDownload** 通常会阻止下载 App Engine 源代码。但是,通过使用 **orgpolicy.policy.set**,攻击者可以停用约束,从而获得下载源代码的权限,即使该源代码在最初是受保护的。
```bash
# Get info
gcloud resource-manager org-policies describe <org-policy> [--folder <id> | --organization <id> | --project <id>]
@@ -14,9 +14,32 @@ gcloud resource-manager org-policies describe <org-policy> [--folder <id> | --or
# Disable
gcloud resource-manager org-policies disable-enforce <org-policy> [--folder <id> | --organization <id> | --project <id>]
```
可以在 [这里](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/orgpolicy.policy.set.py) 找到此方法的 Python 脚本
用于此方法的 Python 脚本可在 [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/orgpolicy.policy.set.py) 找到。
## 参考文献
### `orgpolicy.policy.set`, `iam.serviceAccounts.actAs`
通常无法将来自不同项目的服务账号附加到资源,因为存在名为 **`iam.disableCrossProjectServiceAccountUsage`** 的策略约束会阻止此操作。
可以通过运行以下命令来验证此约束是否已启用:
```bash
gcloud resource-manager org-policies describe \
constraints/iam.disableCrossProjectServiceAccountUsage \
--project=<project-id> \
--effective
booleanPolicy:
enforced: true
constraint: constraints/iam.disableCrossProjectServiceAccountUsage
```
这会防止攻击者滥用权限 **`iam.serviceAccounts.actAs`** 去冒充来自其他项目的服务账户,在没有进一步基础设施权限(例如启动新的 VM)的情况下进行操作,从而导致权限提升。
然而,拥有 **`orgpolicy.policy.set`** 权限的攻击者可以通过禁用约束 **`iam.disableServiceAccountProjectWideAccess`** 来绕过此限制。这样攻击者就可以将来自其他项目的服务账户附加到自己项目的资源上,从而有效地提升其权限。
```bash
gcloud resource-manager org-policies disable-enforce \
iam.disableCrossProjectServiceAccountUsage \
--project=<project-id>
```
## 参考资料
- [https://rhinosecuritylabs.com/cloud-security/privilege-escalation-google-cloud-platform-part-2/](https://rhinosecuritylabs.com/cloud-security/privilege-escalation-google-cloud-platform-part-2/)