Cluster Hijacking
Última actualización
¿Te fue útil?
Última actualización
¿Te fue útil?
¿Crees tener lo que se necesita para ser un experto en Pentesting contra AWS? Si nuestro libro te abrió los ojos a las posibilidades de la ciberseguridad ofensiva o si ya cuentas con habilidades en este campo, es momento de subir de nivel. Te retamos a certificarte en el . No será fácil: te enfrentarás a un examen riguroso de 12 horas donde deberás hackear una infraestructura completa alojada en AWS. ¿Listo para el desafío? Acepta el reto y demuestra tu verdadero potencial.
Este contenido se adentra en una técnica avanzada de post-explotación, crucial para entender cómo maximizar el impacto de un ataque una vez que se ha conseguido penetrar en un sistema. Es importante recalcar que la ejecución de esta técnica presupone que el atacante o consultor ya ha obtenido ciertos niveles de privilegios dentro de la infraestructura objetivo. Sin estos privilegios, llevar a cabo el ataque explicado aquí no sería posible. Proceder con cautela y siempre dentro del marco legal y ético es fundamental.
En este escenario comenzaremos realizando un pentesting de caja negra contra un aplicativo web alojado en una instancia EC2.
Luego de identificar una vulnerabilidad que permite RCE sobre el aplicativo web abusaremos del servicio de metadatos de la instancia y del docker.
Para posteriormente, comprometer una de las tareas que está corriendo aun cluster al que tendremos acceso por medio de la instancia comprometida.
Luego de que finalice el despliegue del laboratorio, nos retornara lo siguiente:
En la evidencia previa, podemos apreciar una URL: ec2-18-212-167-253.compute-1.amazonaws.com
Vamos a comenzar, realizando un escaneo de puertos sobre la URL entregada:
Gracias al resultado de Nmap, podemos afirmar con seguridad que el servicio HTTP está corriendo en el puerto 80 sobre la URL inicial.
Vamos a acceder al aplicativo web desde el navegador para conocer lo que vamos a auditar:
En la evidencia previa, pudimos identificar un campo que permite el ingreso de texto y está solicitando una URL.
Luego de ingresar www.google.com en el campo identificado, podemos apreciar como automáticamente se agrega el parámetro URL sobre el link original y además vemos como también el aplicativo web incrusta el código HTML sobre el DOM de la página web:
Si capturamos la petición con un proxy como BurpSuite lograremos identificar lo siguiente:
Ahora que hemos analizado el comportamiento del aplicativo, vamos a intentar realizar una inyección de comandos sobre el sitio web:
Para ello es recomendable utilizar un intruder de BurpSuite con un diccionario como el que se encuentra en el siguiente enlace:
Luego de utilizar el intruder e identificar que el aplicativo es vulnerable a inyección de comandos sobre el input localizado podemos realizar una enumeración del sistema:
Vamos a retornar las variables de entorno del equipo:
En la evidencia previa, podemos afirmar que nos encontramos en una instancia EC2 y que probablemente hay unos contendores corriendo por medio de ECS.
Vamos a retornar el hostname del equipo:
Vamos a retornar UID y el GID del usuario actual:
El retorno del comando id indica que estamos en un equipo con sistema operativo Linux y que el aplicativo está corriendo con el usuario root.
Por lo anterior, no será necesario realizar una escalación de privilegios sobre el equipo.
Vamos a seguir enumerando para identificar algún posible vector de ataque.
En el proceso de enumeración interna de un servidor, es recomendable utilizar los siguientes scripts:
Una validación básica es analizar el contenido del archivo sensible /etc/passwd
Otra validación importante que se debe realizar es identificar las interfaces de red existentes en el servidor:
En la evidencia previa, pudimos identificar que existe una interfaz de red llamada Docker.
Por lo anterior, vamos a enfocarnos a partir de este momento en una enumeración orientada en Docker.
Vamos a validar los contenedores:
Por la composición de la URL y de las variables de entorno identificadas, podríamos afirmar con seguridad que estamos sobre un servicio alojado en la nube de AWS.
En el retorno del comando previo, pudimos identificar los siguientes contenedores:
ecs-cg-ecs-takeover-ecs_takeover_cgidoc6vcayyqm-vulnsite-1-vulnsite-c8afb7c6c79b90f78a01
74982c535387
ecs-cg-ecs-takeover-ecs_takeover_cgidoc6vcayyqm-privd-1-privd-a29abccb8ff6daa43300
b53d1b7fdd08
ecs-agent
ab2087c21311
Por lo anterior, sería buena idea tratar de consumir el servicio de metadatos para tratar de asumir el rol de la instancia actual:
Los contenedores tienen un servicio de metadatos de contenedor que pueden usar para acceder al rol adjunto a su contenedor. La instancia EC2 también tiene habilitado su servicio de metadatos y, de forma predeterminada, se puede acceder a ella desde todos los contenedores que se ejecutan en el cluster. Como resultado, todos los contenedores en el host pueden obtener el rol de la instancia y alterar el estado del clúster.
Los permisos de este primer rol llamado cg-ecs-takeover-ecs_takeover_cgidoc6vcayyqm-ecs-agent – (Rol de EC2), son los siguientes:
Antes de autenticarnos con este rol, vamos a tratar también de extraer credenciales del Docker ya que podríamos tener aún más permisos que el rol actual y facilitar la enumeración de privilegios.
Si analizamos esta política podemos apreciar que tenemos varios permisos relacionados al ECR, ECS y unos pocos en el servicio de logs.
Las tareas de ECS pueden tener un rol de IAM asociado a ellas. Los permisos que se ejecutan en la tarea asumen los permisos concedidos en el rol de IAM.
El agente de Amazon ECS rellena la variable de entorno AWS_CONTAINER_CREDENTIALS_RELATIVE_URI en el objeto env (disponible con el comando docker inspect container_id) para todos los contenedores que pertenecen a esta tarea.
En pocas palabras, para obtener unas credenciales de IAM del contenedor tenemos que comunicarnos con la siguiente URL:
http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI
Vamos a acceder a uno de los contenedores y tratemos de consultar el servicio de metadatos de dicho contenedor.
El Docker al que vamos a acceder es el siguiente:
Por medio del comando docker exec, podemos controlar internamente a ese contenedor.
Y utilizando wget, podemos realizar una petición GET contra el punto de enlace de credenciales desde este contenedor.
Los permisos de este segundo rol llamado cg-ecs-takeover-ecs_takeover_cgidoc6vcayyqm-privd – (Rol de contenedor), son los siguientes:
A partir de este momento, estaremos trabajando con el usuario cg-ecs-takeover-ecs_takeover_cgidoc6vcayyqm-privd.
Todos los comandos posteriores deben tener especificado el --profile con su respectivo nombre de perfil.
Por lo anterior, tenemos que autenticarnos con el comando aws configure y validar con el comando aws sts get-caller-identity.
El token se especificará dentro del archivo plano de credenciales.
Vamos a listar las políticas para el usuario que será auditado:
Obteniendo información relevante para nuestra auditoria, es utilizando el ARN de la política del usuario auditado:
Luego de identificar los permisos para el rol comprometido, ya podemos iniciar la auditoria de seguridad.
Vamos a enfocarnos en realizar una enumeración básica sobre el servicio de ECS.
Vamos a validar todos los clusters disponibles:
Y ahora procedemos a validar la información relacionada a las tareas del cluster identificado:
Y finalmente, validemos los servicios del cluster identificado:
Vamos a revisar cada una de las tareas hasta encontrar la que esté relacionada al servicio previamente identificado llamado vault:
Ahora identifiquemos los contenedores del cluster:
Ahora vamos a modificar el estado del cluster para forzar el relanzamiento del docker llamado vault.
Para forzar la reprogramación debemos utilizar el permiso ecs:update-container-instances-state.
Este permiso nos permite actualizar el estado de cualquier instancia del cluster a DRANING. Establecer una instancia de cluster al estado DRANING hará que todas las tareas se reprogramen. Una vez que hayamos terminado, el clúster se reanudará normalmente y podremos tener acceso a ese docker.
En el paso anterior, hemos enumerado todas las tareas y sus correspondientes instancias ECS (Cabe resaltar, que en las instancias EC2 se ejecutan las tareas, y por tanto los contenedores docker). También vimos cómo está programado cada servicio y hemos descubierto una segunda instancia ECS en donde hay una tarea a la que no hemos tenido acceso anteriormente. Como esa tarea (VAULT) está programada como una REPLICA, ECS intentará reprogramarla en una instancia EC2 disponible si su instancia anfitriona actual se cae por alguna razón.
En pocas palabras vamos a forzar una reprogramación de la tarea vault a nuestra instancia.
Por lo anterior, tenemos que autenticarnos con el comando aws configure y validar con el comando aws sts get-caller-identity.
Las credenciales que serán usada en este perfil son las extraídas por el servicio de metadatos del EC2.
El token se especificará dentro del archivo plano de credenciales.
El token se especificará dentro del archivo plano de credenciales.
Para analizarlo gráficamente, podemos basarnos en la siguiente imagen que está relacionada a la tarea previamente identificada:
Cabe resaltar, que por medio del RCE nosotros nos tenemos acceso a la instancia EC2 con ID i-0e9d50542ec3d4df3.
Ahora simplemente cambiemos el estado del contenedor, para que automáticamente ECS asigne este contenedor a nuestra instancia comprometida:
Ahora simplemente, tenemos que esperar a que se reprograme el contenedor "Vault", esto se puede verificar ejecutando docker ps a través de la inyección de comando.
En la evidencia previa, podemos apreciar como en nuestra instancia aparece el contenedor VAULT que inicialmente no aparecía en el comienzo de la auditoria.
Ahora podríamos ejecutar cualquier comando sobre el contenedor VAULT:
Para finalizar este laboratorio, debemos visualizar un archivo de texto plano “secreto” en el contenedor de VAULT:
Windows:
Linux:
