GCP - Storage Privesc

Tip

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) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

Stockage

Basic Information:

GCP - Storage Enum

storage.objects.get

Cette permission vous permet de télécharger des fichiers stockés dans Cloud Storage. Cela peut potentiellement vous permettre d’escalader vos privilèges car, dans certaines occasions, des informations sensibles y sont enregistrées. De plus, certains services GCP stockent leurs informations dans des buckets :

  • GCP Composer: Lorsque vous créez un Composer Environment le code de tous les DAGs sera enregistré dans un bucket. Ces tâches peuvent contenir des informations intéressantes dans leur code.
  • GCR (Container Registry): L’image des conteneurs est stockée dans des buckets, ce qui signifie que si vous pouvez lire les buckets vous pourrez télécharger les images et rechercher des leaks et/ou du source code.

storage.objects.setIamPolicy

Cela peut vous permettre d’abuser de n’importe lequel des scénarios précédents de cette section.

# Add binding
gcloud storage objects add-iam-policy-binding gs://<BUCKET_NAME>/<OBJECT_NAME> \
--member="<MEMBER_TYPE>:<MEMBER_IDENTIFIER>" \
--role="<ROLE>" \
--project=<PROJECT_ID>

# Remove binding
gcloud storage objects remove-iam-policy-binding gs://<BUCKET_NAME>/<OBJECT_NAME> \
--member="<MEMBER_TYPE>:<MEMBER_IDENTIFIER>" \
--role="<ROLE>" \
--project=<PROJECT_ID>

# Change Policy
gcloud storage objects set-iam-policy gs://<BUCKET_NAME>/<OBJECT_NAME> - \
--project=<PROJECT_ID> <<'POLICY'
{
"bindings": [
{
"role": "<ROLE>",
"members": [
"<MEMBER_TYPE>:<MEMBER_IDENTIFIER>"
]
}
]
}
POLICY

storage.buckets.setIamPolicy

Pour un exemple montrant comment modifier les autorisations avec cette permission, consultez cette page :

# Add binding
gcloud storage buckets add-iam-policy-binding gs://<MY_BUCKET> \
--member="<MEMBER_TYPE>:<MEMBER_IDENTIFIER>" \
--role=<ROLE> \
--project=<MY_PROJECT>

# Remove binding
gcloud storage buckets remove-iam-policy-binding gs://<MY_BUCKET> \
--member="<MEMBER_TYPE>:<MEMBER_IDENTIFIER>" \
--role=<ROLE> \
--project=<MY_PROJECT>

# Change policy
gcloud storage buckets set-iam-policy gs://<BUCKET_NAME> - \
--project=<PROJECT_ID> <<'POLICY'
{
"bindings": [
{
"role": "<ROLE>",
"members": [
"<MEMBER_TYPE>:<MEMBER_IDENTIFIER>"
]
}
]
}
POLICY

GCP - Public Buckets Privilege Escalation

storage.hmacKeys.create

La fonctionnalité “interoperability” de Cloud Storage, conçue pour les interactions inter-cloud comme avec AWS S3, implique la création de HMAC keys pour Service Accounts and users. Un attaquant peut exploiter cela en générant une HMAC key pour un Service Account doté de privilèges élevés, ce qui permet ainsi d’escalader les privilèges dans Cloud Storage. Alors que les HMAC keys associées aux utilisateurs ne sont récupérables que via la web console, les clés d’accès et les clés secrètes restent accessibles en permanence, permettant un stockage de secours potentiel des accès. En revanche, les HMAC keys liées aux Service Accounts sont accessibles via l’API, mais leurs clés d’accès et clés secrètes ne sont pas récupérables après la création, ajoutant une couche de complexité pour un accès continu.

# Create key
gsutil hmac create <sa-email> # You might need to execute this inside a VM instance

## If you have TROUBLES creating the HMAC key this was you can also do it contacting the API directly:
PROJECT_ID = '$PROJECT_ID'
TARGET_SERVICE_ACCOUNT = f"exam-storage-sa-read-flag-3@{PROJECT_ID}.iam.gserviceaccount.com"
ACCESS_TOKEN = "$CLOUDSDK_AUTH_ACCESS_TOKEN"
import requests
import json
key = requests.post(
f'https://www.googleapis.com/storage/v1/projects/{PROJECT_ID}/hmacKeys',
params={'access_token': ACCESS_TOKEN, 'serviceAccountEmail': TARGET_SERVICE_ACCOUNT}
).json()
#print(json.dumps(key, indent=4))
print(f'ID: {key["metadata"]["accessId"]}')
print(f'Secret: {key["secret"]}')


# Configure gsutil to use the HMAC key
gcloud config set pass_credentials_to_gsutil false
gsutil config -a

# Use it
gsutil ls gs://[BUCKET_NAME]

# Restore
gcloud config set pass_credentials_to_gsutil true

Un autre script d’exploitation pour cette méthode peut être trouvé ici.

storage.objects.create, storage.objects.delete = Permissions d’écriture Storage

Pour créer un nouvel objet dans un bucket, vous avez besoin de storage.objects.create et, selon la documentation, vous avez aussi besoin de storage.objects.delete pour modifier un objet existant.

Une exploitation très courante des buckets où l’on peut écrire dans le cloud concerne les cas où le bucket contient des fichiers de serveur web : vous pourriez être en mesure de stocker du nouveau code qui sera utilisé par l’application web.

Composer

Composer est Apache Airflow géré dans GCP. Il présente plusieurs caractéristiques intéressantes :

  • Il s’exécute dans un GKE cluster, donc le SA utilisé par le cluster est accessible par le code s’exécutant dans Composer
  • Tous les composants d’un environnement composer (code des DAGs, plugins et données) sont stockés dans un bucket GCP. Si l’attaquant a des permissions de lecture et d’écriture dessus, il peut surveiller le bucket et whenever a DAG is created or updated, submit a backdoored version so the composer environment will get from the storage the backdoored version.

Vous pouvez trouver un PoC de cette attaque dans le repo : https://github.com/carlospolop/Monitor-Backdoor-Composer-DAGs

Cloud Functions

  • Le code des Cloud Functions est stocké dans Storage et chaque fois qu’une nouvelle version est créée, le code est poussé dans le bucket puis le nouveau conteneur est construit à partir de ce code. Ainsi, en écrasant le code avant que la nouvelle version ne soit buildée, il est possible de faire exécuter du code arbitraire par la cloud function.

Vous pouvez trouver un PoC de cette attaque dans le repo : https://github.com/carlospolop/Monitor-Backdoor-Cloud-Functions

App Engine

Les versions AppEngine génèrent des données dans un bucket nommé selon le format : staging.<project-id>.appspot.com. Dans ce bucket, on peut trouver un dossier appelé ae contenant un dossier par version de l’application AppEngine et, à l’intérieur de ces dossiers, on peut trouver le fichier manifest.json. Ce fichier contient un json listant tous les fichiers nécessaires à la création de la version spécifique. De plus, il est possible d’y trouver les noms réels des fichiers, l’URL vers eux dans le bucket GCP (les fichiers dans le bucket voient leur nom remplacé par leur sha1) et le sha1 hash de chaque fichier.

Notez qu’il n’est pas possible de pré-saisir ce bucket car les utilisateurs GCP ne sont pas autorisés à créer des buckets utilisant le nom de domaine appspot.com.

Cependant, avec un accès lecture & écriture sur ce bucket, il est possible d’escalader les privilèges vers le SA attaché à la version App Engine en surveillant le bucket et, à chaque changement (nouvelle version), en modifiant la nouvelle version aussi vite que possible. Ainsi, le conteneur créé à partir de ce code exécutera le code backdoored.

L’attaque mentionnée peut être réalisée de plusieurs façons ; toutes commencent par la surveillance du bucket staging.<project-id>.appspot.com :

  • Téléversez le code complet de la nouvelle version AppEngine dans un bucket différent et disponible et préparez un manifest.json avec le nouveau nom de bucket et les sha1 hashes. Ensuite, lorsqu’une nouvelle version est créée dans le bucket, il suffit de modifier le manifest.json et d’uploader le fichier malveillant.
  • Téléversez une version modifiée de requirements.txt qui utilisera des dépendances malveillantes et mettez à jour le manifest.json avec le nouveau nom de fichier, l’URL et son hash.
  • Téléversez un main.py ou app.yaml modifié qui exécutera le code malveillant et mettez à jour le manifest.json avec le nouveau nom de fichier, l’URL et son hash.

Vous pouvez trouver un PoC de cette attaque dans le repo : https://github.com/carlospolop/Monitor-Backdoor-AppEngine

GCR

  • Google Container Registry stocke les images dans des buckets ; si vous pouvez écrire dans ces buckets, vous pourriez être capable de vous déplacer latéralement vers les environnements où ces images sont exécutées.
  • Le bucket utilisé par GCR aura une URL similaire à gs://<eu/usa/asia/nothing>.artifacts.<project>.appspot.com (les sous-domaines de premier niveau sont spécifiés ici).

Tip

Ce service est déprécié, donc cette attaque n’est plus utile. De plus, Artifact Registry, le service qui remplace celui-ci, n’enregistre pas les images dans des buckets.

Références

Tip

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) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks