GCP - Cloudfunctions Privesc
cloudfunctions
Plus d'informations sur Cloud Functions :
GCP - Cloud Functions Enumcloudfunctions.functions.create
, cloudfunctions.functions.sourceCodeSet
, iam.serviceAccounts.actAs
cloudfunctions.functions.create
, cloudfunctions.functions.sourceCodeSet
, iam.serviceAccounts.actAs
Un attaquant avec ces privilèges peut créer une nouvelle Cloud Function avec du code arbitraire (malveillant) et lui attribuer un Service Account. Ensuite, il peut récupérer le token du Service Account à partir des métadonnées pour élever ses privilèges. Certains privilèges pour déclencher la fonction peuvent être nécessaires.
Des scripts d'exploitation pour cette méthode peuvent être trouvés ici et ici et le fichier .zip préconstruit peut être trouvé ici.
cloudfunctions.functions.update
, cloudfunctions.functions.sourceCodeSet
, iam.serviceAccounts.actAs
cloudfunctions.functions.update
, cloudfunctions.functions.sourceCodeSet
, iam.serviceAccounts.actAs
Un attaquant avec ces privilèges peut modifier le code d'une fonction et même modifier le compte de service attaché dans le but d'exfiltrer le token.
Pour déployer des cloud functions, vous aurez également besoin de permissions actAs sur le compte de service de calcul par défaut ou sur le compte de service utilisé pour construire l'image.
Certains privilèges supplémentaires comme la permission .call
pour la version 1 des cloudfunctions ou le rôle role/run.invoker
pour déclencher la fonction peuvent être nécessaires.
Si vous obtenez l'erreur Permission 'run.services.setIamPolicy' denied on resource...
, c'est parce que vous utilisez le paramètre --allow-unauthenticated
et que vous n'avez pas suffisamment de permissions pour cela.
Le script d'exploitation pour cette méthode peut être trouvé ici.
cloudfunctions.functions.sourceCodeSet
cloudfunctions.functions.sourceCodeSet
Avec cette permission, vous pouvez obtenir une URL signée pour pouvoir télécharger un fichier dans un bucket de fonction (mais le code de la fonction ne sera pas modifié, vous devez toujours le mettre à jour)
Je ne suis pas vraiment sûr de l'utilité de cette seule autorisation du point de vue d'un attaquant, mais c'est bon à savoir.
cloudfunctions.functions.setIamPolicy
, iam.serviceAccounts.actAs
cloudfunctions.functions.setIamPolicy
, iam.serviceAccounts.actAs
Donnez-vous l'un des précédents privilèges .update
ou .create
pour escalader.
cloudfunctions.functions.update
cloudfunctions.functions.update
Avoir uniquement des autorisations cloudfunctions
, sans iam.serviceAccounts.actAs
, vous ne pourrez pas mettre à jour la fonction DONC CE N'EST PAS UN VALID PRIVESC.
Accès en lecture et écriture sur le bucket
Si vous avez un accès en lecture et écriture sur le bucket, vous pouvez surveiller les changements dans le code et chaque fois qu'une mise à jour dans le bucket se produit, vous pouvez mettre à jour le nouveau code avec votre propre code afin que la nouvelle version de la Cloud Function s'exécute avec le code backdoor soumis.
Vous pouvez en savoir plus sur l'attaque dans :
GCP - Storage PrivescCependant, vous ne pouvez pas utiliser cela pour pré-compromettre des Cloud Functions tierces car si vous créez le bucket dans votre compte et lui donnez des autorisations publiques afin que le projet externe puisse y écrire, vous obtenez l'erreur suivante :
Cependant, cela pourrait être utilisé pour des attaques DoS.
Accès en lecture et écriture sur l'Artifact Registry
Lorsqu'une Cloud Function est créée, une nouvelle image docker est poussée vers l'Artifact Registry du projet. J'ai essayé de modifier l'image avec une nouvelle et même de supprimer l'image actuelle (et l'image cache
), mais rien n'a changé, la Cloud Function continue de fonctionner. Par conséquent, il pourrait être possible d'abuser d'une attaque de condition de course comme avec le bucket pour changer le conteneur docker qui sera exécuté, mais modifier simplement l'image stockée n'est pas possible pour compromettre la Cloud Function.
Références
Last updated