Cómo usar una "debilidad" de SSRF en Microsoft.com para hacer una PoC de SQL Injection

Durante este verano hemos estado muy activos reportando algunas vulnerabilidades descubiertas por el motor de Faast en algunas empresas tecnológicas. Utilizando la visión del Pentesting Persistente que marca nuestra forma de ver cómo se debe abordar la seguridad de los sistemas expuestos a Internet de las empresas, en entornos hacking friendly hemos estado reportando un buen número de bugs que están corrigiendo.

Figura 1: Cómo usar una "debilidad" de SSRF en Microsoft.com para hacer una PoC de SQL Injection

Hoy os vengo a hablar de uno de estos reportes que no ha sido tomado como un bug de seguridad, y que por tanto no va a ser modificado, para que veáis cómo funciona esto. Se trata de un Server-Side Request Forgery en una web pública de Microsoft.com. Los SSRF son "debilidades" de las aplicaciones web que permiten a un atacante inyectar una URL en el sistema que fuerza al servidor de backend a hacer una petición a un servidor controlado por el atacante, tal y como se describe en el CWE (Common Weaknesses Enumeration) del Mitre que tenéis a continuación. Dependiendo del entorno, esta debilidad se puede convertir en un "bug" o no.

Figura 2: Descripción de las debilidades Server-Side Request Forgery (SSRF)

Este tipo de "debilidades" pueden ser utilizados en muchos entornos para conseguir otros objetivos como se explica en el libro de Hacking Web Technologies donde hablamos de ella. Desde hacer un escaneo de puertos de un servidor de forma anónima con un XSPA (Cross-Site Port Attack) hasta atacar un servidor con un SQL Injection. El peligro además es que, como el que realiza la petición es un servidor de la organización, este podría ser utilizado para hacer los ataques de XSPA o SQLi a servidores internos de la DMZ, como se explica en este artículo que os dejé publicado hace poco más de un año "Cómo usar un SSRF para hacer un XSPA a un servidor de la DMZ".

SSRF en Microsoft.com

En el caso de Microsoft el SSRF se encuentra en una URL pública, accesible por cualquiera desde Internet, que se utiliza para acceder a un Feed RSS. Éste es un entorno clásico para localizar este tipo de debilidades, tal y como se describía en el artículo de "Utilizar los Buscadores como arma de destrucción masiva" y en una web corporativa como la de Microsoft.com tal vez no debería estar público. Sin embargo, es verdad que algunos sistemas necesitan que esto funcione así y si ellos han determinado que no es un problema será que lo tienen controlado y no existe riesgo alguno en que esté público.

Figura 3: Confirmación de que el MSRC lo ha investigado y no hay riesgo

Sea como fuere, ya que en el artículo de hace un año nuestro compañero Ricardo usó el SSRF para hacer un XSPA, ayer le pedí a otro compañero de ElevenPaths - en este caso al gran Ioseba Palop que está cuidando el core de Faast con mimo y ternura desde hace años - que preparase una PoC con un SQL Injection, para que se viera cómo funciona esto, y lo tenéis en el siguiente vídeo.

Figura 4: Ataque SQLi a un servidor web vía SSRF en Microsoft.com

La demo es muy sencilla, hemos dejado una web vulnerable a un SQL Injection que permite hacer un Shutdown, es decir, hemos dejado corriendo el servidor SQL Server con privilegios de administrador a propósito, para hacer que el servidor de Microsoft.com, a través del SSRF, apague el motor de bases de datos desde Internet.

Esto es algo así como cuando Leonard, Koothrappali, Sheldon y Wolovich apagan y encienden las luces del salón a través de Internet solo por ver que se puede hacer, pero si ese servidor fuera uno interno en la DMZ de Microsoft, probablemente funcionaria igualmente. Sí, están todos menos Penny.

Figura 5: Todos menos Penny felices por encender las luces desde Internet

Este tipo de debilidades son importantes en muchos entornos, por eso nosotros prestamos mucha atención a todas ellas en nuestra knowledge base, pero a veces los equipos de seguridad las evalúan y deciden que el riesgo es bajo y no deben aplicar ninguna medida correctora más allá de las que tienen, como en el caso del HTTP Parameter Pollution de Apple.com, donde no implicaba riesgos de seguridad a pesar de existir la debilidad en la aplicación web.

Saludos Malignos!