Destripando Nuclear EK (II)

En el anterior post, conseguimos un ejemplo del caso a tratar. Teniendo los ficheros HTML extraídos con Wireshark, comenzamos su análisis.

(1) index.php

imagen_1

Simple; redirecciona sí o sí a (2) http://zvqumcs1tsfct4sjvzot3p9.filmtane.com/watch.php?kcppp=MTE3NzU5ODg2Nzk3NjRlY2M0MmJiNDk3M2NmZGVkM2Fl.

(2) watch.php

El servidor responde a la petición del cliente:

HTTP/1.1 302 Found
Server: nginx/1.4.3
Date: Wed, 11 Feb 2015 16:39:20 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Cache-Control: no-store, no-cache, must-revalidate
Expires: Wed, 11 Feb 2015 16:39:20 +0000
Location: http://zvqumcs1tsfct4sjvzot3p9.filmtane.com/BQdXBkRUTQg.html

De nuevo éste es redireccionado. Esta vez a (3) http://zvqumcs1tsfct4sjvzot3p9.filmtane.com/BQdXBkRUTQg.html

Esta técnica se llama Cushion Redirection y consiste en obligar al cliente a dar saltos pudiendo de esta manera evadir filtros de navegación.

(3) BQdXBkRUTQg.html

imagen_2

No queda otra. Éste es el fichero HTML que tiene la chicha. En él encontramos texto sin sentido y código javascript claramente ofuscado.

imagen_3

Directamente vamos a desofuscar el código javascript y ver qué se cuece en su interior.

imagen_4

Una vez desofuscado, se comprueba que el objeto que explota la vulnerabilidad –en este caso hay varios pero nos centraremos en el objeto Flash– está siendo llamado desde un segundo javascript embebido en el código HTML y ofuscado en el texto, a priori, carente de sentido.

imagen_5

Este javascript, carga en tiempo de ejecución el objeto flash (4) Bk8RH15VB1xLUk5SS1BXClYHDgVUBlNLV1UWVAkOGVQBTQZQVkQDXQs

-> GET http://zvqumcs1tsfct4sjvzot3p9.filmtane.com/Bk8RH15VB1xLUk5SS1BXClYHDgVUBlNLV1UWVAkOGVQBTQZQVkQDXQs
<- HTTP/1.1 200 OK

Pasándole como parámetro FlashVars el string “exec=N3NNYPWYYgX3YW...” que actúa como parte del payload para el exploit.

NOTA: Debemos darnos cuenta que estos Exploit Kit se hacen para que sean lo más dinámicos posible y vender el mayor número de ellos. De esta manera, únicamente hay que cambiar esta parte del payload para que se adapte a las exigencias del comprador.

Antes de dejarlo por hoy, hay que preguntarse: si se está llamando a un objeto flash, ¿por qué el proxy lo detecta como tipo application/octet-stream y no como application/x-shockwave-flash?

En el próximo post, veremos por qué.

¡Saludos!

Ver también en: