El caso L-A-C (3/3)

El caso L-A-C (1/3)
El caso L-A-C (2/3)
El caso L-A-C (3/3)

El dominio principal en cuestión "http://l-a-c.cn" tiene la sorpresa que vimos en el primer post del caso L-A-C.

Ese pedazo de código en javascript es otro sistema de ofuscación parecido al que hemos visto en el post anterior pero más complejo y extenso. No lo voy a explicar en profundidad pero, una vez interpretado vamos a ver directamente la sorpresa que lleva dentro:

Como vemos, define la variable url con el contenido que vemos que es una URL muy peculiar. Si ponemos esa URL en el navegador, éste descarga la sorpresa final: un fichero llamado "file.exe" de 20.480 bytes.

Conclusión:

El peligro de este tipo de ataques es bastante eficiente y silencioso, debido a que si navegamos a cualquier URL que consideramos de confianza y ésta tiene agregado el código de javascript que vimos en el primer post de esta serie, automáticamente IFRAME hace el resto de forma oculta: descargar de la web maliciosa y ejecutar un fichero ejecutable con el premio.

Aunque estas webs sospechosas utilicen ofuscación en javascript, es sencillo comprobar los resultados monitorizando el tráfico entre la web y el host que realiza la monitorización.

La web en concreto todavía sigue activa, y eso quiere decir que la legislación del país donde reside el webserver (Tailandia) todavía no tiene una política madura en cuanto a perseguir el alojamiento de malware.

rAmIx

El caso L-A-C (1/3)
El caso L-A-C (2/3)
El caso L-A-C (3/3)

El caso L-A-C (2/3)

El caso L-A-C (1/3)
El caso L-A-C (2/3)
El caso L-A-C (3/3)

Vamos a analizar el código javascript que genera el iframe malicioso en la web víctima y que lleva al navegador del usuario hacia la web maliciosa.

Este código primero define la función Decode() y después la invoca al final del script para decodificar la secuencia de valores decimales que contiene la variable str y construir la sentencia completa del iframe. Para seguirlo con más claridad lo he formateado de una forma más estructurada:


La función Decode comienza con la definición de las variables:

• temp: para transportar valores, iniciado con un blanco
• i: que no se utiliza
• c: es un contador iniciado a 0
• out: contendrá la cadena resultante con la sentencia del iframe completo. Esta variable se inicia con un blanco
• str: contiene los valores codificados
• l: contiene la longitud en bytes de str, y tampoco se utiliza

Comienza la decodificación en la línea 7 con un while que dice que mientras c sea menor o igual a la longitud total de str menos 1 (esto es 221 porque la longitud total de str son 222), iremos dando vueltas a lo siguiente.

Lo siguiente es el while de la línea 9 que aisla los números decimales de los símbolos de admiración, los deja en la variable temp, incrementa c en uno por cada posición de str y saldrá del while cuando llegue a la posición del siguiente símbolo de admiración.

La línea 10 incrementa c en uno que es la posición que tiene el símbolo de admiración.

En la línea 11 es donde realmente se produce la decodificación. Actualiza la variable out con su valor existente más el valor ASCII de temp.

Por último, cuando c se incremente hasta 222, saltará del while de la línea 7 y sacará con document.write el resultado decodificado.

En la primera vuelta, la variable str comienza con el decimal 60. El 6 del 60 es c=0 (primera posición) y el 0 del 60 es c=1 (segunda posición). Como c en la primera vuelta es 0 entra en la primera vuelta porque es menor a 221. Después entra en el while de la línea 9, y como 6 es distinto del símbolo de admiración, temp se actualiza con el valor 6 porque el valor original de temp es un blanco (blanco más 6 igual a 6), se incrementa c en uno y pasa a ser c=1. Seguimos en la línea 9 en la segunda vuelta y nos encontramos con el 0 del 60 (segunda posición de la variable str), y como no es un símbolo de admiración volvemos a meter en temp lo que tenia (6) más lo de ahora (0): se agrega el 0 al 6 y tenemos 60 en temp. Se incrementa c en uno (c=2) y nos encontramos con que en esta posición que es la tercera de str (c=2) tenemos una admiración, por tanto sale del while de la línea 9, se incrementa c en uno y mete en out el valor ASCII de 60 que es el símbolo menor que.

Así, sucesivamente, el siguiente valor decimal (105) es i, el 102 es f... hasta llegar al 62 que es un mayor que, que cierra la sentencia siguiente y que ya vimos en el post anterior:

Esta sentencia sencillamente abre la URL indicada en src en el HTML que contiene el código javascript analizado.

En el siguiente post intentaremos analizar el código javascript encontrado en el dominio principal de la URL indicada, que, como adelanté en el post anterior, provocaba un desbordamiento de buffer en el navegador con toda la pinta de un rootkit.

rAmIx

El caso L-A-C (1/3)
El caso L-A-C (2/3)
El caso L-A-C (3/3)

El caso L-A-C (1/3)

El caso L-A-C (1/3)
El caso L-A-C (2/3)
El caso L-A-C (3/3)

Analizando el origen del código de un website, al final y después de la etiqueta del fin del código HTML, aparecía un trozo de javascript bastante sospechoso:


Lo que más llama la atención aquí es el contenido de la cadena str, que es una serie de números decimales separados por el símbolo de admiración. Estos números decimales deben tener una correspondencia, y lo más seguro es que sea en ASCII.

Para comprobar rápidamente esta correspondencia, utilicé la utilidad on-line JavaScript ASCII Converter de los chicos de HolyCarrot. Introduje la cadena en el campo "Enter decimal ASCII here.", le dí a "Calculate" y en el campo de arriba apareció la equivalencia en ASCII...


toda una revelación.

Como sabemos, iframe incrusta un HTML en el HTML actual.

Con la herramienta Paros Proxy intenté analizar la respuesta de "http://b.l-a-c.cn/" pero no hubo respuesta. Entonces intenté analizar la respuesta del dominio principal "http://l-a-c.cn/" y el resultado fué escalofriante:


Una obra de arte en javascript que, cargada en Internet Explorer provoca un desbordamiento de memoria: KERNEL32.LoadLibraryA. Tiene toda la pinta de un rootkit.

Veamos más información acerca de "http://l-a-c.cn/":

Domain Name: l-a-c.cn
ROID: 20080726s10001s95148405-cn
Domain Status: clientTransferProhibited
Registrant Organization: l-a-c.cn
Registrant Name: Alison Fineman
Administrative Email: ****@CHINOPOSTALPLACE.COM
Sponsoring Registrar: 厦门三五互联科技股份有限公司
Name Server:ns1.mynsnet.biz
Name Server:ns2.mynsnet.biz
Registration Date: 2008-07-26 21:50
Expiration Date: 2009-07-26 21:50

IP Address: 202.151.177.35
IP Location: Thailand
Website Status: active
Server Type: Apache/2
Cache Date: 2008-08-19 12:36:49 MST

Estos datos dicen que el host tiene la versión 2 de Apache, está en Thailandia a nombre de Alison Fineman (a saber de donde han sacado ese nombre) y lo de ****@CHINOPOSTALPLACE.COM es muy gracioso.

El registro del nombre de dominio es bastante reciente: el 26 de julio de este año.

Veamos los puertos abiertos de nuestro amigo el chino:

C:\nmap>nmap -sS 202.151.177.35

Starting Nmap 4.60 ( http://insecure.org ) at 2008-08-20 16:00 Hora estandar romance
Interesting ports on ppp-202.151.177.35.revip.proen.co.th (202.151.177.35):
Not shown: 1703 closed ports
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
25/tcp open smtp
53/tcp open domain
80/tcp open http
110/tcp open pop3
143/tcp open imap
443/tcp open https
587/tcp open submission
993/tcp open imaps
995/tcp open pop3s
3306/tcp open mysql

Nmap done: 1 IP address (1 host up) scanned in 65.218 seconds

C:\nmap>

Vamos, que tiene casi todas las ventanas bien abiertas, para dar servicio.

Viendo todo esto, sólo queda la moraleja:

Firefox y Noscript
siempre antes de salir.

Que la calle está más mala que en los 80's

Salu2.

rAmIx

El caso L-A-C (1/3)
El caso L-A-C (2/3)
El caso L-A-C (3/3)

La Cápsula Verde aterriza

Estimados navegantes.

Este será un blog donde verteré información relacionada con la seguridad en las TI.

Espero resulte de vuestro agrado.

Ramiro Encinas (rAmIx).