¡¿Quién me ataca?!

Navegar por la red es una actividad peligrosa desde el punto de vista de la seguridad. Los viejos tiempos en los que podíamos identificar y evitar los sitios sospechosos ya han pasado a la historia. Las infecciones masivas de sitios web son comunes hoy en día, e infectan a cuantos sitios puedan sin fijarse en su contenido. Después de comprometerlos, suelen vender sus datos de acceso a los cibercriminales, quienes los usan para alojar malware o redirigir a las víctimas a algún paquete de exploits.

Hemos visto esto cientos de veces, un ejemplo reciente es la distribución de Flashfake mediante blogs comprometidos de WordPress.

Gracias a Kaspersky Security Network (KSN) tenemos buenas estadísticas de los sitios por los que navegan nuestros clientes y detectan como maliciosos. Y gracias a Kaspersky Internet Security y Kaspersky Anti-Virus, los usuarios pueden seguir navegando tranquilamente sin mayores inconvenientes.

Este mes he estado analizando sitios comprometidos con ES TLD para determinar cuáles son los más peligrosos para los usuarios que hablan castellano. Estas son las 5 amenazas principales:

• Trojan.Script.Generic
• Trojan.Script.Iframer
• Trojan-Downloader.JS.Expack.sn
• Trojan.JS.Redirector.ro
• Trojan-Downloader.HTML.IFrame.agc

Los resultados muestran que casi todas las detecciones maliciosas ocurren en archivos JS, simples trucos JS para redirigir al usuario a sitios web maliciosos. Parece que agregar un IFRAME al código HTML no es muy atractivo hoy en día.

Vale la pena notar que 2 de los 3 sitios más detectados tienen alguna relación con la distribución de anuncios publicitarios. Esto es muy preocupante, porque estos anuncios se pueden mostrar en cualquier otro sitio.

Nuestro motor heurístico es el principal responsable del veredicto, así que el código en sí despertó mi curiosidad. Descargué todos los archivos JS detectados y los revisé. Los resultados fueron interesantes.

La mayoría de los códigos JS que analicé son archivos legítimos modificados, es decir, no se crearon nuevos archivos en el sitio comprometido.

Por lo general, el código modificado se anexa al final del archivo legítimo.
Sólo hay unos pocos códigos maliciosos diferentes en los cientos de sitios infectados. Por eso podemos relacionar estas infecciones con diferentes campañas maliciosas. Aquí puedes ver los resultados de mi análisis:

Puedes notar que la familia 1 (family1) y la familia 2 (family2) son las causantes de más del 75% de las infecciones. Veámoslas más a fondo:

Familia 1:
Código malicioso inyectado:

Básicamente, este código crea un Iframe en un dominio RU utilizando un pseudo generador de números aleatorios:

Estos sitios albergan el paquete de exploits BlackHole.

Pero lo que me parece más interesante es la forma en la que se infectaron todos estos sitios. No hay un patrón común en la tecnología que utilizan. Buscando en foros podrás encontrar sin esfuerzo cómo se inyectó este código para realizar el ataque utilizando un problema reciente en PLESK .

Se abusó este Panel de Control para inyectar el código malicioso en archivos JS.

Aquí puedes encontrar más información sobre este ataque.

Parece que esta campaña se realizó en junio.

Familia 2:
En este caso no hay una sola inyección, sino muchas con un patrón común. El código infectado es así:

Fíjate en el nombre de la variable. El patrón ‘var_0x’ se encuentra en diferentes archivos JS infectados. Por eso no sorprende que redirija al usuario a un sitio web malicioso:

De nuevo, la pregunta es: ¿cómo sucedió la infección? Parece que el grupo responsable de estas infecciones ha estado utilizando vulnerabilidades viejas de WordPress y de complementos. En tal caso, en vez de inyectar un sólo archivo JS, es más común inyectar el código en cada JS individual que se encuentra en el sitio web comprometido.

Y, una vez más, los sitios infectados redirigen a las víctimas al paquete de exploits BlackHole.

Parece que esta campaña se realizó en abril.

Conclusiones

Podemos ver dos ejemplos de cómo ataques automatizados pueden infectar un sitio web. La primer vulnerabilidad estaba en el Panel de Control, la segunda en el CMS y los complementos que usaba.

Las vulnerabilidades de WordPress son bastante antiguas, así que es probable que los administradores del sistema ya hayan hecho algo para prevenir que se comprometan sus sitios web.

Durante el último mes, estas campañas trataron de infectar a 7.000 usuarios diferentes. Esta cifra no es significativa, lo importante es el número de visitantes desprotegidos que ingresaron a los sitios infectados el mes pasado. Pero no sabemos cuántos fueron.

Este es un ejemplo del impacto masivo que las campañas de infección tienen sobre los usuarios y los sitios legítimos. Podemos encontrar ejemplos similares en cualquier dominio de nivel superior (TLD).

Por último, un mensaje para los administradores de sitios web: sé que es una tarea difícil, de verdad lo sé, pero no subestimes el potencial de peligro de CADA vulnerabilidad en CUALQUIER programa que utilicen tus sistemas.

Como nota de cierre, estoy ansioso por recibir las estadísticas del próximo mes para ver cuántos de estos sitios infectados aparecen limpios.