Saltándose los filtros javascript El ataque Flash!

[FeRmO]

[Introduccion al ataque Flash!]

En este documento describimos un bug, con implicaciones de seguridad, funciona en muchas paginas web que soportan documentos flash insertado con HTML, o que permiten subir documentos al servidor. Este escrito confía en el echo de que un gran numero de usuarios que navegan por la red tienen instalado el plugin de Flash, para que el atacante pueda lanzar el ataque de Cross-site scripting. No entraremos en mucho detable en la descripción del ataque de Cross-site scripting en general; Sin embargo esperamos que este documentos esplique como un documento Flash se puede utilizar para inyectar código javascript en aplicaciones web que no tengan un buen filtro.


[Aplicaciones web actuales y cross-site scripting]

Las aplicaciones web consisten en paginas web no estáticas, que permiten a los usuarios interactuar con el sitio web. Ejemplos de tales sitios incluyen a Hotmail, Yahoo, MSN communities y una larga lista de otros sitios. En la mayoría de los casos, esta interacción implica la autentificación de los usuarios, para proporcionar un entorno multiusuario.

En comunidades como deviantARTcada miembro tiene su sección y espacio web, donde el o ella pueden subir material artístico, por ejemplo poesía, gráficos (normalmente formato jpg), fotografías, y por supuesto, películas Flash. Con cuenta de usuario (o como usuario anónimo) se pueden ver los trabajos de otra gente. Esto significa que los ficheros y el contenido es compartido entre diversos usuarios. Desde un punto de vista de la seguridad, esto significa que los contenidos compartidos han de ser de confianza para los dueños del contenido y para las personas que están viendo el contenido.

Cross-site scripting, también conocido como XSSes un típico ataque que explota la confianza entre el dueño del contenido y la persona que accede a el. En un termino mas simple, XSS consiste en un usuario que accede al contenido ( creado por otro usuario 'malicioso' ), que contiene código como puede ser javascript, que manipula la pagina para robar el identificador de sesión, o datos personales de este usuario.


[Prevención de ataques Cross-site scripting]

métodos actuales

La mayoría de las aplicaciones web suelen utilizar una de estas tres tecnicas para evitar los ataques XSS:

·   Rechazar todo el código html que sea introducido por el usuario.
·   Permitir solo tags específicos. Esto es alcanzada generalmente haciendo uso de código especial para representar etiquetas específicas del HTML.
·   Filtrar o eliminar código Active Scripting del código HTML.

Se cree que estos métodos generalmente rechazan a usuarios malignos de inyectar código Active Scripting o HTML. Las aplicaciones web como Hotmail y Yahoo Mail intentan suprimir todas las posibilidades de injeccion de código javascript (y contenido activo) haciendo uso de extensos filtros de contenido. Varias autoridades de internet como CERT y Microsoft han descritos métodos de filtrado y detallan los peligros de este ataque.

Algunas aplicaciones web permiten subir específicamente contenido Flash, por ejemplo deviantArt. Otras apenas permiten que los archivos sean almacenados en el servidor para posteriormente descargarlos, algo similar a los servidores FTP.

Este documento describe como se pueden saltar tales filtros de contenido facilmente debido a la carencia de la previsión en el diseño de las aplicaciones web. El bug descrito aquí, consisten en la confianza en los documentos Flash (o películas según la referencia de macromedia) y el echo de no tratar este contenido como contenido activo.


[El ataque Flash!]

Macromedia Flash tiene su propio lenguaje de scripting. ActionScript (el lenguaje scripting) parece muy simple para programadores de javascript experimentados ya que utiliza una sintaxis similar a la de javascript, C y PERL. Sin embargo este mismo lenguaje se puede utilizar para las animaciones complejas, simulaciones, creación de juegos etc... La acción/función que nos interesa a nosotros es getURL() .Esta función nos permite redirigir al usuario a otra pagina web. El parámetro normalmente es una URL; algo del tipo: "http://eyeonsecurity.net", de modo que el código final quede como sigue:

Código [Seleccionar] Expandir

getURL('http://eyeonsecurity.net')

Supongamos que ahora usamos javascript: La URL ahora seria así:

Código [Seleccionar] Expandir

getURL('javascript:alert(document.cookie)')

El siguiente ejemplo abre un cuadro de alerta javascript con la cookie que esta utilizando el usuario en su sesión para ver ese documento Flash.
NOTA del traductor: de ahí que sea importante usar un sitio web en el que los usuarios tengan que autentificarse para ver tu fichero flash, de ese modo, la cookie que veas, sera la cookie que pertenece a su usuario en ese servidor. Esto significa que ya hemos conseguido inyectar javascript haciendo uso de las características del internet explorer y Flash. En el ejemplo, el fichero Flash en el que hemos insertado el script es similar a lo que podéis observar en la primera imagen, que es la que tenéis justo debajo.



[Sitio vulnerable y ejemplos del software]

Ezboard (http://www.ezboard.com/) es probablemente uno de los mejores sistemas de Bulletin Board Systems libres conocidos en internet. Este BBS esta basado en el protocolo HTTP, permite a sus usuarios a tener su firma en flash haciendo uso de las etiquetas (tag) EMBED. Por lo tanto en nuestras pruebas, editamos nuestras preferencias y especificamos el siguiente código en la firma:

Código [Seleccionar] Expandir

<embed
src="http://eyeonsecurity.net/download/example.swf"
pluginspage=http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash
type="application/x-shockwave-flash"
width="0"
height="0"
>
</embed>


Este código es añadido a cada post que el atacante envíe al foro de Ezboard, permitiendo así, que robe la cookie de la sesión de los usuarios.


DeviantART es una popular pagina web, anima a sus usuarios a subir animaciones flash y creaciones para visualizarlas por otros miembros del sitio web. Por supuesto que es un sitio web muy popular, sus usuarios subirán sus animaciones flash y creaciones que serán vistas por otros usuarios del sitio. Por supuesto usuarios maliciosos que intenten robar cuentas de usuario y posiblemente cuentas administrativas, deberían crear una nueva cuenta, subir el fichero flash malicioso y esperar a los resultados. No hay disponible ninguna demo para este portal.

Comunidad MSNEste sitio permite a los usuarios subir sus ficheros entre los ficheros que subimos nosotros estaban los ficheros SWF, que en su momento ejecutaran código javascript. Este es un error de seguridad muy obvio. En un documento anterior [9] en la web de EyeonSecurity, llamado Microsoft Passport Account Hijack Attack, esplicabamos como un solo defecto creaba un significativo problema de seguridad en la red de MSN o Passport.

Los servicios anónimos por ejemplo Anonimizery The-Cloak, son también vulnerables a este ataque. Estos servicios intentan filtrar código javascript de las paginas HTML, sin embargo fallan en el reconocimiento del ataque que estamos explicando en este momento. Significa que el WebMaster lincando (o redireccionando) a estos usuarios a un fichero SWF puede saltarse las restricciones establecidas por este servicio.

Dos foros (BBS) software específicos, las cuales son particularmente vulnerables a este ataque, son Ikonboard y YaBB. Estos foros particulares, admiten solo tags específicos que son analizados por la Aplicacion Web para producir el resultado. Sin embargo estos foros permiten meter animaciones flash en la pagina usando los tags específicos para flash, los cuales se convierten en la etiqueta de objeto correcta.

Ejemplo

[flash]http://eyeonsecurity.net/download/example.swf[/flash]

Lo anterior seria interpretado por el script y transformado a:

Código [Seleccionar] Expandir

<object
classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"
width=200
height=200>
<param
name=movie
value=http://eyeonsecurity.net/download/example.swf>
<param
name=play
value=true>
<param
name=loop
value=true>
<param name=quality
value=high>
<embed
src=http://eyeonsecurity.net/download/example.swf
width=200
height=200
play=true
loop=true
quality=high>
</embed>
</object>


Sin embargo estos ejemplos específicos no son los únicos vulnerables. Cualquier servicio online, el cual permita insertar contenido flash es vulnerable a ataques XSS. Los vendedores y servicios descritos en esta sección han sido notificados del defecto antes de que este documento fuese de acceso publico. Esto significa que los ejemplos explicados en esta sección puedes estar ya corregidos para cuando leas este texto.



[Reparando este bug]

Solución simple: NO PERMITAS CONTENIDO FLASH EN TUS APLICAIONES WEB.

Sin embargo en la mayoría de los casos, la solución no es tan simple. Considere el caso de deviantART por ejemplo. Las animaciones Flash son parte del contenido del sitio. Tal contenido es considerado imprescindible para las comunidades Flash como deviantART.

Posibles soluciones para:
Macromedia (Desarrolladores de Flash player)

Macromedia y EyeonSecurity han trabajado en conjunto para proporcionar una solución a los desarrolladores web. Fue sugerido que permitiesen a los diseñadores web cambiar el comportamiento del contenido Flash dentro de las paginas HTML. Esto soluciona el problema dentro de foros y sitios similares, pero se intenta no romper cualquier existencia de película animación/flash.

Sin embargo tal solución no resuelve el problema en sitios web como MSN Communities y deviantART. Estos sitios web mas que permitir usar etiquetas HTML para lincar ficheros SWF externos, permiten a sus usuarios subir ficheros SWF. Macromedia (así como el EoS) desaconseja activamente el diseño de aplicaciones web que permita a los usuarios subir contenido Flash sin chequear.

Debe ser observado que la interacción entre las paginas HTML (y javascript u otro contenido activo para la materia) y los ficheros Flash es soportado usando diferentes funciones, y el método descrito en este documento se podría clasificar mas como "hack" que como una función. Sin embargo una aplicación bien conocida para realizar películas Flash llamada Swish hace uso de métodos javascript para permitir a los diseñadores web insertar su propio código javascript.

Macromedia lanzo un boletín sobre este bug el 13 de Junio del 2002. Puedes consultar este documento en:
http://www.macromedia.com/v1/handlers/index.cfm?ID=23051


Desarrolladores Web y Diseñadores Web

Una buena solución seria analizar la animación Flash y filtrar parámetros maliciosos en la función getURL(). Esto se debería hacer en el caso de que el sitio web permita subir al servidor ficheros SWF. Se recomienda altamente a los Webmasters que filtren el contenido en el caso en el que dejen subir este tipo de ficheros. Los Webmasters pueden elegir bloquear cualquier contenido Flash en el cual la funcion getURL() no apunte a un sitio web o dominio específico. Otra solución seria cambiar todas las referencias a getURL() para que se ejecuten en una ventana nueva. Esto se puede conseguir específicando la propiedad target de los links como '_blank'.

Nota del traductor: en un link seria:

Código [Seleccionar] Expandir

<a href='tralala' target='_blank'>link</a>
Esto haría que el link se abra en una nueva ventana.

Realizando los cambios descritos, el código javascript no se ejecutará bajo los privilegios del hosting de dominio. Sin embargo, según lo publicado por Bertrand Saint-Guillain, esta solución no es constante debido al echo de que el lenguaje ActionScript es complejo y proporciona la función eval(). Esta función permite a hackers mas sofisticados saltarse la protección contra el análisis/filtrado de ActionScript.

Ejemplo:

Código [Seleccionar] Expandir

a="get";
b="URL";
c="javascript:";
d="alert('bypassed');void(0);";
eval(a+b)(c+d);

Este ejemplo permite saltarse cualquier protección propuesta en la solución anterior, puesto que no hay ninguna referencia a getURL('javascript:loquesea').

Otra solución posiblemente más factible sería hacer uso de un dominio separado para almacenar y visualizar las películas Flash. Este método se puede utilizar también para otros documentos, tales como HTML, para permitir el contenido activo sin permitir a los atacantes obtener la autentificación de la sesión robando cookies. Esto significa que si su dominio es securewebapplication.com, usted posiblemente podría almacenar el contenido malicioso en securewebapplication.net. Por supuesto esto significa que el contenido de securewebapplication.net no requiere autentificación de sesión y por lo tanto este contenido es visible por cualquier usuario de internet. Es importante observar que el contenido malicioso se debe exhibir solamente en un dominio esterilizado, significando eso que si el documento Flash se encuentra en un archivo del HTML, el archivo del HTML tiene que ser también visualizado desde el dominio esterilizado.

Los desarrolladores web pueden también hacer uso de un IFRAME que señale directamente a la animación Flash que reside en terceros dominios en lugar de usar las etiquetas EMBED o OBJECT. En este caso la animación Flash todavía se incluye pero se lanza desde un iframe que elimina la posibilidad de utilizar javascript para robar las cookies y realizar otros ataques de Cross site scripting. Este método primero fue descrito en Neworder, y luego fue añadido al boletín de  errores de Macromedia. Mientras que esta solución es más constante ofrece menos compatibilidad entre diversos navegadores que no soporten IFRAME.


Sugerencias para los usuarios de productos/servicios específicos

Ezboard.
La respuesta dada por la ayuda del producto de Ezboard es la siguiente:

Desafortunadamente, está muy, muy complicado hacer imposible el robo de cookies. Si así lo hiciéramos, ezboard no tendría tantas opciones para requisitos de usuarios como tiene actualmente. Afortunadamente, tenemos un alto nivel de seguridad de login que comprueba la dirección IP del usuario.
Si esta es seleccionada, nadie podrá utilizar la cookie para hacer login cuando el usuario real este logueado (conectado) al sistema.

Esto puede ser una buena solución, que trata fallos XSS, incluyendo la que esta descrita en este documento. Sin embargo la comprobación del IP no trabaja bien con los usuarios de Internet detrás de proxys.


YaBB
La respuesta de la solución de Corey Chapman fue:

No la consideramos como opción, sino que hemos informado a la gente que
simplemente comenten o supriman 2 líneas flash-rendering dentro de yabbc.pl.
Probablemente inhabilitaremos la característica para la siguiente
actualización, pero asumimos que es una vulnerabilidad para esta versión.


Ésta es solución absolutamente directa. Por supuesto sugerimos también quitar el icono Flash que se muestra cuando se edita un mensaje.


Ikonboard
Este producto permite que los administradores deshabilitar el soporte Flash, según Andrew (Ikonboard).

Esto abre el
agujero de seguridad que usted mencionó, como la gente lo ha utilizado antes
a cambiar los avatars de la gente. El problema es que no podemos apenas quitar
la opción de tantos usuarios que estén descontentos con nosotros. Como está ahora
usted puede inhabilitar esta opción, y no permitir el flash en su sitio.

Esto suena como una solución elegante sin embargo no probamos esta característica.


Autor:

Obscure [obscure@eyeonsecurity.net]

Traducido por: SeSoX para DTF-Zine

Ultima actualización: 25.Agosto.2002