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!

No esperes a ser hackeado: Piensa como un hacker, planifica como un CSO y haz magia como Harry Potter

Hace ya un tiempo me pidieron escribir un decálogo sobre seguridad informática para entregar en un evento en el que iba a participar. Como siempre, huyendo de formalismos establecidos decidí escribir en tono de humor algunas de las ideas que llevo siempre dentro de mi cabeza - o debajo del gorro para según quién -. Entre las diez reglas que escribí, recuerdo que una de ellas decía:

"Pagarás todo el dinero del mundo por securizar tus sistemas…

una vez te hayan hackeado y expuesto públicamente. ".

Inexplicablemente, día tras día, veo esta afirmación respaldada por la actualidad de Internet que no deja de traer, una tras otra, noticias de empresas que han sido afectadas por esta norma del decálogo maligno que escribí.

Figura 1: Bitly hakeado solicita resetear passwords

La última de ellas que ha venido a respaldar el enunciado ha sido la empresa Bit.ly la web de Ebay que ha visto como sus cuentas de usuario han quedado expuestas públicamente y ha tenido que pedir el reseteo de contraseñas masivo.

Figura 2: Después del 21 de Mayo hay que cambiar la password

En ambos casos, tanto en Bitly como en Ebay los datos se fueron para siempre, y como suelo decir en las charlas de Digital Latches, una vez que los datos de un cliente han sido expuestos, han sido expuestos para siempre. Puedes pedirle al usuario que cambie la password o que cancele la tarjeta de crédito, pero no puedes pedirle que se cambie el nombre, los apellidos, dónde vive, la fecha de nacimiento o los números de identificación de documentos oficiales como el DNI o el pasaporte. Tu eras responsable de sus datos, y ahora ya no hay forma de controlarlos porque están en la red para siempre.

Para evitar que alguien pueda sufrir un robo de identidad y cualquiera de las consecuencias que esto pueda acarrear, en el caso de Bitly se ha implementado un sistema de Autenticación de Segundo Factor para sus identidades, mientras que en el caso de Ebay ya lo tienen...- al menos en USA, pero no en Ebay.es, donde aún por defecto el sitio funciona en HTTP y no HTTPs y no hay forma de encontrar donde poner un 2FA -.

Figura 3: Zona de configuración de cuenta de Ebay.es bajo HTTP

Esto no solo le pasa a empresas de este tamaño, sino que empresas tan importantes, poderosas, grandes y con tanto dinero en caja como Apple no han tenido una media de seguridad en 2FA en sus sistemas de identidad hasta que el número de incidentes como el del periodista de la revista Wired, Matt Honan que según sus palabras fue "brutalmente hackeado" no han salido a la luz pública.

Lo triste es que, una vez que los datos se han esfumado, puedes solicitar el reseteo de la contraseña -incluso aunque sea casi 2 meses después de que la base de datos hubiera robada como en el caso de Ebay, que dicen que perdieron la base de datos a finales de Febrero o principios de Marzo, robando las credenciales de empleados de Ebay porque NO tenían 2FA en sus cuentas de usuario internas.

Figura 4: la base de datos fue robada a finales de Febrero, principios de Marzo

La fortificación de sistemas

La fortificación de cualquier sistema informático se basa en tres reglas archi-conocidas fácilmente entendibles y reconocibles por cualquier persona. La primera de ella dice que debes aplicar siempre el Mínimo Privilegio Posible en todas las piezas de tu sistema - incluidos tus usuarios -. La segunda habla de crear un sistema con la Mínima Superficie de Exposición, o lo que es lo mismo, que reduzca al máximo los puntos expuestos a un atacante. El tercer principio es el más genérico y más importante de todos: Defensa en Profundidad.

Defense in Depth, que dicen los anglosajones, recopila bajo su paraguas todas las medidas de seguridad que ayuden a fortificar el sistema en cualquiera de las capas, siempre y cuando una medida no anule a otra. Si puedes poner otra capa de seguridad para proteger tus sistemas y no rompe una medida de seguridad anterior y no va en contra de la disponibilidad del servicio, ponla.

Piensa como un hacker y hackeate a ti mismo

En un sistema informático, al igual que hacen los hackers e investigadores de seguridad, hay que poner en tela de juicio siempre las protecciones de seguridad que tiene actualmente el sistema para poder pensar en la siguiente medida a implantar. Pensar como un atacante para descubrir cuál es el punto más débil en el sistema que tienes actualmente y planificar como un CSO deben ser parte de la tarea diaria.

Descubrir si lo que necesitas es una protección de 2FA basada en sistemas SMS o más evolucionado como Latch, es tan fácil como descubrir si es sencillo o no robar las credenciales de personas clave de tu compañía como le ha pasado a Ebay. Es sencillo y lo puedes hacer tú, aunque viendo todo lo que ha pasado ya a tantas y tantas empresas que han sufrido el robo de cuentas, parece innecesario.

O bien dentro del próximo proceso de auditoría de seguridad, o como una prueba ad-hoc, hazte un ataque de phishing a ti mismo. Para ello busca las direcciones de correo electrónico de 50 personas de tu compañía o de 50 clientes y envíales un correo de phishing bien armado que les lleve a una web donde se les pida el usuario y la contraseña con el gancho de ser una campaña interna de la empresa para poder participar en un sorteo de la compañía. Haz bonita la web y luego parate a contar el número de credenciales que la gente entrega por la promesa de poder ganar un premio interno. Me apuesto el gorro a que te sorprendería.

Planifica como un CSO ... a pesar de tus jefes

Si eres un CSO y no tienes un Plan Director de Seguridad que te vaya indicando cuál es la siguiente medida de protección que debes aplicar dentro de la regla de Defensa en Profundidad, tal vez no estás gestionando del todo bien tus sistemas. Si pones una medida de seguridad como un segundo factor de autenticación solo después de que has tenido un escándalo, un robo de identidad o un hackeo, probablemente tendrás el mismo problema con otra medida de seguridad en el futuro.

De todas las medidas que tengas que poner, prioriza sabiendo cuáles de ellas van a requerir presupuesto, y cuáles solo voluntad de tu equipo. Si necesitas presupuesto y no tienes, entonces hackea a tus jefes y haz campaña para que entiendan la importancia. Mételos en el ataque de phishing si es necesario.

Haz magia como Harry Potter

Si tienes gente con voluntad de cambiar las cosas, pasionales por la tecnología, con ganas de transformar la compañía a pesar de la compañía, entonces piensa en todas las cosas que se pueden hacer con cero o poco dinero. Aplicar una medida como Latch en una web o servidores Linux, es algo que lleva unos minutos y es gratis si hay menos de 50 usuarios.

No esperes a que hackeen tu sistema para poner la próxima medida de seguridad. Piensa ya como un hacker, atácate a ti mismo, y planifica como solo un CSO sabe hacer, "haciendo magia" con los presupuestos y los recursos, además de pegándose con la gente de negocio. No pensarías que iba a ser fácil ese rol, ¿verdad?

Saludos Malignos!

PD: No os olvidéis de cambiar las contraseñas de Ebay, yo ya he acabado de cambiar las mías.