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

src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-misc-perms-privesc.md

@@ -1,25 +1,32 @@
-# GCP - Privilèges Généraux Privesc
+# GCP - Permissions génériques Privesc
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-## Privilèges Intéressants Généraux
+## Permissions génériques intéressantes
 
 ### \*.setIamPolicy
 
-Si vous possédez un utilisateur qui a la permission **`setIamPolicy`** dans une ressource, vous pouvez **escalader les privilèges dans cette ressource** car vous pourrez changer la politique IAM de cette ressource et vous donner plus de privilèges dessus.\
-Cette permission peut également permettre de **s'escalader vers d'autres principaux** si la ressource permet d'exécuter du code et que iam.ServiceAccounts.actAs n'est pas nécessaire.
+Si un utilisateur que vous contrôlez possède la permission **`setIamPolicy`** sur une ressource, vous pouvez **escalader les privilèges sur cette ressource** car vous pourrez modifier la politique IAM de cette ressource et vous accorder davantage de privilèges.\
+Cette permission peut aussi permettre d'**escalader vers d'autres entités (principals)** si la ressource permet d'exécuter du code et que `iam.ServiceAccounts.actAs` n'est pas nécessaire.
 
 - _cloudfunctions.functions.setIamPolicy_
-- Modifiez la politique d'une fonction Cloud pour vous permettre de l'invoquer.
+- Modifier la politique d'une Cloud Function pour vous permettre de l'invoquer.
 
-Il existe des dizaines de types de ressources avec ce type de permission, vous pouvez les trouver tous sur [https://cloud.google.com/iam/docs/permissions-reference](https://cloud.google.com/iam/docs/permissions-reference) en recherchant setIamPolicy.
+Il existe des dizaines de types de ressources avec ce genre de permission ; vous pouvez tous les trouver sur [https://cloud.google.com/iam/docs/permissions-reference](https://cloud.google.com/iam/docs/permissions-reference) en recherchant setIamPolicy.
 
 ### \*.create, \*.update
 
-Ces permissions peuvent être très utiles pour essayer d'escalader les privilèges dans les ressources en **créant une nouvelle ou en mettant à jour une nouvelle**. Ce type de permissions est particulièrement utile si vous avez également la permission **iam.serviceAccounts.actAs** sur un compte de service et que la ressource sur laquelle vous avez .create/.update peut attacher un compte de service.
+Ces permissions peuvent être très utiles pour tenter d'escalader des privilèges sur des ressources en **créant une nouvelle ressource ou en mettant à jour une ressource existante**. Ce type de permissions est particulièrement utile si vous avez aussi la permission **iam.serviceAccounts.actAs** sur un Service Account et que la ressource sur laquelle vous avez .create/.update peut attacher un Service Account.
 
 ### \*ServiceAccount\*
 
-Cette permission vous permettra généralement **d'accéder ou de modifier un compte de service dans une ressource** (par exemple : compute.instances.setServiceAccount). Cela **pourrait conduire à un vecteur d'escalade de privilèges**, mais cela dépendra de chaque cas.
+Cette permission vous permettra généralement de **accéder ou modifier un Service Account dans une ressource** (par ex. : compute.instances.setServiceAccount). Cela **pourrait conduire à un vecteur d'escalade de privilèges**, mais cela dépendra de chaque cas.
+
+### iam.ServiceAccounts.actAs
+
+Cette permission vous permettra d'attacher un Service Account à une ressource qui le prend en charge (par ex. : Compute Engine VM, Cloud Function, Cloud Run, etc).\
+Si vous pouvez attacher un Service Account qui a plus de privilèges que votre utilisateur à une ressource capable d'exécuter du code, vous pourrez escalader vos privilèges en exécutant du code avec ce Service Account.
+
+Cherchez dans Cloud Hacktricks `iam.ServiceAccounts.actAs` pour trouver plusieurs exemples d'escalade de privilèges avec cette permission.
 
 {{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-orgpolicy-privesc.md

@@ -6,7 +6,7 @@
 
 ### `orgpolicy.policy.set`
 
-Un attaquant utilisant **orgpolicy.policy.set** peut manipuler les politiques organisationnelles, ce qui lui permettra de supprimer certaines restrictions entravant des opérations spécifiques. Par exemple, la contrainte **appengine.disableCodeDownload** bloque généralement le téléchargement du code source d'App Engine. Cependant, en utilisant **orgpolicy.policy.set**, un attaquant peut désactiver cette contrainte, lui permettant ainsi d'accéder au téléchargement du code source, malgré le fait qu'il soit initialement protégé.
+Un attaquant exploitant **orgpolicy.policy.set** peut manipuler les politiques organisationnelles, ce qui lui permettra de supprimer certaines restrictions empêchant certaines opérations. Par exemple, la contrainte **appengine.disableCodeDownload** bloque habituellement le téléchargement du code source d'App Engine. Cependant, en utilisant **orgpolicy.policy.set**, un attaquant peut désactiver cette contrainte, obtenant ainsi l'accès pour télécharger le code source, malgré sa protection initiale.
 ```bash
 # Get info
 gcloud resource-manager org-policies describe <org-policy> [--folder <id> | --organization <id> | --project <id>]
@@ -14,8 +14,31 @@ 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>]
 ```
-Un script python pour cette méthode peut être trouvé [ici](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/orgpolicy.policy.set.py).
+Un script Python pour cette méthode est disponible [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/orgpolicy.policy.set.py).
 
+### `orgpolicy.policy.set`, `iam.serviceAccounts.actAs`
+
+Habituellement, il n'est pas possible d'attacher un service account d'un autre projet à une ressource, car une contrainte de policy appliquée nommée **`iam.disableCrossProjectServiceAccountUsage`** empêche cette action.
+
+Il est possible de vérifier si cette contrainte est appliquée en exécutant la commande suivante :
+```bash
+gcloud resource-manager org-policies describe \
+constraints/iam.disableCrossProjectServiceAccountUsage \
+--project=<project-id> \
+--effective
+
+booleanPolicy:
+enforced: true
+constraint: constraints/iam.disableCrossProjectServiceAccountUsage
+```
+Cela empêche un attaquant d'abuser de la permission **`iam.serviceAccounts.actAs`** pour se faire passer pour un service account d'un autre projet sans disposer des permissions d'infrastructure supplémentaires nécessaires pour démarrer une nouvelle VM, par exemple, ce qui pourrait conduire à une privilege escalation.
+
+Cependant, un attaquant disposant de la permission **`orgpolicy.policy.set`** peut contourner cette restriction en désactivant la contrainte **`iam.disableServiceAccountProjectWideAccess`**. Cela permet à l'attaquant d'attacher un service account d'un autre projet à une ressource dans son propre projet, escaladant ainsi effectivement ses privilèges.
+```bash
+gcloud resource-manager org-policies disable-enforce \
+iam.disableCrossProjectServiceAccountUsage \
+--project=<project-id>
+```
 ## Références
 
 - [https://rhinosecuritylabs.com/cloud-security/privilege-escalation-google-cloud-platform-part-2/](https://rhinosecuritylabs.com/cloud-security/privilege-escalation-google-cloud-platform-part-2/)