Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Plus d'informations sur les Cloud Functions :
GCP - Cloud Functions Enum
cloudfunctions.functions.create , cloudfunctions.functions.sourceCodeSet, iam.serviceAccounts.actAsUn attaquant avec ces privilèges peut créer une nouvelle Cloud Function avec du code arbitraire (malveillant) et lui assigner 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 requis.
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.actAsUn attaquant avec ces privilèges peut modifier le code d'une Function et même modifier le service account attaché dans le but d'exfiltrer le token.
Pour déployer des cloud functions, vous aurez également besoin de permissions actAs sur le service account de calcul par défaut ou sur le service account 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 requis.
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.sourceCodeSetAvec 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.actAsDonnez-vous l'un des précédents privilèges .update ou .create pour escalader.
cloudfunctions.functions.updateAvoir uniquement des autorisations cloudfunctions, sans iam.serviceAccounts.actAs, vous ne pourrez pas mettre à jour la fonction DONC CE N'EST PAS UNE ESCALADE VALIDE.
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 écrire dessus, vous obtenez l'erreur suivante :
Cependant, cela pourrait être utilisé pour des attaques DoS.
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), et 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.
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)
