Unos trucos para pasar el filtro AntiXSS en Chrome y Safari

Uno de los proyectos estrella de Eleven Paths es el sistema de Pentesting Persistente o Pentesting Continuo que hemos bautizado como Faast. En este servicio el motor en el core se dedica a implementar un análisis extensivo, exhaustivo y continuo dirigido por una base de conocimiento en forma de plugins que van buscando todo tipo de vulnerabilidades de seguridad en un sistema.

Dentro de la elaboración de Faast toca lidiar diariamente con nuevas formas de detectar y explotar las vulnerabilidades, y en uno de esos días nuestro compañero Ioseba Palop, Software Architect de Faast, se topó con una forma de saltarse el filtro Anti-XSS que implementa Webkit, y que por tanto afectaba a los navegadores Google Chrome y Apple Safari.

Desde el Laboratorio de Eleven Paths en Málaga nos pusimos en contacto con el equipo de seguridad ed Google Chrome el 23 de Octubre de 2013 y con el equipo de seguridad Apple Safari para reportarles este issue. Google respondió derivando el fallo al equipo de Chromium que lo arregló a los pocos días, lo que ha hecho que en la última versión de Google Chrome esté ya resuelto.  En el caso de Apple Safari no hay todavía solución, pero nos han contestado que están solucionándolo.

El fallo en el atributo srcdoc

El fallo que descubrió nuestro compañero se basa en hacer un uso incorrecto del atributo srcdoc de la etiqueta IFRAME, incluido en la definición de HTML5. Para realizar un ataque XSS con éxito en el navegador Google Chrome usando este fallo, la web debía incluir un IFRAME y debería ser capaz de leer cualquier atributo de este elemento desde los parámetros de llamada HTTP - por GET o por POST - sin aplicar filtrado de caracteres. El siguiente código de ejemplo es que se envió para demostrar el fallo.

Después, en el parámetro IFRAME, el atributo srcdoc se puede incluir con código JavaScript. Como se puede ver Google Chrome no lo filtra y se ejecutará el código inyectado. Para reproducir la PoC, debería haber una página con un IFRAME similar a éste. 

Figura 1: El iframe que se va a utilizar para ejecutar el código script

Y la inyección HTML en el parámetro src sería la que se ve a continuación:

Figura 2: Forma en la que quedará la inyección

Ahora la víctima podría visitar la siguiente URL y se ejecutaría el código script: 

Figura 3: Inyección y ejecución del código en un Google Chrome vulnerable

En Google Chrome está resuelto ya, pero en Apple Safari se puede comprobar que sigue funcionando este truco y el código se ejecuta en la última versión disponible para las últimas actualizaciones del sistema.

Figura 4: La ejecución en la última versión disponible de Apple Safari

Una reescritura de la etiqueta "script" de apertura

Chromium publicó el bug y la solución, y un investigador con nickname mramydnei se inspiró para desarrollar otra forma de eludir el filtro que todavía no está corregido. El truco es inyectar una etiqueta "script" de apertura que se escriba directamente en la respuesta HTTP  sin filtrar ningún carácter. Bajo esta escritura debe existir contenido dentro de etiquetas scripts que pertenezcan a la propia página.

Figura 5: El código de la web y el código inyectado que se genera

El comportamiento del navegador será incluir nuestra inyección que va sin cierre de etiqueta, obviar la apertura de "script" de la propia web, y  utilizar el cierre de la etiqueta "script" para generar un HTML bien formado. Esto haría que se ejecutara el script inyectado sin ningún tipo de problema, consiguiendo así un bypass de XSSAuditor.

Figura 6: Inyección y resultado de ejecución

El segundo fallo está aún disponible en Google Chrome, y los dos fallos en Apple Safari, así que por ahora se abre la puerta para saltarse el filtro AntiXSS en estos navegadores.

Saludos Malignos!