jueves, noviembre 24, 2016

La historia del bug de "Open Proxy" en Microsoft.com

Durante el mes del verano estuvimos haciendo unas pruebas con Faast sobre varios sitios hacking friendly para ver cómo se comportaba la nueva versión de nuestro motor. Los resultados fueron espectaculares, y por el camino localizamos varias vulnerabilidades y debilidades en Microsoft y en Apple. Alguna de las debilidades las he comentado por aquí, como fue el caso de HPP (HTTP Parameter Pollution) en Apple.com, los certificados digitales en su CDN o el SSRF en Microsoft.com, por poner algunos ejemplos de lo que íbamos encontrando.

Figura 1: La historia del bug de "Open Proxy" en Microsoft.com

Aparte de las debilidades, localizamos varias debilidades más serias, que por supuesto reportamos a los equipos de seguridad de las empresas para que los corrigieran, y uno de ellos fue este Open Proxy que Microsoft ha solucionado ya, y nos ha agradecido en el último paquete de créditos.

Figura 2: Agradecimiento de Microsoft a los Security Researchers en Septiembre-Octubre

El bug fue descubierto por el motor de pentesting persistente de Faast, en una de las URLs de Microsoft.com. Un bug de Open Proxy permite a un atacante utilizar un servidor publicado en Internet para ocultar su dirección en un ataque o para navegar a servidores internos de la DMZ

Figura 3: Bug de Open Proxy descubierto en Microsoft.com con Faast

También se pueden hacer cosas más sutiles, dependiendo de la implementación concreta, como cachear peticiones DNS, conseguir descargar ficheros maliciosos para hacer saltar las protecciones de seguridad, o algún que otro sutil escenario.

Figura 4: Conexión a Facebook a través del Open Proxy de Microsoft.com
En nuestro caso, como PoC para reportar el bug, hicimos un par de pruebas. La primera de ellas fue con una dirección de Internet, como el caso de Google.com, y como se puede ver el servidor de Microsoft.com hace de Proxy y trae la información solicitada.

Figura 5: Conexión a Google a través de Open Proxy

El segundo de los casos, algo más sencillo, una petición a Localhost para ver si se podía acceder a la información de servidores en la DMZ no publicados.

Figura 6: Conexión a Localhost a través del Open Proxy de Microsoft.com

A partir de ahí hicimos alguna prueba, para ver si podíamos acceder con direcciones locales escritas en IPv4, en IPv6 o codificadas en hexadecimal, para ver el impacto total de este bug.

Figura 7: Conexión a localhost codificada en hexadecimal

Al final, Microsoft lo corrigió y ya está resuelto, y nosotros nos quedamos contentos y felices por haber ayudado y comprobar que nuestro Faast cada día mejora un poco más.

Saludos Malignos!

Entrada destacada

Infraestructuras Críticas y Sistemas Industriales: Auditorías de Seguridad y Fortificación de @0xWord

Desde hoy está disponible a la venta un nuevo libro de 0xWord centrado en la seguridad de los Sistemas Industriales y las Infraestructuras...

Entradas populares