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

This commit is contained in:
Translator
2025-11-15 11:48:18 +00:00
parent 2816eeac1b
commit b895caaffe
2 changed files with 41 additions and 11 deletions

View File

@@ -1,25 +1,32 @@
# GCP - Generische Berechtigungen Privesc
# GCP - Generic Permissions Privesc
{{#include ../../../banners/hacktricks-training.md}}
## Generische interessante Berechtigungen
## Allgemein interessante Berechtigungen
### \*.setIamPolicy
Wenn Sie einen Benutzer besitzen, der die **`setIamPolicy`**-Berechtigung in einer Ressource hat, können Sie **die Berechtigungen in dieser Ressource eskalieren**, da Sie die IAM-Richtlinie dieser Ressource ändern und sich selbst mehr Berechtigungen gewähren können.\
Diese Berechtigung kann auch ermöglichen, **zu anderen Prinzipalen zu eskalieren**, wenn die Ressource das Ausführen von Code erlaubt und iam.ServiceAccounts.actAs nicht erforderlich ist.
Wenn du einen Nutzer besitzt, der die **`setIamPolicy`**-Berechtigung für eine Ressource hat, kannst du **escalate privileges in that resource**, weil du die IAM-Richtlinie dieser Ressource ändern und dir dadurch mehr Rechte verschaffen kannst.\
Diese Berechtigung kann auch erlauben, **escalate to other principals**, wenn die Ressource das Ausführen von Code erlaubt und `iam.ServiceAccounts.actAs` nicht notwendig ist.
- _cloudfunctions.functions.setIamPolicy_
- Ändern Sie die Richtlinie einer Cloud-Funktion, um sich selbst zu erlauben, sie aufzurufen.
- Ändere die Richtlinie einer Cloud Function, um dir selbst das Aufrufen zu erlauben.
Es gibt Dutzende von Ressourcentypen mit dieser Art von Berechtigung, Sie können alle von ihnen in [https://cloud.google.com/iam/docs/permissions-reference](https://cloud.google.com/iam/docs/permissions-reference) finden, indem Sie nach setIamPolicy suchen.
Es gibt Dutzende von Ressourcentypen mit dieser Art von Berechtigung; du kannst alle in [https://cloud.google.com/iam/docs/permissions-reference](https://cloud.google.com/iam/docs/permissions-reference) finden, indem du nach setIamPolicy suchst.
### \*.create, \*.update
Diese Berechtigungen können sehr nützlich sein, um zu versuchen, Berechtigungen in Ressourcen zu eskalieren, indem Sie **eine neue erstellen oder eine neue aktualisieren**. Diese Art von Berechtigungen ist besonders nützlich, wenn Sie auch die Berechtigung **iam.serviceAccounts.actAs** über ein Dienstkonto haben und die Ressource, über die Sie .create/.update verfügen, ein Dienstkonto anhängen kann.
Diese Berechtigungen können sehr nützlich sein, um zu versuchen, in Ressourcen Privilegien zu eskalieren, indem du eine neue Ressource erstellst oder eine bestehende aktualisierst. Diese Arten von Berechtigungen sind besonders nützlich, wenn du außerdem die Berechtigung **iam.serviceAccounts.actAs** für ein Service Account hast und die Ressource, über die du .create/.update-Rechte besitzt, ein Service Account anhängen kann.
### \*ServiceAccount\*
Diese Berechtigung ermöglicht es Ihnen normalerweise, **auf ein Dienstkonto in einer Ressource zuzugreifen oder es zu ändern** (z.B.: compute.instances.setServiceAccount). Dies **könnte zu einem Vektor für eine Berechtigungseskalation führen**, hängt jedoch von jedem Einzelfall ab.
Diese Berechtigung erlaubt dir in der Regel, auf ein Service Account in einer Ressource zuzugreifen oder es zu ändern (z. B.: compute.instances.setServiceAccount). Dies **could lead to a privilege escalation**, hängt aber vom Einzelfall ab.
### iam.ServiceAccounts.actAs
Diese Berechtigung erlaubt es dir, ein Service Account an eine Ressource anzuhängen, die dies unterstützt (z. B.: Compute Engine VM, Cloud Function, Cloud Run, etc).\
Wenn du ein Service Account anhängen kannst, das mehr Rechte hat als dein Nutzer, an eine Ressource, die Code ausführen kann, wirst du in der Lage sein, escalate your privileges, indem du Code mit diesem Service Account ausführst.
Suche in Cloud Hacktricks nach `iam.ServiceAccounts.actAs`, um mehrere Beispiele zu finden, wie man mit dieser Berechtigung escalate privileges erreicht.
{{#include ../../../banners/hacktricks-training.md}}

View File

@@ -6,7 +6,7 @@
### `orgpolicy.policy.set`
Ein Angreifer, der **orgpolicy.policy.set** ausnutzt, kann organisatorische Richtlinien manipulieren, was ihm ermöglicht, bestimmte Einschränkungen zu entfernen, die spezifische Operationen behindern. Zum Beispiel blockiert die Einschränkung **appengine.disableCodeDownload** normalerweise das Herunterladen des App Engine Quellcodes. Durch die Verwendung von **orgpolicy.policy.set** kann ein Angreifer jedoch diese Einschränkung deaktivieren und somit Zugriff auf den Quellcode erhalten, obwohl dieser ursprünglich geschützt war.
Ein Angreifer, der **orgpolicy.policy.set** nutzt, kann Organisationsrichtlinien manipulieren, wodurch er bestimmte Einschränkungen aufheben kann, die bestimmte Aktionen verhindern. Zum Beispiel verhindert die Einschränkung **appengine.disableCodeDownload** üblicherweise das Herunterladen des App Engine-Quellcodes. Durch die Verwendung von **orgpolicy.policy.set** kann ein Angreifer diese Einschränkung jedoch deaktivieren und so Zugriff erhalten, um den Quellcode herunterzuladen, obwohl er ursprünglich geschützt war.
```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>]
```
Ein Python-Skript für diese Methode kann [hier](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/orgpolicy.policy.set.py) gefunden werden.
Ein Python-Skript für diese Methode befindet sich [hier](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/orgpolicy.policy.set.py).
## Referenzen
### `orgpolicy.policy.set`, `iam.serviceAccounts.actAs`
Normalerweise ist es nicht möglich, ein Servicekonto aus einem anderen Projekt an eine Ressource anzuhängen, da eine Richtlinienbeschränkung mit dem Namen **`iam.disableCrossProjectServiceAccountUsage`** durchgesetzt wird, die diese Aktion verhindert.
Es ist möglich zu überprüfen, ob diese Beschränkung durchgesetzt wird, indem man den folgenden Befehl ausführt:
```bash
gcloud resource-manager org-policies describe \
constraints/iam.disableCrossProjectServiceAccountUsage \
--project=<project-id> \
--effective
booleanPolicy:
enforced: true
constraint: constraints/iam.disableCrossProjectServiceAccountUsage
```
Dies verhindert, dass ein Angreifer die Berechtigung **`iam.serviceAccounts.actAs`** missbraucht, um sich als Servicekonto aus einem anderen Projekt auszugeben, ohne die dafür sonst erforderlichen zusätzlichen Infrastruktur-Berechtigungen (z. B. zum Starten einer neuen VM) zu besitzen, was zu einer Privilegieneskalation führen könnte.
Allerdings kann ein Angreifer mit den Rechten **`orgpolicy.policy.set`** diese Einschränkung umgehen, indem er die Constraint **`iam.disableServiceAccountProjectWideAccess`** deaktiviert. Dadurch kann der Angreifer ein Servicekonto aus einem anderen Projekt an eine Ressource in seinem eigenen Projekt anhängen und so effektiv seine Privilegien eskalieren.
```bash
gcloud resource-manager org-policies disable-enforce \
iam.disableCrossProjectServiceAccountUsage \
--project=<project-id>
```
## Quellen
- [https://rhinosecuritylabs.com/cloud-security/privilege-escalation-google-cloud-platform-part-2/](https://rhinosecuritylabs.com/cloud-security/privilege-escalation-google-cloud-platform-part-2/)