GCP - Storage Privesc
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Storage
Información básica:
GCP - Storage Enumstorage.objects.get
storage.objects.get
Este permiso te permite descargar archivos almacenados dentro de Cloud Storage. Esto potencialmente te permitirá escalar privilegios porque en algunas ocasiones se guarda información sensible allí. Además, algunos servicios de GCP almacenan su información en buckets:
GCP Composer: Cuando creas un entorno de Composer, el código de todos los DAGs se guardará dentro de un bucket. Estas tareas pueden contener información interesante dentro de su código.
GCR (Container Registry): La imagen de los contenedores se almacena dentro de buckets, lo que significa que si puedes leer los buckets podrás descargar las imágenes y buscar filtraciones y/o código fuente.
storage.objects.setIamPolicy
storage.objects.setIamPolicy
Puedes darte permiso para abusar de cualquiera de los escenarios anteriores de esta sección.
storage.buckets.setIamPolicy
storage.buckets.setIamPolicy
Para un ejemplo sobre cómo modificar permisos con este permiso, consulta esta página:
GCP - Public Buckets Privilege Escalationstorage.hmacKeys.create
storage.hmacKeys.create
La función de "interoperabilidad" de Cloud Storage, diseñada para interacciones entre nubes como con AWS S3, implica la creación de claves HMAC para cuentas de servicio y usuarios. Un atacante puede explotar esto generando una clave HMAC para una cuenta de servicio con privilegios elevados, así escalando privilegios dentro de Cloud Storage. Mientras que las claves HMAC asociadas a usuarios solo son recuperables a través de la consola web, tanto las claves de acceso como las secretas permanecen perpetuamente accesibles, lo que permite un posible acceso de respaldo. Por otro lado, las claves HMAC vinculadas a cuentas de servicio son accesibles a través de API, pero sus claves de acceso y secretas no son recuperables después de la creación, añadiendo una capa de complejidad para el acceso continuo.
Otro script de explotación para este método se puede encontrar aquí.
storage.objects.create
, storage.objects.delete
= Permisos de escritura en almacenamiento
storage.objects.create
, storage.objects.delete
= Permisos de escritura en almacenamientoPara crear un nuevo objeto dentro de un bucket necesitas storage.objects.create
y, según la documentación, también necesitas storage.objects.delete
para modificar un objeto existente.
Una explotación muy común de los buckets donde puedes escribir en la nube es en caso de que el bucket esté guardando archivos del servidor web, podrías ser capaz de almacenar nuevo código que será utilizado por la aplicación web.
Composer
Composer es Apache Airflow gestionado dentro de GCP. Tiene varias características interesantes:
Se ejecuta dentro de un clúster GKE, por lo que el SA que utiliza el clúster es accesible por el código que se ejecuta dentro de Composer.
Todos los componentes de un entorno de composer (código de DAGs, plugins y datos) se almacenan dentro de un bucket de GCP. Si el atacante tiene permisos de lectura y escritura sobre él, podría monitorear el bucket y cada vez que se crea o actualiza un DAG, enviar una versión con puerta trasera para que el entorno de composer obtenga de almacenamiento la versión con puerta trasera.
Puedes encontrar un PoC de este ataque en el repositorio: https://github.com/carlospolop/Monitor-Backdoor-Composer-DAGs
Cloud Functions
El código de Cloud Functions se almacena en Storage y cada vez que se crea una nueva versión, el código se envía al bucket y luego se construye el nuevo contenedor a partir de este código. Por lo tanto, sobrescribir el código antes de que se construya la nueva versión es posible para hacer que la función en la nube ejecute código arbitrario.
Puedes encontrar un PoC de este ataque en el repositorio: https://github.com/carlospolop/Monitor-Backdoor-Cloud-Functions
App Engine
Las versiones de AppEngine generan algunos datos dentro de un bucket con el formato nombre: staging.<project-id>.appspot.com
. Dentro de este bucket, es posible encontrar una carpeta llamada ae
que contendrá una carpeta por versión de la aplicación AppEngine y dentro de estas carpetas será posible encontrar el archivo manifest.json
. Este archivo contiene un json con todos los archivos que deben ser utilizados para crear la versión específica. Además, es posible encontrar los nombres reales de los archivos, la URL a ellos dentro del bucket de GCP (los archivos dentro del bucket cambiaron su nombre por su hash sha1) y el hash sha1 de cada archivo.
Ten en cuenta que no es posible tomar el control de este bucket porque los usuarios de GCP no están autorizados para generar buckets utilizando el nombre de dominio appspot.com.
Sin embargo, con acceso de lectura y escritura sobre este bucket, es posible escalar privilegios al SA adjunto a la versión de App Engine monitoreando el bucket y cada vez que se realiza un cambio (nueva versión), modificar la nueva versión lo más rápido posible. De esta manera, el contenedor que se crea a partir de este código ejecutará el código con puerta trasera.
El ataque mencionado se puede realizar de muchas maneras diferentes, todas ellas comienzan por monitorear el bucket staging.<project-id>.appspot.com
:
Sube el nuevo código completo de la versión de AppEngine a un bucket diferente y disponible y prepara un archivo
manifest.json
con el nuevo nombre del bucket y los hashes sha1 de ellos. Luego, cuando se crea una nueva versión dentro del bucket, solo necesitas modificar el archivomanifest.json
y subir el malicioso.Sube una versión modificada de
requirements.txt
que utilizará el código de dependencias maliciosas y actualiza el archivomanifest.json
con el nuevo nombre de archivo, URL y el hash de este.Sube un archivo
main.py
oapp.yaml
modificado que ejecutará el código malicioso y actualiza el archivomanifest.json
con el nuevo nombre de archivo, URL y el hash de este.
Puedes encontrar un PoC de este ataque en el repositorio: https://github.com/carlospolop/Monitor-Backdoor-AppEngine
GCR
Google Container Registry almacena las imágenes dentro de buckets, si puedes escribir en esos buckets podrías ser capaz de moverte lateralmente a donde se están ejecutando esos buckets.
El bucket utilizado por GCR tendrá una URL similar a
gs://<eu/usa/asia/nothing>.artifacts.<project>.appspot.com
(Los subdominios de nivel superior están especificados aquí).
Este servicio está en desuso, por lo que este ataque ya no es útil. Además, Artifact Registry, el servicio que lo sustituye, no almacena las imágenes en buckets.
Referencias
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)
Last updated