En la etapa de enumeración, se identifico que la aplicación web  posee funciones para llevar acabo tareas corporativas como lo es la emisión de facturas. En este apartado, como podemos observar los usuarios que utilizan la aplicación tienen la posibilidad de previsualizar el documento mediante un visor de PDF antes de finalizar la creación.

Figura 001 – Visor PDF

A primera vista, algo que denota atención es que al usar esta función para ver el documento PDF la aplicación abre una pestaña que pertenece al mismo dominio de la organización y un contenido cifrado en base64. Este mismo pertenecía a un directorio interno del servidor. Por lo tanto, procediendo con la lógica de la aplicación, si nosotros manipulamos dicho directorio definido por el sistema, ¿Será posible la lectura de ficheros internos?

En la siguiente imagen en contenido en base64 pertenece al fichero /etc/hosts:

Figura 002 – Solicitud encodeada en base64

Para nuestra sorpresa, al recibir la respuesta del servidor podemos observar el contenido del fichero que especificamos con anterioridad. Lo que significa podemos confirmar que es posible la lectura de ficheros internos de manera arbitraria.

Figura 003 – Fichero hosts

Es momento de indagar un poco mas en el servidor para enumerar los potenciales usuarios que nos permitan obtener información sensible de algún servicio como lo es el protocolo de SSH, para lograr un acceso de manera remota. A simple vista uno de los usuarios que habría que enumerar por lo que tiene establecida una carpeta en el directorio /home/ es ec2-user.

Figura 004 – Fichero /etc/passwd

Llegados a este punto, podemos leer el fichero que pertenece a la clave privada del servicio de SSH que utiliza el usuario ec2-user para autenticarse por medio de este mismo.

Figura 005 – Llave RSA

En este punto ya tenemos la clave del fichero id_rsa del usuario ec2-user. Esta la procedemos a convertir en formato john para poder realizar un ataque de fuerza bruta con John The Ripper. Al finalizar el proceso tal y como se ve la clave del usuario es 12345678.

Figura 006 – Password crackeada

Continuando con la enumeración logramos obtener el contenido del fichero bash_history. Este almacena un historial de los comandos utilizados por el usuario. Asimismo, localizamos un repositorio privado de bitbucket.

Figura 007 – Contenido del fichero bash_history

Tras conseguir la key privada y no poder autenticarnos contra la instancia de AWS, procedemos a clonar el repositorio de Bitbucket. Esto es posible ya que con anterioridad definimos la clave privada en nuestra carpeta local del servicio de SSH.

Figura 008 – Repositorio privado

Llegados a este momento, observando los ficheros podemos confirmar que el repositorio es todo el código fuente de la aplicación. Asimismo, identificamos un fichero de configuración que almacena varias contraseñas para distintos servicios como lo es MySQL y SFTP, pero vamos a centrarnos en las credenciales del servicio de AWS.

Figura 009 – Divulgación de información

Después, definimos las credenciales en el fichero de configuración de la herramienta de AWS-cli para interactuar con el servicio de Amazon y recibimos una respuesta verificando que son válidas.

Figura 010 – Identificación de usuario a través de AWS-Cli

El siguiente movimiento es intentar crear un usuario con todos los privilegios para esto utilizaremos la herramienta Nimbustratus. Esta herramienta contiene funciones que permiten a un atacante realizar acciones de reconocimiento y post explotación en servicios de AWS.

Figura 011 – Creación de usuario con privilegios

Hasta el momento, ya tenemos un usuario con todos los privilegios. Por lo que, para provocar un impacto crítico y afectar a todas las instancias de la organización, volvemos a emplear AWS-cli para establecerle una contraseña al usuario IAM especificado, en este caso el que creamos con anterioridad. Tras otorgarle esta, podremos acceder a los servicios de Amazon Web Services a través de la consola de administración de Amazon.

Figura 012 – Usuario establecido para acceder vía consola

Posteriormente, ingresamos al apartado de la consola de AWS y proporcionamos las credenciales para el usuario.

Figura 013 – Portal de login AWS

Finalmente, tras iniciar sesión, logramos ver todas las instancias creadas por la organización las cuales podrían administrarse con total albedrío, provocando una gran perdida económica a la organización.

Figura 014 – Infraestructura AWS comprometida