GCP - Storage Privesc
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Informations de base :
GCP - Storage Enumstorage.objects.getCette permission vous permet de télécharger des fichiers stockés dans Cloud Storage. Cela pourrait potentiellement vous permettre d'escalader les 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 environnement Composer, 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 fuites et/ou du code source.
storage.objects.setIamPolicyVous pouvez vous donner la permission de profiter de l'un des scénarios précédents de cette section.
storage.buckets.setIamPolicyPour un exemple sur la façon de modifier les permissions avec cette permission, consultez cette page :
GCP - Public Buckets Privilege Escalationstorage.hmacKeys.createLa fonctionnalité "d'interopérabilité" de Cloud Storage, conçue pour les interactions inter-cloud comme avec AWS S3, implique la création de clés HMAC pour les comptes de service et les utilisateurs. Un attaquant peut exploiter cela en générant une clé HMAC pour un compte de service avec des privilèges élevés, permettant ainsi d'escalader les privilèges au sein de Cloud Storage. Bien que les clés HMAC associées aux utilisateurs ne soient récupérables que via la console web, les clés d'accès et secrètes restent perpétuellement accessibles, permettant un accès de sauvegarde potentiel. En revanche, les clés HMAC liées aux comptes de service sont accessibles via l'API, mais leurs clés d'accès et secrètes ne sont pas récupérables après leur création, ajoutant une couche de complexité pour un accès continu.
Un autre script d'exploitation pour cette méthode peut être trouvé ici.
storage.objects.create, storage.objects.delete = Permissions d'écriture dans le stockagePour créer un nouvel objet à l'intérieur d'un bucket, vous avez besoin de storage.objects.create et, selon la documentation, vous avez également besoin de storage.objects.delete pour modifier un objet existant.
Une exploitation très courante des buckets où vous pouvez écrire dans le cloud est le cas où le bucket sauvegarde des fichiers de serveur web, vous pourriez être en mesure de stocker un nouveau code qui sera utilisé par l'application web.
Composer est Apache Airflow géré à l'intérieur de GCP. Il a plusieurs fonctionnalités intéressantes :
Il fonctionne à l'intérieur d'un cluster GKE, donc le SA utilisé par le cluster est accessible par le code s'exécutant à l'intérieur de Composer.
Tous les composants d'un environnement de composer (code des DAGs, plugins et données) sont stockés à l'intérieur d'un bucket GCP. Si l'attaquant a des permissions de lecture et d'écriture sur celui-ci, il pourrait surveiller le bucket et chaque fois qu'un DAG est créé ou mis à jour, soumettre une version compromise afin que l'environnement de composer récupère la version compromise depuis le stockage.
Vous pouvez trouver un PoC de cette attaque dans le repo : https://github.com/carlospolop/Monitor-Backdoor-Composer-DAGs
Le code des Cloud Functions est stocké dans Storage et chaque fois qu'une nouvelle version est créée, le code est poussé vers le bucket et ensuite le nouveau conteneur est construit à partir de ce code. Par conséquent, écraser le code avant que la nouvelle version ne soit construite permet d'exécuter du code arbitraire dans la fonction cloud.
Vous pouvez trouver un PoC de cette attaque dans le repo : https://github.com/carlospolop/Monitor-Backdoor-Cloud-Functions
Les versions d'AppEngine génèrent des données à l'intérieur d'un bucket avec le format de nom : staging.<project-id>.appspot.com. À l'intérieur de ce bucket, il est possible de trouver un dossier appelé ae qui contiendra un dossier par version de l'application AppEngine et à l'intérieur de ces dossiers, il sera possible de trouver le fichier manifest.json. Ce fichier contient un json avec tous les fichiers qui doivent être utilisés pour créer la version spécifique. De plus, il est possible de trouver les vrais noms des fichiers, l'URL vers eux à l'intérieur du bucket GCP (les fichiers à l'intérieur du bucket ont changé leur nom pour leur hash sha1) et le hash sha1 de chaque fichier.
Remarque : il n'est pas possible de pré-prendre ce bucket car les utilisateurs GCP ne sont pas autorisés à générer des buckets utilisant le nom de domaine appspot.com.
Cependant, avec un accès en lecture et é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 fois qu'un changement est effectué (nouvelle version), modifier la nouvelle version aussi rapidement que possible. De cette manière, le conteneur qui est créé à partir de ce code exécutera le code compromis.
L'attaque mentionnée peut être réalisée de plusieurs manières différentes, toutes commencent par surveiller le bucket staging.<project-id>.appspot.com :
Téléchargez le nouveau code complet de la version AppEngine vers un autre bucket disponible et préparez un fichier manifest.json avec le nouveau nom de bucket et les hashes sha1 de ceux-ci. Ensuite, lorsque qu'une nouvelle version est créée à l'intérieur du bucket, vous devez simplement modifier le fichier manifest.json et télécharger le fichier malveillant.
Téléchargez une version modifiée de requirements.txt qui utilisera le code des dépendances malveillantes et mettez à jour le fichier manifest.json avec le nouveau nom de fichier, l'URL et le hash de celui-ci.
Téléchargez un fichier main.py ou app.yaml modifié qui exécutera le code malveillant et mettez à jour le fichier manifest.json avec le nouveau nom de fichier, l'URL et le hash de celui-ci.
Vous pouvez trouver un PoC de cette attaque dans le repo : https://github.com/carlospolop/Monitor-Backdoor-AppEngine
Google Container Registry stocke les images à l'intérieur des buckets, si vous pouvez écrire dans ces buckets, vous pourriez être en mesure de vous déplacer latéralement vers l'endroit où ces buckets sont exécutés.
Le bucket utilisé par GCR aura une URL similaire à gs://<eu/usa/asia/nothing>.artifacts.<project>.appspot.com (Les sous-domaines de niveau supérieur sont spécifiés ici).
Ce service est obsolète donc cette attaque n'est plus utile. De plus, Artifact Registry, le service qui le remplace, ne stocke pas les images dans des buckets.
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)
