miércoles, abril 08, 2015

Cómo explotar un SSRF (Server Side Request Forgery) y hacer un XSPA (Cross Site Port Attacks) a una DMZ

Las vulnerabilidades SSRF (Server Side Request Forgery) y los ataques de XSPA (Cross Site Port Attacks) son dos fallos de seguridad que van casi siempre de la mano. Los bugs de SSRF se producen en aplicaciones web inseguras que permiten a un atacante forzar al servidor web a realizar peticiones desde dentro del sistema hacia el exterior. Usando esas conexiones, los ataques de XSPA tratan de conocer, en base a las respuestas obtenidas, la lista de puertos que se encuentran abiertos o por el contrario cerrados en el servidor al que se fuerza la conexión.

Figura 1: Cómo explotar un SSRF y hacer un XSPA a una DMZ

Es importante tener claro que estas vulnerabilidades afectan al Back-End y que vienen conducidas por una mala validación en el Front-End o API al poder ser manipuladas las direcciones a las que se le van a realizar peticiones desde el Back-End. La principal ventaja para un atacante de que las peticiones sean realizadas desde dentro de la red en la que se encuentra el sistema vulnerable es que le van a permitir acceder a sitios que de otra manera no podría (pivoting), tal como sucede cuando estamos conectados a nuestro router y podemos acceder a las maquinas conectadas a nuestra red local.

SSRF & XSPA en buscadores y paneles de administración con CSPP 

Estos fallos son muy típicos, y ya los hemos visto en un buen número de sitios. En el artículo de Buscadores como arma de destrucción masiva se hablaba de posibles ataques de SSRF utilizando la indexación maliciosa o los agregadores de noticias, que permitían por ejemplo que un servidor lanzara un ataque de SQL Injection sin interacción alguna del atacante.

Figura 2: Ejemplo de utilización de un agregador de noticias para realizar ataques SSRF

Un caso curioso de SSRF son los paneles de administración expuestos en Internet, como sitios de configuración de impresoras HP que permiten escanear la DMZ completa, o los casos de bugs de Connection String Parameter Polution, tanto de bases de datos MySQL como de tecnologías .NET. Con ellos hemos visto lo fácil que es realizar ataques de XSPA (Cross Site Port Attacks) aprovechando estas vulnerabilidades de SSRF o CSPP, como en el caso de las herramietnas MyLittleAdmin.

Figura  3: XSPA en MyLittleAdmin for SQL Server

Como se ve, aprovechando la ventaja de que sea el Back-End el encargado de realizar peticiones internamente y que estas a su vez puedan ser manipuladas, permitiría a un atacante apuntar a direcciones IP internas y ya sea visualizando la respuesta o en base a tiempos dibujar un mapa de los activos de la red interna o conocer los puertos abiertos. A continuación les dejo una serie de enlaces donde se documenta cómo explotaron este fallo en sitios de Yahoo!, Facebook o Coinbase, por poner solo algunos ejemplos:
Yahoo! SSRF/XSPA Vulnerability
XSPA / SSRF bug with Facebook's Developer Web Application
SSRF/XSPA Bug in Coinbase
SSRF/XSSA usando ScreenShots

El siguiente caso que les traigo me pareció interesante, vendría a ser algo así como SSRF/XSSA aprovechando un sistema implementado para hacer ScreenShots en aplicaciones web. Esto es algo similar a lo que se publicó por aquí en el artículo de "Jugando con los ojos", donde aprovechando un sistema de captura de pantallas en distintos navegadores se hacían ataques a terceros servidores.

En este caso se trata de una aplicación web hecha en ruby on rails que a través de un sencilla interfaz web, recibe una URL o dominio que luego es enviada a un servicio externo que consulta en su base de datos quién es el propietario del dominio - lo que viene a ser un Whois -. Una vez el servicio Whois devuelve una respuesta a la aplicación web, ésta - además de imprimir dichos datos a través del navegador- seguidamente realizará una captura de pantalla levantando un navegador que visitará la misma dirección.

Figura 4: Funcionamiento normal de la web con el screenshot de Google

Como se puede ver en el navegador aparece en la parte inferior derecha una imagen de la página principal de google.com, al inspeccionar el elemento se puede comprobar que el nombre de la imagen parece ser un Hash MD5 por los 32 caracteres de longitud, que efectivamente corresponde a la concatenación del dominio más un slash tal que así google.com/.

Figura 5: Nombre de la imagen vinculada al screenshot

Escaneando la DMZ interna

Entonces, recordando la ventaja que supone que sea el servidor web el encargado de realizar la petición, por su conectividad con el resto de máquinas de su red interna, se podría realizar un escaneo completo de la DMZ. Para ello sería cuestión de ir probando a enviar por el parámetro uri, diferentes direcciones IP locales con la esperanza de obtener capturas de pantalla de máquinas de la red interna que tengan corriendo en el puerto 80 aplicaciones con interfaz web. Para ello bata con lanzar varias peticiones enviado varias direcciones IP locales, desde la 192.168.0.1 a la 192.168.0.24, y una vez el servicio externo hubiese procesado la dirección IP y devuelto la respuesta, se realizaría la captura de pantalla contra el servidor web en dicha dirección IP.

Figura 6: Resultados del escaneo completo de la DMZ

Ya por último teniendo un listado de las rutas a las imágenes que contiene las capturas realizadas, bastaría con acceder a cada una de ellas para comprobar si contenían algo interesante o simplemente estaban en blanco.

Figura 7: Resultados obtenidos con Burp

Después de realizar peticiones e intentar acceder a cada uno los enlaces con las imágenes, pude ver que algunas tenían un peso mayor que otras, dando a entender que algunas capturas realizadas contra algunas direcciones IP locales SÍ contenían información,  y por lo consiguiente alguna aplicación web corriendo sobre la máquina con dicha dirección IP. Ordene el listado de las imágenes por peso y fui visualizando cada una de ellas, algunas contenían información muy sensible y otras simplemente el típico banner de un servidor Apache.

Nota de reflexión final

Por supuesto, este tipo de vulnerabilidades son muy peligrosas, ya que desde el servidor no solo se puede hacer el escaneo de puertos, sino que se pueden hacer ataques de SQL Injection a servidores internos, Heartbleed o ShellShock, por poner algunos casos, así que hay que tener mucho cuidado con ellas.

Autor: Ricardo Martín (@ricardo090489)
Security QA Engineer en Eleven Paths

1 comentario:

asdsdadasdsadasdas dijo...

Buen articulo Ricardo! Muy interesante :)

Ts

Entrada destacada

10 maneras de sacarle el jugo a tu cuenta de @MyPublicInbox si eres un Perfil Público

Cuando doy una charla a algún amigo, conocido, o a un grupo de personas que quieren conocer MyPublicInbox , siempre se acaban sorprendiendo ...

Entradas populares