GCP - Network Docker Escape
Estado Inicial
En ambos informes donde se especifica esta técnica, los atacantes lograron obtener acceso de 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).
Ataque
Cuando inspeccionas el tráfico de red en una instancia regular de Google Compute Engine, verás muchos solicitudes HTTP simples dirigidas a la instancia de metadata en 169.254.169.254. Un servicio que realiza tales solicitudes es el Google Guest Agent de código abierto. Ejemplo de solicitud:
Este agente monitorea los cambios en la metadata. Dentro de la metadata hay un campo con claves públicas SSH autorizadas.
Por lo tanto, cuando una nueva clave pública SSH aparece en la metadata, el agente la autorizará en el archivo .authorized_key del usuario y creará un nuevo usuario si es necesario, añadiéndolo a sudoers.
La forma en que el Google Guest Agent monitorea los cambios es a través de una llamada para recuperar todos los valores de metadata recursivamente (GET /computeMetadata/v1/?recursive=true), indicando al servidor de metadata que solo envíe una respuesta cuando haya algún cambio con respecto a los últimos valores de metadata recuperados, identificados por su Etag (wait_for_change=true&last_etag=).
Esta solicitud también incluye un tiempo de espera (timeout_sec=), por lo que si un cambio no ocurre dentro del tiempo especificado, el servidor de metadata responde con los valores sin cambios.
Esto hace que el IMDS responda después de 60 segundos si no hubo un cambio de configuración en ese intervalo, permitiendo una ventana para inyectar una respuesta de configuración falsa al agente invitado desde el IMDS.
Por lo tanto, si un atacante logra realizar un ataque MitM, podría falsificar la respuesta del servidor IMDS insertando una nueva clave pública para permitir que un nuevo usuario acceda vía SSH al host.
Escape
El spoofing ARP no funciona en las redes de Google Compute Engine, sin embargo, Ezequiel generó esta versión modificada de rshijack **** que se puede utilizar para inyectar un paquete en la comunicación e inyectar el usuario SSH.
Esta versión modificada de rshijack permite pasar los números ACK y SEQ como argumentos de línea de comando, ahorrando tiempo y permitiéndonos falsificar una respuesta antes de que llegue la verdadera respuesta de Metadata.
Además, este pequeño script de Shell **** que devolvería un payload especialmente diseñado que activaría al Google Guest Agent para crear el usuario wouter, con nuestra propia clave pública en su archivo .authorized_keys.
Este script recibe el ETag como parámetro, ya que al mantener el mismo ETag, el servidor de Metadata no le diría inmediatamente al Google Guest Agent que los valores de la metadata eran diferentes en la siguiente respuesta, en su lugar esperando la cantidad de segundos especificada en timeout_sec.
Para lograr el spoofing, deberías observar las solicitudes al servidor de Metadata con tcpdump: tcpdump -S -i eth0 'host 169.254.169.254 and port 80' & esperando una línea que se pareciera a esta:
Cuando veas ese valor, envía los datos falsos de metadatos con el ETAG correcto a rshijack:
fakeData.sh <ETAG> | rshijack -q eth0 169.254.169.254:80 <IP_LOCAL>:<PUERTO> <TARGET_SEQ> <TARGET_ACK>; ssh -i id_rsa -o StrictHostKeyChecking=no wouter@localhost
Y esto debería hacer que el agente autorice esa clave pública que te permitirá conectarte vía SSH con la clave privada.
Referencias
Última actualización
