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.
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.
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.
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:
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.
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/.
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.
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.
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
 |
| 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 VulnerabilitySSRF/XSSA usando ScreenShots
• XSPA / SSRF bug with Facebook's Developer Web Application
• SSRF/XSPA Bug in Coinbase
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
Buen articulo Ricardo! Muy interesante :)
ResponderEliminarTs