GCP - Privilege Escalation
Introduction à l'élevation de privilèges GCP
GCP, comme tout autre cloud, a certains principes : utilisateurs, groupes et comptes de service, et quelques ressources comme les instances de calcul, les fonctions cloud... Ensuite, via les rôles, des autorisations sont accordées à ces principes sur les ressources. C'est la manière de spécifier les autorisations qu'un principe a sur une ressource dans GCP. Il existe certaines autorisations qui permettront à un utilisateur d'obtenir encore plus d'autorisations sur la ressource ou sur 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 d'autorisations).
Par conséquent, je voudrais séparer les techniques d'élévation de privilèges GCP en 2 groupes :
Élévation de privilèges vers un principe : Cela vous permettra de usurper l'identité d'un autre principe, et donc d'agir comme lui avec toutes ses autorisations. Par exemple : Abuser de getAccessToken pour usurper l'identité d'un compte de service.
Élévation de privilèges sur la ressource : Cela vous permettra d'obtenir plus d'autorisations sur la ressource spécifique. Par exemple : vous pouvez abuser de l'autorisation setIamPolicy sur les fonctions cloud pour vous permettre de déclencher la fonction.
Notez que certaines autorisations sur les ressources vous permettront également d'attacher un compte de service arbitraire à la ressource. Cela signifie que vous pourrez lancer une ressource avec un compte de service, accéder à la ressource et voler le jeton du compte de service. Par conséquent, cela permettra de passer à un principe via une élévation de privilèges sur une ressource. Cela s'est produit dans plusieurs ressources précédemment, mais c'est maintenant moins fréquent (mais cela peut encore se produire).
De toute évidence, les techniques d'élévation de privilèges les plus intéressantes sont celles du deuxième groupe car elles vous permettront d'obtenir plus de privilèges en dehors des ressources sur lesquelles vous avez déjà certains privilèges. Cependant, notez que l'élévation dans les ressources peut également vous donner accès à des informations sensibles ou même à d'autres principes (peut-être en lisant un secret contenant un jeton d'un compte de service).
Il est également important de noter qu'dans GCP, les comptes de service sont à la fois des principes et des autorisations, donc l'élévation de privilèges dans un compte de service vous permettra également de l'usurper.
Les autorisations entre parenthèses indiquent les autorisations nécessaires pour exploiter la vulnérabilité avec gcloud. Elles pourraient ne pas être nécessaires si elle est exploitée via l'API.
Autorisations pour la méthodologie d'élévation de privilèges
C'est ainsi que je teste des autorisations 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 le nouveau script dans tests/
Contournement des portées d'accès
Les jetons de compte de service divulgués à partir du service de métadonnées GCP ont des portées d'accès. Ce sont des restrictions sur les autorisations 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 aura seulement un accès en lecture seule à tous les services GCP même si le compte de service a plus d'autorisations dans IAM.
Il n'y a pas de moyen direct de contourner ces autorisations, mais vous pouvez toujours essayer de rechercher de nouvelles informations d'identification sur l'hôte compromis, trouver la clé de service pour générer un jeton OAuth sans restriction ou passer à un autre VM moins restreint.
Lorsque les portées d'accès sont utilisées, le jeton OAuth généré pour l'instance de calcul (VM) comprendra une limitation de portée incluse. Cependant, vous pourriez être en mesure de contourner cette limitation et exploiter les autorisations dont dispose le compte compromis.
La meilleure façon de contourner cette restriction est soit de trouver de nouvelles informations d'identification sur l'hôte compromis, de trouver la clé de service pour générer un jeton OAuth sans restriction ou de compromettre un autre VM avec un compte de service moins restreint.
Vérifiez le compte de service avec les clés générées avec :
Techniques d'élévation de privilèges
La façon d'escalader vos privilèges dans AWS est d'avoir suffisamment d'autorisations pour pouvoir, d'une manière ou d'une autre, accéder aux privilèges d'autres comptes/utilisateurs/groupes de services. Enchaîner les élévations jusqu'à obtenir un accès administratif sur l'organisation.
GCP a des centaines (voire des milliers) de permissions qu'une entité peut se voir accorder. Dans ce livre, vous pouvez trouver toutes les autorisations que je connais que vous pouvez abuser pour escalader les privilèges, mais si vous connaissez un chemin non mentionné ici, veuillez le partager.
Les sous-pages de cette section sont classées par services. Vous pouvez trouver sur chaque service différentes façons d'escalader les privilèges sur les services.
Abuser de GCP pour escalader les privilèges localement
Si vous êtes à l'intérieur d'une machine dans GCP, vous pourriez être en mesure d'abuser des autorisations pour escalader les privilèges même localement :
pageGCP - local privilege escalation ssh pivotingRéférences
Dernière mise à jour