Vulnerabilidad en red social de Microsoft permite usar sus servidores como proxy

SO.CL es el nombre de la red social de Microsoft la cual permite, mediante una vulnerabilidad que afecta a uno de sus servidores, usar una IP de Microsoft como proxy.
La vulnerabilidad afecta al servicio que genera las minuaturas (thumbnail) de las imagenes que suben los usuarios a la red. Al insertar o enlazar una imagen, la red social llama a https://cdn2.so.cl/handlers/thumbnail entregandole mediante GET la URL de la imagen a mostrar. Este sistema de thumbnails no valida correctamente los parametros permitiendo generar request a servidores remotos de manera arbitraria.

La vulnerabilidad en si es un poco compleja de explotar, ya que no devuelve ningún valor, pero realizando algunas pruebas de concepto con un servidor de pruebas podemos analizar el comportamiento e imaginar distintas formas de explotarla.

La primera prueba a realizar será entregarle directamente una imagen en formato gif para que genere el thumbnail, usaremos la URL de pruebas https://zerial.org/socl.gif.

El sistema alojado en cdn2.so.cl generó el thumbnail correspondiente generando el siguiente request en el servidor zerial.org:

 168.62.163.190- - [30/Dec/2012:03:00:38 -0300] "GET /socl.gif HTTP/1.1" 200 160834

La dirección IP  168.62.163.190 desde la que se hizo el request corresponde a Microsoft Corporation. De esta forma, generamos un request desde el servidor de Microsoft a mi servidor de pruebas.

Hasta ahora está todo normal, ya que el servicio de thumbnails ha funcionado bien, fue a buscar la imagen desde la URL que le entregamos, la redimensionó y la mostró.

Ahora vamos a intentar con la misma imagen, pero modificando su extensión a .html.

El resultado es el mismo, indiferente si la extensión es html, gif, mp3 o cualquier otra, el servidor de microsoft realiza la petición al servidor remoto y nos muestra la miniatura.
Este es el primer problema, no valida correctamente la extensión del archivo. Si es un sistema para generar thumbnails debería validar al menos la extensión del archivo.

Ahora vamos a intentar generar un thumbnail de un archivo que no sea una image, por ejemplo un mp3. Probaremos con el archivo de audio https://zerial.org/ghost.mp3.

No nos muestra nada, ya que obviamente no puede generar un thumbnail de un mp3, sin embargo, si genera el request en el servidor de pruebas:

168.62.163.190 - - [30/Dec/2012:03:17:38 -0300] "GET /ghost.mp3 HTTP/1.1" 200 3901240

Desde la misma dirección IP que el request anterior cuando abrimos un archivo de imagen. El sistema no muestra ningun mensaje de error ni nada por el estilo, por lo tanto me atrevo a asumir que está intentando generar el thumbnail y como no puede, muestra la página en blanco.

Lo que haremos ahora es encontrar la forma de poder explotar esta vulnerabilidad para poder realizar ataques a otros sistemas. A modo de pruebas seguiré usando zerial.org pero llamaré a un archivo php simulando tener un sql-injection

Nuevamente nos devuelve una página en blanco pero nos genera el request en el servidor de pruebas

168.62.163.190 - - [30/Dec/2012:03:22:56 -0300] "GET /fake.php?id='%20or%20'1'='1 HTTP/1.1" 200 1476 "-"

De esta forma, si nuestro archivo fake.php fuese vulnerable a sql injection, estaría recibiendo la inyección ‘ or ‘1’=’1 desde la dirección IP de Microsoft.

Con el siguiente ejemplo podemos determinar el tiempo de timeout que tiene el servidor de microsoft, por ejemplo creamos un archivo php con una llamada a la función sleep(5), para que “espere 5 segundos”. Para poder tomar el tiempo de ejecución usaré cURL por la línea de comandos junto con time:

Podemos ver en la primera linea (real) que dice que el tiempo de ejecución fue 5,419 segundos. De esta misma forma, si ponemos un sleep(10) el tiempo de ejecución será 10 y así …

Con esto ya tenemos una información interesante, podemos ejecutar inyecciones SQL que tarden 10 segundos en ejecutarse.

¿Cual es el real alcance de esta vulnerabilidad?

Si bien podemos enviar request a sitios remotos y llenar los logs de un servidor con accesos desde la dirección IP de Microsoft o bien ejecutar llamadas a sitios con vulnerabilidades de inyección sql, yo creo que el real alcance de esta vulnerabilidad está en saber como explotar un SQL Injection explotando esta vulnerabilidad de SO.CL.
Por ejemplo, si conocemos un sistema que sea vulnerable a inyección sql que permita eliminar todos los registros de una base de datos, podemos fabricar una URL especialmente para ese ataque y que en los logs de acceso de la empresa afectada aparezca la IP de Microsoft como origen del ataque.

Disclaimer

Esta vulnerabilidad fue reportada al Microsoft Security Response Center (MSRC) siguiendo las instrucciones publicada por ellos mismos en su sitio web, el día 21 de Mayo del 2012. Sólo tuve respuesta del bot que recibe los incidentes, asignando el caso MSRC 12574. Respondí el correo para conocer el estado del incidente el día 4 de Junio del 2012 obteniendo la siguiente respuesta el 6 de Junio:

We are currently reviewing the issue to determine root cause and perform variant analysis.

ACTUALIZADO

La respuesta final por parte de los ingenieros de Microsoft, enviada el día 11 de marzo del 2013, fue:

Thank you for reporting this behavior to us. After further analysis, our team found the issue to be by design. There were various solutions discussed and we found the current implementation meets the current needs for this feature at the scale required. In the future, we will implement a solution which will provide a key for every thumbnail creation request, which will address the specific issue you reported.

4 comentarios

  1. Muy buen artículo, la verdad es que siendo Microsoft deberían darse más prisa solucionando estas cosas. Aparentemente podría pensarse que es una vulnerabilidad poco peligrosa pero es cierto que puede resultar muy perjudicial para Microsoft ya que podrían acusarle de ataques que realmente hacen otros.

  2. Mmm… encuentro demasiada rebuscada la “vulnerabilidad”, en primera la extensión del archivo es un string más, no tiene ninguna implicancia en el contenido del archivo. Puedo tener un foto.jpg que venga con un mimetype application/php o en el caso de Microsoft application/x-csh y un código.

    La foto a subir puede venir un query string y sería tonto que no lo aceptara, muchas imagenes son generadas dinámicamente y si yo como usuario uso una aplicación online en donde retoque la foto y me la exporta como una url de la forma https://www.fake.tld?user=pepe&changes=sd98s098d

    Es de esperarse que al copiar https://www.fake.tld?user=pepe&changes=sd98s098d en el thumbnail de Microsoft me genere la misma foto, y no me corte el query string (en cuyo caso no pasaría nada).

    Así es como funciona internet, no encuentro una solución para esto. Si tengo un sistema que tiene problemas de SQL Injection y en los log veo http://cdn2.so.cl/handlers/thumbnail?url=http://misitio.tld?name=pepe‘ OR 1=1

    Es de esperarse que:
    1) http://cdn2.so.cl/handlers/thumbnail sólo genera un thumbnail.
    2) El error es mio.

    Simplemente todos los servicios de thumbnail funcionan así.

  3. Hola Rodrigo. Primero que todo gracias por el feedback.

    Respecto a lo que escribes, si bien la extension del archivo no es la vulnerabilidad en si, porque todos sabemos que -como bien dices- es un string mas, no significa que tipo de archivo es, si sirve para realizar una primera validacion; por ejemplo aceptar imagenes con extension mp3 no es valido (indiferente del tipo de archivo), pienso yo. Pero insisto, esa no es la vulnerabilidad en si, la falla esta en poder utilizar esa funcionalidad como proxy para hacer peticiones GET a otros servidores y con eso efectuar ataques dejando rastro la IP de Microsoft. Si tienes un SQL Injection previamente preparado para que elimine o modifique registros de una base de datos, puedes utilizar este servicio para explotarlo.
    Respecto a las validaciones, dices que “simplemente asi funcionan los servicios de thumbnail”, pero no es tan asi. Este tipo de servicios si van a ofrecerse mediante una API publica deben tener la seguridad que requiere una API, es decir autenticacion y esas cosas. Si solo lo usaras para tu servicio (es decir, uso exclusivo para SO.CL), debees manejar tokens de seguridad para prevenir que usuarios o aplicaciones externos a la red social hagan uso de la funcionalidad.

    saludos

  4. Como todo el blog excelente.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.