Play es un framework para el desarrollo de aplicaciones webs de código abierto escrito en Scala y Java que sigue el patrón de arquitectura Modelo, Vista, Controlador (MVC). Play está pensado para conseguir un alta productividad y la construcción de aplicaciones con velocidad que cumple con los modelos de ingeniería de desarrollo ágil de software y que además integra los componentes y las API necesarias para el desarrollo moderno de aplicaciones webs. Todo esto ha hecho que se haya hecho muy popular. Muchos de los proyectos que hacemos internamente en Eleven Paths trabajan con este framework, es por ello que sea habitual que durante las auditorías, se le acaben lanzando pruebas con Faast y desde el equipo de QA a todos los vectores posibles, entre ellos contra todos los parámetros transmitidos.
El 0day de XSS en Play Framework
Algún tiempo atrás durante anteriores pruebas contra alguno de nuestro productos, me percaté de un comportamiento extraño al colocar dos puntos al principio del valor de algunos parámetros, más específicamente cuando se usaba el parámetro para renderizar la URL “@{Controller.action(URLparameterWithInjection)}”, sin importar si era enviado por GET o por POST.
Al principio no le dimos la suficiente transcendencia cuando en realidad la variación en la respuesta producida al enviar este carácter al principio del valor de los parámetros, implicaba que lo siguiente que acompañara a los dos puntos dependería de que fuese o no encodeado el resto del mensaje, tal y como se ve en esta sección de código.
Este comportamiento abría las puertas a realizar casi cualquier tipo de inyección XSS, dejando cientos de webs vulnerables, expuestas a ser objetivo de este tipo de ataque derivando con ello robos de cookies, modificación de la capa de presentación del contenido, redireccionamiento a otros sitios, etcétera, por lo que se lo reportamos para que lo corrigieran tal y como publicamos en el blog de Eleven Paths.
PoC: Ataque de Phishing usando el bug de XXS
Como prueba de concepto he desplegado un sencilla aplicación con Play Framework en su versión 1.3.0, aunque me hubiese servido cualquiera de estas versiones 1.2.0 - 1.2.7. Creé una página en la raíz de mi servidor web que renombre como “test” la cual recibirá e imprimirá el valor del parámetro “url”.
El ataque que se va a mostrar, pretende robar las credenciales con una técnica algo más complicada o rebuscada de lo habitual pero que no por ello inservible o a pasar por alto. El primer paso será conseguir una imagen transparente http://disaster-lab.itsm3.com/images/transp.png que posteriormente inyectaré para superponer encima del botón del login de entrada a la administración de la web. De esta forma se pretende que una vez la víctima pulse sobre el botón - cuando en realidad pulsa sobre la imagen transparente - se inicie el evento “onclick” de la imagen logrando mediante JavaScript redireccionar a la víctima a una copia exacta del login de su portal de administración “phishing”. Este va a ser el código que inyectaré en el parámetro vulnerable para darle forma a lo explicado anteriormente.
Por último les dejo un vídeo que muestra en la respuesta cómo queda la inyección sin y con los dos puntos, además del ataque del que se ha hablado superponiendo la imagen y robando las credenciales de la víctima.
Figura 4: PoC de explotación de XSS en una aplicación Play Framework
Una semana después Play lanzo un parche resolviendo el bug de seguridad y liberando varias versiones que como comprobé, mitigaban la vulnerabilidad:
Para terminar, me gustaría dejar aquí una referencia a Playtch, uno de los plugins que se presentaron para el concurso de Latch Contest que permite utilizar Latch en aplicaciones Play de forma sencilla. Aquí tienes un vídeo de cómo funciona y aquí tienes el plugin.
Autor: Ricardo Martín (@ricardo090489)
QA Security Engineer de Eleven Paths
 |
| Figura 1: Ataque de Phishing usando bug de XSS |
El 0day de XSS en Play Framework
Algún tiempo atrás durante anteriores pruebas contra alguno de nuestro productos, me percaté de un comportamiento extraño al colocar dos puntos al principio del valor de algunos parámetros, más específicamente cuando se usaba el parámetro para renderizar la URL “@{Controller.action(URLparameterWithInjection)}”, sin importar si era enviado por GET o por POST.
Al principio no le dimos la suficiente transcendencia cuando en realidad la variación en la respuesta producida al enviar este carácter al principio del valor de los parámetros, implicaba que lo siguiente que acompañara a los dos puntos dependería de que fuese o no encodeado el resto del mensaje, tal y como se ve en esta sección de código.
 |
| Figura 2: Código fuente que procesa el parámetro URL |
Este comportamiento abría las puertas a realizar casi cualquier tipo de inyección XSS, dejando cientos de webs vulnerables, expuestas a ser objetivo de este tipo de ataque derivando con ello robos de cookies, modificación de la capa de presentación del contenido, redireccionamiento a otros sitios, etcétera, por lo que se lo reportamos para que lo corrigieran tal y como publicamos en el blog de Eleven Paths.
PoC: Ataque de Phishing usando el bug de XXS
Como prueba de concepto he desplegado un sencilla aplicación con Play Framework en su versión 1.3.0, aunque me hubiese servido cualquiera de estas versiones 1.2.0 - 1.2.7. Creé una página en la raíz de mi servidor web que renombre como “test” la cual recibirá e imprimirá el valor del parámetro “url”.
El ataque que se va a mostrar, pretende robar las credenciales con una técnica algo más complicada o rebuscada de lo habitual pero que no por ello inservible o a pasar por alto. El primer paso será conseguir una imagen transparente http://disaster-lab.itsm3.com/images/transp.png que posteriormente inyectaré para superponer encima del botón del login de entrada a la administración de la web. De esta forma se pretende que una vez la víctima pulse sobre el botón - cuando en realidad pulsa sobre la imagen transparente - se inicie el evento “onclick” de la imagen logrando mediante JavaScript redireccionar a la víctima a una copia exacta del login de su portal de administración “phishing”. Este va a ser el código que inyectaré en el parámetro vulnerable para darle forma a lo explicado anteriormente.
"/></a> /<div style="position: absolute; z-index:1;right:710px; top:180px; border: none; border: 0;"/> /<img src="http://disaster-lab.itsm3.com/images/transp.png" height="50" width="70" onclick="window.location.href='http://disaster-lab.itsm3.com/phishing.htm'"/> /</div/> /<a href="Tras ser inyectar el código JavaScript se puede ver en la respuesta como los dos puntos logran que el resto del mensaje no sea encodeado y visiblemente funcional.
 |
| Figura 3: Código XSS inyectado en la aplicación de ejemplo en Paly |
Por último les dejo un vídeo que muestra en la respuesta cómo queda la inyección sin y con los dos puntos, además del ataque del que se ha hablado superponiendo la imagen y robando las credenciales de la víctima.
Figura 4: PoC de explotación de XSS en una aplicación Play Framework
Una semana después Play lanzo un parche resolviendo el bug de seguridad y liberando varias versiones que como comprobé, mitigaban la vulnerabilidad:
• Play 1.2.5.5Integración de Latch en aplicaciones Framework
• Play 1.2.6.1
• Play 1.2.7.2
• Play 1.3.1
Para terminar, me gustaría dejar aquí una referencia a Playtch, uno de los plugins que se presentaron para el concurso de Latch Contest que permite utilizar Latch en aplicaciones Play de forma sencilla. Aquí tienes un vídeo de cómo funciona y aquí tienes el plugin.
Figura 5: Playtch, integración de Latch en aplicaciones con Play Framework
Autor: Ricardo Martín (@ricardo090489)
QA Security Engineer de Eleven Paths
No hay comentarios:
Publicar un comentario