Hola

Puede que a algunos no les suene ese «Hola», es una interjección muy habitual en castellano. El sonido todavía no ha sido gravado por la SGAE ni por hacienda, asi que es gratis emitirlo por cualquier medio. Pongamos un ejemplo.

Marisa sale cada mañana hacia el trabajo y se encuentra con Carlos en el portal. Marisa,que es una persona educada, dice «Hola, buenos días» y Carlos ignora la interjección. Días más tarde, Marisa (¿hemos dicho que era de Anonymous?) sube a 4chan un flyer de la operación «HelloWorld». En cuestión de 1 mes Carlos pierde su trabajo, a su mujer, su hija se hace choni, le suben la hipoteca y es obligado a dimitir como presidente de la comunidad. Todo por no decir hola. ¿Te arriesgarías a seguir siendo un maleducado? Yo no. Di hola hijo de puta o págalo caro.

Ahora vamos a ver cómo se dice «hola» en cyberchino…

Hace unos días Brian Krebs destapó la liebre, un nuevo 0day en flash estaba siendo explotado en ataques muy dirigidos.
A partir de ahí la cosa ya se empezó a mover y Adobe confirmaba la situación.

En el blog de referencia sobre ataques dirigidos empezaba a brotar la info, y al poco tiempo ya nos podíamos bajar los samples (en un zip con contraseña).

A través de correos, se había enviado el exploit embebido en documentos de word.

¿Y qué pasa cuando los abres?. Por si alguna vez te lo has preguntado, echa un vistazo al siguiente video donde ejecuto el .DOC real que contiene el exploit. Esto es lo que vería el objetivo del ataque.

Básicamente lo que tenemos es la siguiente secuencia, que se repite en este tipo de ataques.:

1. Se carga el documento con el exploit embebido
2. Se ejecuta el exploit y el payload
3. Se mata la instancia actual del Word
4. Se abre otra rápidamente con un documento «limpio» para que la víctima no sospeche.

Al ejecutarse en una VM vemos que pasa demasiado tiempo entre las diferentes etapas, pero en una física, aunque todavía perceptible, se reduciría algo más.

Veamos que tiene dentro el documento, usando el programa FileInsight de McAfee

Vemos en esta imagen como el documento lleva embebido un objeto flash, que es el que hace todo el «trabajo». En este caso, ubicar en memoria el nop sled y la shellcode mediante heap spray.

El decompilado del .swf original lo podeís ver aquí

Si os fijais en la linea 61 vereis lo siguiente

this.t = "4657530ACC0500007800055F00000FA000001801004.... [bugly swf]....";

Un cadena que representa los bytes de otro archivo flash, que es el encargado de provocar la vulnerabilidad.
Este trigger es cargado sin necesidad de pasar por disco usando el metodo loadBytes del loader

this.r = this.hexToBin(this.t);
this.ldr = new flash.display.Loader();
this.ldr.loadBytes(this.r);

El exploit no tiene mucho, no se salta ni DEP ni ASLR por lo que parece que estaba destinado a XP principalmente.

Si quereis echar un ojo a la shellcode la he subido aquí http://www.filefactory.com/file/cbb6273/n/shellcode.bin

Podéis leer un buen análisis de la lógica del fallo que ha hecho la gente de secunia
http://secunia.com/blog/210

También os recomiendo, si queréis profundizar en este tipo de fallos, las siguientes slides http://cansecwest.com/csw11/Flash_ActionScript.ppt

Otra referencia con una curiosidad al final 😉
http://bugix-security.blogspot.com/2011/04/cve-2011-0611-adobe-flash-zero-day.html

Hasta la próxima.