miércoles, noviembre 20, 2013

No necesitas subir el código fuente para que rule el Flash

En las auditorías de seguridad, cuando te topas con una web escrita en Adobe Flash, tienes que conseguir todos los ficheros .SWF. Al igual que haces con el código fuente de las páginas HTML servidas por el sitio web, tener un archivos .SWF significa que también tienes que el código fuente si realizas un proceso de decompilación para obtener su código fuente. Para ello se pueden usar múltiples herramientas, y hasta decompiladores .SWF o .NET online - también decompilan Applets Java -.

Esto está bien, pero si puedes conseguir el archivo .FLA original, mejor que mejor, solo por si hay comentarios o recursos que no aparecen durante el proceso de decompilación. Esto, en una web que tenga un proceso estricto de seguridad, no debería pasar nunca, y los ficheros .FLA no deberían estar nunca al alcance de todo el mundo.

Pero como os podéis imaginar, esto no siempre es así.

Hace tiempo, cuando publiqué el artículo que hablaba de analizar los ficheros .DS_Store subidos a los sitios web para descubrir otros ficheros escondidos en el mismo servidor, ya me pasó que encontré que en una carpeta estaban el fichero .SWF y el código fuente en fichero .FLA.

Figura 1: Al analizar el fichero .DS_Store aparecían principal.swf y principal.fla

Los ficheros .FLA no están protegidos en el servidor web por defecto, así que si lo encuentras, salvo que haya alguna regla añadida manualmente en el WAF - sería una buena recomendación añadirlo directamente a las reglas de fortificación de Mod_Security para evitar estas fugas - vas a poder disfrutar de toda la información.

Conocido esto, decidí probar el otro día que andaba con algo de tiempo, a buscar ficheros .SWF e intentar localizar los ficheros .FLA de los ficheros .SWF que me fuera escupiendo Google haciendo algo de hacking con buscadores, en plan "lotería random". Lo que esperaba es que no fueran muchos, y que cuando solicitará el fichero .FLA se obtuviera algún mensaje de error como este.

Figura 2: El fichero .fla no está en el servidor web

En algunos casos me topé con la grata sorpresa de que el servidor tenía el mod_negotiation activado, así que cuando pedía el fichero .FLA me proporcionaba la lista de ficheros con el .SWF de nuevo. Ya sabéis que si está activado este módulo se pueden listar casi todos los ficheros del servidor web.

Figura 3: Buscando un .fla acabé topando con un mod_negotiation activado

Pero lo más curioso fue que sobre más o menos unos 50 sitios que probé, acabé con 8 ficheros de código fuente .FLA. Como podéis suponer, primero empecé probando en sitios al azar, y luego fui dirigiendo el tiro a dominios que deberían tener una mayor seguridad - como cuando se prueban los análisis de metadatos con FOCA en sitios como la Missile Defense Agency, para probar años después que siguen teniendo fugas que pueden provocar ataques "desde el pasado" -. Y no hizo falta buscar mucho, enseguida apareció algún fichero .FLA en sitios .mil.

Figura 4: Un fichero .FLA en un dominio .mil

No había nada especial en ese código fuente. Tan solo el código para reproducir unos vídeos. Nada preocupante desde el punto de vista de seguridad, pero me extrañó que no tuvieran una medida global de protección contra este tipo de fugas de datos, con lo serios que se han puesto con esto.

En cualquier caso, nosotros con Faast buscamos y detectamos esto, y si tienes que hacer una auditoría, antes de buscar hacer probar las 20 técnicas para listar ficheros de un servidor web, prueba a pedir el código fuente, no vaya a ser que una vez más, los árboles no te dejen ver el bosque.

Saludos Malignos!

2 comentarios:

  1. Medidas de securización aparte, que nunca vienen mal, yo lo que nunca haría (y nunca he hecho) es publicar un fichero .fla en el servidor web.

    ResponderEliminar