GIFScript: From GIF to the Hell – Parte GIF

Esta entrada nace de la necesidad de informar en la red de la pasada ponencia que hicimos Manu (@WireW0lf), Miguel Angel (@n4ut1l0) y yo el 28 de Abril en el congreso MundoHackerDay en Madrid.

Hoy me gustaría hablar de los llamados archivos políglotas, esto es un archivo de “X” tipo, que puede ser cargado como un archivo de tipo totalmente distinto al que en un principio parece ser, y por supuesto, se puede comportar de forma distinta según de qué tipo sea.

Aunque no lo parezca, usamos archivos poliglotas todos los días, un ejemplo claro son los ficheros que se generan con Windows Office a partir de la versión 2007, que no deja de ser una implementación comprimida de imágenes mostrada como un archivo de imágenes + texto, un ejemplo claro son los archivos .docx y .pptx de Word y PowerPoint respectivamente.

Si mantienen su extensión original, se puede abrir un documento o una presentación normales, pero si se cambia la extensión por .zip o .rar (lo que mas rabia nos de) se convierte en un archivo comprimido en el que se encuentran las fotos que hemos usado en nuestra presentación o trabajo.

Lo comentado anteriormente es un ejemplo sencillo y humilde, pero es una característica que puede hacer mucho daño.

Como segundo ejemplo (algo más elaborado) podemos hacer un GIF políglota que no deja de ser una imagen GIF que al ser cargada como código JavaScript puede ejecutar código malicioso desde cualquier lugar de internet.

Para crear el GIF políglota, usaremos lenguaje ensamblador y luego lo compilaremos con YASM.

Código Ensamblador:

Y cuando compilamos con la orden: YASM gifjs.asm -o img.gif

Siendo gifjs.asm el nombre del fichero donde hemos guardado la programación del gif, se nos queda:

Como podéis notar, todo el código del gif aparece comentado salvo la cadena GIF89a, esto es porque al poner el WIDTH con ese valor en específico provocamos que se “ensamble” un carácter de comienzo de comentario, y al terminar, lo cerramos nosotros, esto causa que se cree una variable llamada GIF89a SIN VALOR, así que lo solucionamos dándole uno cualquiera (en el ejemplo le hemos dado valor 1), así nos quitamos de en medio esa variable para que no moleste y seguir ejecutando nuestro código malicioso que consiste en llamar a un archivo .js (en este caso exploit.js) donde quiera que esté alojado (ya sea en local o en remoto) y es eso exactamente lo que puede hacer daño, debido a que el archivo JavaScript puede tener cualquier cosa, desde un simple Keylogger en la pestaña en la que esté cargado (como en la PoC de HackPlayers) o provocar una ejecución de un UXSS en un navegador vulnerable (Como ejemplo tenemos la charla de MundoHacker que hicimos exactamente eso, provocar que el gif cargara el UXSS con la vulnerabilidad de IE11 CVE-2015-0072, ahora ya parcheada).

Aunque, si se carga el gif como lo que debe ser, nos sale un rectángulo enorme negro (gracias al WIDTH.

También decir (que esto se me olvidó en la ponencia por los nervios) que no se puede hacer con cualquier gif, si no que solo funciona con uno expresamente compilado para ese fin.

Si no os ha asustado aún todo lo expuesto anteriormente... Solo imaginad, un MITM, el gif y que en cada petición hecha del cliente, el que esta en medio de la comunicación inyecte en cada pestaña "<script src="img.gif"></script>" en el código de la página... Disfruta de la ejecución del código JavaScript que tu quieras en cada pestaña víctima... de cualquier usuario. ¿A que ahora si que asusta un poco mas?.

Siguiendo con este post, Manu (WireW0lf) os explicará que es un UXSS, porque es tan importante mitigar sus efectos, y más específicamente explicará la vulnerabilidad de IE11.

Enlaces:

Manu García (WireW0lf) – UXSS

Fuente Políglota – Ange Albertini