Cross-Site SWF Scripting con Rosetta para Flash

Cuando un sitio web está utilizando en alguna medida Adobe Flash, está poniendo en el cliente códigos que van a ser ejecutados no directamente en el navegador de Internet, sino en un plugin que se carga en él, el famoso - muchas veces por fallos de seguridad - Adobe Flash Player. Al ser una plugin completo que ejecuta un código propio - Action Script - se comporta como un navegador de Internet dentro de un navegador de Internet y por ello debe aplicar más o menos las mismas medidas de protección que toman hoy en día los navegadores, y a veces no lo hace correctamente.

Same-Origin Policy en Adobe con CrossDomain.xml

Una de las políticas de seguridad que implementan los navegadores de Internet es el Same-Origin Policy. Esta política hace que el código que se carga en una pestaña de un navegador pueda acceder a datos solo a páginas que son del mismo dominio, es decir, que un código JavaScript no podría nunca acceder a la cookie o ningún elemento que compongan la página servida desde otro dominio. Es por ello que para poder acceder a los datos de otra pestaña se utilizan, por ejemplo, los ataques de Cross-Site Scripting, ya que consiguen inyectar código en la pestaña del dominio víctima.

En el caso de Adobe Flash y Adobe Acrobat, es el plugin es que debe forzar esa política de Same-Origin Policy y lo hace mediante la configuración de un fichero en la web de cada sitio, llamado CrossDomain.XML. Por defecto el acceso a datos desde otras ubicaciones está prohibido, pero el dueño de un sitio web puede permitir excepciones. Por ejemplo, si vamos a ver el fichero CrossDomain.XML de EBay podemos ver que hay muchas excepciones en él.

Figura 1: Fichero CrossDomain.XML en Ebay

Sin embargo, existe una forma de saltarse la protección de Same-Origin Policy en Adobe Flash Player mediante la inyección de un fichero SWF en un ataque Cross-Site Scripting o CSRF, pero para ello hay que conseguir que el fichero NO sea servido desde ninguna ubicación externa, sino que sea servido desde el mismo sitio creándolo al vuelo.

Es decir, si se inyecta un código JavaScript que carga un SWF que venga desde una ubicación de terceros, entonces se aplicará Same-Origin Policy y no se podrá hacer nada, pero el plugin de Adobe Flash Player permite que se ejecuten ficheros SWF que desde las llamadas especificadas dentro del parámetro DATA luego si se consigue que esa URL devuelva un SWF aunque sea inyectándolo en un parámetro, se ejecutar. Es decir, si un atacante es capaz de inyectar byte a byte el código de un SWF en la respuesta de una web inyectable haciendo mirroring sin que el plugin tenga que ir a una ubicación tercera, la configuración de CrossDomain.xml no afectaría para nada a este esquema.

Ataques a JASONP API

El trabajo que va a ser presentado por el investigador Michele Spagnolo se ha basado en lo explicado anteriormente, es decir, en inyectar objetos SWF maliciosos en funciones vulnerables de un dominio víctima que van a ejecutar un código Action Script que robará los datos del usuario que se conecte a ese domino víctima. Algo que podríamos decir que es un Cross-Site SWF Scripting.

Para ello ha abusado de los puntos de llamada a las APIs de JASONP vulnerables. Estas APIs de JASONP son muy comunes en los grandes sitios web de Internet ya que permiten servir y consumir WebServices con llamadas en texto plano, indicando en el parámetro Callback de la API el nombre de la función a invocar, y luego los parámetros que deben pasarse. 

Figura 2: Inyección de SWF en el parámetro callback de un API JASONP

En APIs de JASONP en las que se pueda controlar la respuesta de los datos mediante la inyección en los parámetros de llamada por CallBack, un atacante podría aprovecharse de un bug de XSS, o lo que es aún más peligroso, de un bug de CSRF en la web e inyectar en ellos un objeto SWF malicioso escrito directamente en la URL que robara  las cookies de la víctima haciendo peticiones GET y/o POST a un servidor controlado.

Rosetta Tool

En este entorno hay dos limitaciones, la primera de ellas encontrar la función del API JASONP que permite controlar la salida, y que por lo visto no ha sido un reto para Michele Spagnolo que ha visto como este ataque afectaba a Google, Ebay, Twitter, Tumblr, Instagram, etcétera, etcétera. Algunos de ellos, como Ebay o Instagram aún permanecen vulnerables.

La segunda de las limitaciones era la complejidad técnica más grande que había que saltar, y es que la API de JASONP generalmente solo permite entradas de valores en los parámetros que sean alfanuméricas, por lo que hay que conseguir que el objeto SWF que se inyecte en el parámetro esté codificado en ese formato. 

Figura 3: Concepto de Rosetta Tool

Habitualmente un fichero SWF es un archivo binario, y ahí es donde aparece Rosetta. Lo que hace esta herramienta es, a partir de cualquier objeto binario SWF genera un archivo comprimido con zlib que utiliza solo caracteres alfanuméricos, gracias a técnicas basadas en la codificación Huffman y algún ataque más. Todo esto lo explicará en su próxima charla en Hack in The Box, pero las diapositivas están ya disponibles.

Figura 4: Prueba de Concepto Universal escrita en Action Script 2 para ejecutar en la víctima

Esto permite generar ataques saltándose Same-Origin Policy, y para hacerlo más fácil ha creado una Prueba de Concepto Universal escrita en Action Script 2 que realiza la petición de los datos de entorno de una ubicación víctima a un servidor atacante. Puede ser descargada desde su repositorio en GitHUB.

Figura 5: Explotación de la POC con un Objeto Flash que debe ser cargado en el navegador de la víctima

La codificación con Rosetta del objeto malicioso es la que se ve en Data y para realizar el ataque completo hay que llamar con los parámetros URL y Exfiltrate correctos.

Mitigaciones y estado actual

Por supuesto, Adobe no tardó en proveer de una actualización de seguridad para todos los Adobe Flash Players en Windows, Linux y Mac OS X con el objeto de evitar estos ataques mediante una nueva versión que revisa con mayor fortaleza los objetos que le entran escritos en las páginas web, pero como no todos los usuarios se actualizan hay aún muchos clientes vulnerables. Algunos como Apple, ha prohibido con XCode el uso de versiones de Adobe Flash Player en Apple Safari para OS X vulnerables a esta técnica.

Por su parte, los sitos web con APIs JASONP que permiten al atacante controlar la salida de las respuestas están mirando cómo solucionar estos bugs. Algunos como Google o Twitter ya lo han solucionado, pero aún quedan muchos otros por corregir estos fallos. Tú, por si acaso, actualiza tu Adobe Flash Player ahora mismo.

Saludos Malignos!