GCP - Network Docker Escape

Tip

Aprende y practica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprende y practica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

Estado inicial

En ambos writeups donde se especifica esta técnica, los atacantes lograron obtener acceso root dentro de un contenedor Docker gestionado por GCP con acceso a la red del host (y las capacidades CAP_NET_ADMIN y CAP_NET_RAW).

Explicación del ataque

En una instancia de Google Compute Engine, la inspección habitual del tráfico de red revela numerosas peticiones HTTP en texto plano al metadata instance en 169.254.169.254. El Google Guest Agent, un servicio open-source, realiza con frecuencia este tipo de peticiones.

Este agente está diseñado para vigilar cambios en los metadatos. De forma notable, los metadatos incluyen un campo para claves públicas SSH. Cuando se añade una nueva clave pública SSH a los metadatos, el agente automáticamente la autoriza en el archivo .authorized_key. También puede crear un nuevo usuario y añadirlo a sudoers si es necesario.

El agente monitoriza cambios enviando una petición para recuperar todos los valores de metadata de forma recursiva (GET /computeMetadata/v1/?recursive=true). Esta petición está diseñada para inducir al servidor de metadata a enviar una respuesta solo si ha habido algún cambio en los metadatos desde la última recuperación, identificado por un Etag (wait_for_change=true&last_etag=). Adicionalmente, se incluye un parámetro de timeout (timeout_sec=). Si no ocurre ningún cambio dentro del timeout especificado, el servidor responde con los valores sin cambios.

Este proceso permite que el IMDS (Instance Metadata Service) responda después de 60 segundos si no ha habido cambios de configuración, creando una posible ventana para inyectar una respuesta de configuración falsa al guest agent.

Un atacante podría explotar esto realizando un ataque Man-in-the-Middle (MitM), suplantando la respuesta del servidor IMDS e insertando una nueva clave pública. Esto podría permitir acceso SSH no autorizado al host.

Técnica de escape

Mientras que ARP spoofing es ineficaz en las redes de Google Compute Engine, una versión modificada de rshijack desarrollada por Ezequiel puede usarse para la inyección de paquetes en la comunicación y así inyectar el usuario SSH.

Esta versión de rshijack permite introducir los números ACK y SEQ como argumentos de línea de comandos, facilitando la suplantación de una respuesta antes de la respuesta real del servidor Metadata. Además, se utiliza un pequeño script Shell para devolver una carga útil especialmente creada. Esta payload provoca que el Google Guest Agent cree un usuario wouter con una clave pública especificada en el archivo .authorized_keys.

El script utiliza el mismo ETag para evitar que el servidor Metadata notifique inmediatamente al Google Guest Agent sobre valores de metadata diferentes, retrasando así la respuesta.

Para ejecutar el spoofing, son necesarios los siguientes pasos:

  1. Monitorizar las peticiones al servidor Metadata usando tcpdump:
Monitorizar peticiones al servidor metadata con tcpdump ```bash tcpdump -S -i eth0 'host 169.254.169.254 and port 80' & ```

Busca una línea similar a:

Ejemplo de línea de salida de tcpdump ```