GCP - Élévation de privilèges

Reading time: 6 minutes

tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

Vérifiez les plans d'abonnement !
Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez-nous sur Twitter 🐦 @hacktricks_live.
Partagez des astuces de hacking en soumettant des PR au HackTricks et HackTricks Cloud dépôts github.

Introduction à l'élévation de privilèges GCP

GCP, comme tout autre cloud, a des principes : utilisateurs, groupes et comptes de service, et certaines ressources comme compute engine, cloud functions…
Ensuite, via des rôles, les permissions sont accordées à ces principes sur les ressources. C'est ainsi que l'on spécifie les permissions qu'un principe a sur une ressource dans GCP.
Il existe certaines permissions qui permettront à un utilisateur de obtenir encore plus de permissions sur la ressource ou des ressources tierces, et c'est ce qu'on appelle l'élévation de privilèges (également, l'exploitation des vulnérabilités pour obtenir plus de permissions).

Par conséquent, je voudrais séparer les techniques d'élévation de privilèges GCP en 2 groupes :

Privesc à un principe : Cela vous permettra de imiter un autre principe, et donc d'agir comme lui avec toutes ses permissions. par ex. : Abuser de getAccessToken pour imiter un compte de service.
Privesc sur la ressource : Cela vous permettra de obtenir plus de permissions sur la ressource spécifique. par ex. : vous pouvez abuser de la permission setIamPolicy sur cloudfunctions pour vous permettre de déclencher la fonction.
Notez que certaines permissions de ressources vous permettront également d'attacher un compte de service arbitraire à la ressource. Cela signifie que vous pourrez lancer une ressource avec un SA, entrer dans la ressource, et voler le jeton SA. Par conséquent, cela permettra d'escalader à un principe via une élévation de ressource. Cela s'est produit dans plusieurs ressources auparavant, mais maintenant c'est moins fréquent (mais cela peut encore arriver).

Évidemment, les techniques d'élévation de privilèges les plus intéressantes sont celles du deuxième groupe car elles vous permettront de obtenir plus de privilèges en dehors des ressources sur lesquelles vous avez déjà certains privilèges. Cependant, notez que l'escalade dans les ressources peut également vous donner accès à des informations sensibles ou même à d'autres principes (peut-être en lisant un secret qui contient un jeton d'un SA).

warning

Il est également important de noter qu'dans GCP, les comptes de service sont à la fois des principes et des permissions, donc escalader les privilèges dans un SA vous permettra également de l'imiter.

note

Les permissions entre parenthèses indiquent les permissions nécessaires pour exploiter la vulnérabilité avec gcloud. Celles-ci peuvent ne pas être nécessaires si vous l'exploitez via l'API.

Permissions pour la méthodologie d'élévation de privilèges

Voici comment je teste des permissions spécifiques pour effectuer des actions spécifiques dans GCP.

Téléchargez le dépôt github https://github.com/carlospolop/gcp_privesc_scripts
Ajoutez dans tests/ le nouveau script

Contournement des portées d'accès

Les jetons de SA divulgués par le service de métadonnées GCP ont des portées d'accès. Ce sont des restrictions sur les permissions que le jeton possède. Par exemple, si le jeton a la portée https://www.googleapis.com/auth/cloud-platform, il aura un accès complet à tous les services GCP. Cependant, si le jeton a la portée https://www.googleapis.com/auth/cloud-platform.read-only, il n'aura qu'un accès en lecture seule à tous les services GCP même si le SA a plus de permissions dans IAM.

Il n'y a pas de moyen direct de contourner ces permissions, mais vous pourriez toujours essayer de rechercher de nouvelles identifiants dans l'hôte compromis, trouver la clé de service pour générer un jeton OAuth sans restriction ou passer à une VM différente moins restreinte.

Lorsque les portées d'accès sont utilisées, le jeton OAuth qui est généré pour l'instance de calcul (VM) aura une limitation de portée incluse. Cependant, vous pourriez être en mesure de contourner cette limitation et d'exploiter les permissions que le compte compromis possède.

Le meilleur moyen de contourner cette restriction est soit de trouver de nouvelles identifiants dans l'hôte compromis, de trouver la clé de service pour générer un jeton OAuth sans restriction ou de compromettre une VM différente avec un SA moins restreint.

Vérifiez le SA avec des clés générées avec :

bash

for i in $(gcloud iam service-accounts list --format="table[no-heading](email)"); do
echo "Looking for keys for $i:"
gcloud iam service-accounts keys list --iam-account $i
done

Techniques d'escalade de privilèges

La façon d'escalader vos privilèges dans AWS est d'avoir suffisamment de permissions pour pouvoir, d'une manière ou d'une autre, accéder aux privilèges d'autres comptes de service/utilisateurs/groupes. Enchaînant les escalades jusqu'à ce que vous ayez un accès administrateur sur l'organisation.

warning

GCP a des centaines (si ce n'est des milliers) de permissions qui peuvent être accordées à une entité. Dans ce livre, vous pouvez trouver toutes les permissions que je connais que vous pouvez abuser pour escalader des privilèges, mais si vous connaissez un chemin non mentionné ici, merci de le partager.

Les sous-pages de cette section sont ordonnées par services. Vous pouvez trouver sur chaque service différentes façons d'escalader des privilèges sur les services.

Abuser de GCP pour escalader des privilèges localement

Si vous êtes à l'intérieur d'une machine dans GCP, vous pourriez être en mesure d'abuser des permissions pour escalader des privilèges même localement :

GCP - local privilege escalation ssh pivoting

Références

tip