EC2_SSRF
Lab: CloudGoat
Laboratorio
En este apartado se observará el ejemplo utilizando el laboratorio cloudgoat el escenario ec2_ssrf. 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
El desarrollo de este ejercicio puede llegar a consumir recursos económicos dentro de las cuentas de AWS.
Objetivo: Invocar la función de Lambda "cg-lambda-[ CloudGoat ID ]".
Configuración Inicial
Checar instalación de CloudGoad en:
Privesc-PathsLanzar el escenario con
./cloudgoat.py create ec2_ssrf
Configurar las credenciales iniciales al finalizar el comando anterior
aws configure --profile solus
Explotación
Como en toda fase de pentesting, primero se inicia con la enumeración, en este caso se hará uso de la herramienta cliam, pero se puede hacer de manera manual o con otras herramientas:
cliam aws enumerate iam s3 ec2 lambda --profile solus
Al parecer el usuario tiene capacidad de list sobre el servicio lambda de AWS, el objetivo de del laboratorio es ejecutar la función "cg-lambda-[ CloudGoat ID ]", se procede a buscar e intentar ejecutar la función:
aws lambda list-functions --profile solus
Como se observa en la salida, se puede saber el nombre de la función "cg-lambda-ec2_ssrf_cgiddojqir0rks". También se observar variables de ambiente que contiene las credenciales del rol que se conecta con la instancia EC2, procedemos a intentar ejecutar la función
aws lambda invoke --function-name cg-lambda-ec2_ssrf_cgiddojqir0rks ./out.txt --profile solus
Al parecer, el usuario inicia no tiene permisos de ejecución sobre lambdas, se procede a configurar las llaves encontradas en la función y enumerar:
aws configure --profile lambda
aws sts get-caller-identity --profile lambda
Al realizar la enumeración, parece que el perfil lambda tiene full permisos en los servicios EC2
Se procede intentar listar las instancias en la nube
Existe una instancia en la nube que ofrece una IP publica con un DNS, se procede a realizar OSINT sobre ese dominio para saber que servicios ofrece:
sudo nmap -sS -sV -T4 -Pn domain
Al parecer, la computadora que corre sobre el servicio EC2 es un Ubuntu que expone el puerto 80 para dar servicio de http con el framework Node.js, procedamos a consumir ese servicio por medio de un navegador web:
Al entrar por la web, el aplicativo expone un error indicando sobre un parámetro faltante en la petición, al colocarlo se obtiene lo siguiente:
El aplicativo, parece hacer una llamada sobre el parámetro y exponer el valor de entrada en el aplicativo, en un péntesting web se puede realizar diferentes ataques, como XSS, OS Inyection, entre otros, en este caso el aplicativo es claro que trata de hacer una petición a otro sitio, al coloral el valor www.google.com se puede observar esta acción:
Se tiene que hacer explotación de la vulnerabilidad conocida como SSFF. 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.
Como lo estudiado previamente en este blog en la entrada:
EC2Existe un End Point en AWS al cual todas las maquinas EC2 puede consumir de manera interna para la consulta de los metadatos, estos metadatos son ocupados por las instancias para configurar o administrar la instancia en ejecución, estos metadatos de instancia se dividen en categorías, como, por ejemplo, nombre de host, eventos y grupos de seguridad.
Metadatos de instancia y datos de usuario - Amazon Elastic Compute CloudAmazon Elastic Compute CloudComo indica la documentación de amazon AWS, estos metadatos no está protegidos criptográficamente, entonces aprovechando la vulnerabilidad del sitio web, se puede realizar una llamada sobre en endpoint http://169.254.169.254/latest/meta-data para tratar de consumir estos metadatos.
curl http://domain.com/?url=http://169.254.169.254/latest/meta-data
En este punto, se pueden listar las carpetas y la información valiosa, un servicio que es interesante de consumir es el siguiente:
curl http://domain.com/?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/rol
Esta api, permite generar nuevas llaves de acceso para el rol / usuario que administra la Instancia EC2, se procede a configurarlas y enumerar
¿Qué hacer cuando se tienen credenciales? enumerar, enumerar y enumerar
Al parecer este rol solo tiene acceso a listar buckets, pues listemos buckets s3
aws s3 ls --profile ec2
¿Se podrá listar el contendio y descargar archivos? ¡Pongámoslo a prueba !
aws s3 ls s3://cg-secret-s3-bucket-<cloudgoat_id> --profile ec2
aws s3 cp s3://cg-secret-s3-bucket-<cloudgoat_id>/admin-user.txt ./ --profile ec2
cat admin-user.txt
Al parecer, este bucket es para guardar un archivo muy secreto donde contiene las credenciajes de administrador de algo... encontramos credenciales, procedemos a configurarlas y usarlas, a ver si con este usuario podemos ejecutar la función inicial:
¿Conque shepard ? ejecutemos la función lambda inicial y obtengamos la bandera
Última actualización