AWS Pentesting - FLAWS

 CONTEXTO

flaws es una web con varios  desafíos creados por Scott Piper. Para resolverlos, hay que buscar fallos en configuraciones de aws.


Estoy usando el sistema operativo kali linux y tengo instalado aws cli.


Es necesario tener cuenta propia de aws (free tier suficiente).


NIVEL 1

El primer nivel está en flaws.cloud



Ya nos da una pista con la palabra bucket referenciando al servicio S3 de AWS. Además de para almacenamiento, podemos usarlo para servir páginas web estáticas.


Con wappalyzer lo confirmo.



Nota: En la vida real, pocas veces veremos un S3 expuesto, suele tener CloudFront (servicio CDN de AWS) por delante. Sigamos.


A la hora de encontrarnos con un S3, debemos preguntarnos:

  • ¿Podemos listar su contenido?
  • ¿Podemos subir archivos?

Desde la terminal, utilizando aws cli, vamos a intentar listar el contenido de ese S3.


aws s3 ls  flaws.cloud --no-sign-request


Gracias a la flag --no-sign-request enviamos la petición de forma anónima, es decir, no hace falta que tengamos credenciales de aws. Y viendo el resultado, vemos que es así. 



secret-... nos dice dónde está el segundo nivel.


NIVEL 2


El segundo nivel está en http://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud/


Este nivel nos dice que es similar al nivel 1, veamos si podemos volver a listar el contenido de este bucket de forma anónima.



Esta vez nos aparece un error, no tenemos acceso de forma anónima a listar el contenido del s3.


Vamos a probar de nuevo, pero esta vez, con una cuenta de aws real. Para ello, utilizar el comando aws configure y configurar con vuestras credenciales reales.



Ahora ya podemos listar y ver que secret-... nos dice dónde está el tercer nivel.


La diferencia del nivel 1 con el nivel 2, es que el primero deja a cualquiera de internet listar el contenido, por eso podemos hacerlo con la flag –no-sign-request, en cambio el nivel 2, permite a cualquier cuenta de aws listar el contenido, por eso no sirve la flag del nivel 1, pero sí que podemos ver el contenido con cualquier cuenta de aws, incluso la nuestra.


NIVEL 3


El nivel 3 empieza en http://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/


Nos dice que este nivel es parecido al anterior y que debemos encontrar una clave de AWS.


Volvemos a listar el contenido de este bucket.


Vemos que hay un directorio llamado .git, es decir, está subido un archivo git (un sistema de control de versiones), donde podemos encontrar antiguos commits con información interesante.


Vamos a ver si podemos traerlo a nuestro pc.


aws s3 cp --recursive s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/.git/ ./


Usamos cp para copiar del s3 a nuestro ordenador, la flag --recursive ya que dentro del directorio git hay mas carpetas y queremos traer todo, indicamos el bucket s3 y a donde lo queremos traer.



Vemos los logs con el comando git log (dentro de la carpeta que hemos descargado el archivo git) y hay uno de los commits con un mensaje interesante, veamos que tiene.



Tenemos unas claves de aws. Vamos a configurarlas en nuestra aws cli y ver si podemos ver otros buckets (la pista nos la da el enunciado que dice “algo con lo que listar otros buckets”).


Con estas credenciales podemos listar todos los buckets:



Vamos a por el nivel 4 (si intentamos ir al 5 o el 6 no podremos).


NIVEL 4

Ya que el ejercicio nos dice que hay una snapshot hecha, vamos a ver si podemos verla.



Sabiendo cual es el ID del snapshot, lo voy a copiar en mi cuenta de aws, con el fin de crear un volumen a partir de esa snapshot, lanzar un ec2 y montar ese volumen, así podré “tener acceso” al servidor web desde mi cuenta.



Una vez montado, encontramos en /home/ubuntu el usuario y la contraseña en un archivo .sh.


NIVEL 5


Es un ec2 con un proxy, que hace peticiones a donde indiquemos, por lo que si buscamos la ruta 169.254.169.254/latest/meta-data/iam/security-credentials/flaws nos dará las credenciales con las que podremos listar el contenido del bucket del nivel 6. Esa IP nos da acceso a información y metadata de la instancia. Esta petición solo se puede hacer desde dentro de la máquina EC2, por lo que nos valemos de esta “vulnerabilidad” SSRF (server-side-request-forgery) y hacemos que la propia ec2 con el proxy haga la petición, haciendo que se ejecute dentro del ec2 y dándonos acceso a la información.


NIVEL 6


Nos da unas claves de AWS, las configuramos y vemos que permisos tenemos, aunque ya nos indica que uno es SecurityAudit (ReadOnly).


Vamos a ver las políticas managed que tiene:


aws iam list-user-policies --user-name Level6


Ninguna.


Vamos a ver las que tiene inline:


aws iam list-attached-user-policies --user-name Level6



Vemos que tiene dos, vamos a ver qué hace cada una de estas. Para ello, primero necesitamos la versión.


Para ver la versión:


aws iam get-policy --policy-arn arn:aws:iam::975426262029:policy/MySecurityAudit


aws iam get-policy --policy-arn arn:aws:iam::975426262029:policy/list_apigateways


Con las versiones ya podemos ver que hace cada una (la lista de security es larga, no la voy a poner con capturas). 


aws iam get-policy-version --policy-arn arn:aws:iam::975426262029:policy/MySecurityAudit --version-id v1


aws iam get-policy-version --policy-arna rn:aws:iam::975426262029:policy/list_apigateways --version-id v1



Lo que sí vemos es que en la policy list_apigateways nos deja hacer GET a una API, pero aun no sabemos cual es exactamente, solo vemos *. Para ejecutar una api de apigateway se sigue esta estructura:


https://{api-id}.execute-api.{region}.amazonaws.com/{stage}/{recurso} 


Ya que podemos listar las funciones Lambda vamos a ver si hay algo interesante.



Con el rol de security podemos ver la policy de esta función lambda, y en esta, vemos otra API, solo nos hace falta el STAGE para ejecutarla y reemplazar ese *.


https://{api-id}.execute-api.{region}.amazonaws.com/{stage}/{recurso} 



Para saber el STAGE hacemos:


aws apigateway get-stages --rest-api-id <api_id> --region <región>



Ahora si podemos buscar en el buscador:


https://s33ppypa75.execute-api.us-west-2.amazonaws.com/Prod/level6




Con esto termina FLAWS. Buena forma de introducirse al pentesting de AWS. En caso de quedar atascado, estan las Hints (pistas) que la propia web ofrece. Trabajo increíble de Scott Piper, incluso tiene una segunda parte (flaws2).


No hay comentarios:

Publicar un comentario

AWS Pentesting - FLAWS

  CONTEXTO flaws es una web con varios  desafíos creados por Scott Piper. Para resolverlos, hay que buscar fallos en configuracion...