GCP - Privilege Escalation
Introduction à l'Élévation de Privilèges GCP
GCP, comme tout autre cloud, a des principaux : utilisateurs, groupes et comptes de service, et certaines ressources comme le moteur de calcul, les fonctions cloud… Ensuite, via des rôles, les permissions sont accordées à ces principaux sur les ressources. C'est ainsi que l'on spécifie les permissions qu'un principal a sur une ressource dans GCP. Il existe certaines permissions qui permettront à un utilisateur de détenir 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 principal : Cela vous permettra de imiter un autre principal, et donc d'agir comme lui avec toutes ses permissions. par exemple : Abuser de getAccessToken pour imiter un compte de service.
Privesc sur la ressource : Cela vous permettra de détenir plus de permissions sur la ressource spécifique. par exemple : vous pouvez abuser de la permission setIamPolicy sur les 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 principal 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 détenir 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 principaux (peut-être en lisant un secret qui contient un jeton d'un SA).
Il est également important de noter qu'en GCP, les Comptes de Service sont à la fois des principaux et des permissions, donc escalader des privilèges dans un SA vous permettra également de l'imiter.
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 chercher 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 :
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'à obtenir un accès administrateur sur l'organisation.
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 classées par services. Vous pouvez trouver sur chaque service différentes manières 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 pivotingRéférences
Last updated
