Vector de ataque de los paquetes de exploits –actualización semestral

Es muy llamativo ver cuán corta es la vida de un paquete de exploits, pues algunos de estos paquetes que alguna vez se hicieron muy populares infectando a miles de usuarios, ya no están vigentes. Y lo es aun más que algunos antiguos paquetes estén de regreso recargados con nuevos y frescos exploits, posicionándose a la cabeza de todas las clasificaciones de programas maliciosos.

Sin embargo, resulta más interesante estudiar cómo se usan los actuales exploits, y sus víctimas.

2010

Para situarnos, comencemos analizando la situación en el año 2010. Ese año, los kits de explotación más populares fueron:

1. Phoenix
2. Eleonore
3. Neosploit
4. YESExploitKit
5. SEOSploitPack

A finales de 2010, hubo una acentuada disminución en el uso de Phoenix y un aumento en la cantidad de servidores maliciosos para NeoSploit.

El análisis de las vulnerabilidades a las que apuntaban estos paquetes de exploits, nos lleva a inferir el principal vector de ataque:

Lo importante aquí no es la figura estática, sino la dinámica. En este caso, las vulnerabilidades en Java subieron hasta el tercer lugar en apenas un año. El 40% de todos los nuevos exploits usados por los cinco principales paquetes en el año 2010 apuntaban a Java. Según mi colega Dan Guido, 11 de cada 15 paquetes principales incluían al menos un exploit para Java, y 7 de cada 15 de los principales paquetes incluían más de uno.

Comparemos esta información con otros datos. Según el Centro de prevención de programas maliciosos de Microsoft, el año pasado se registró un récord en los ataques contra las vulnerabilidades de Java:

arstechnica.com/business/news

Nuestros propios registros muestran una situación similar. A continuación se puede ver la creación de firmas relacionadas con Java en respuesta a los ataques detectados:

Estos intentos de ataque también se detectaron en nuestra base de clientes:

La pregunta es: ¿por qué Java? Por un tiempo he estado reflexionando la respuesta hasta que la encontré cuando asistí a la presentación que dio Dino Dan Zovi en la conferencia SOURCE. ¡Era tan obvio! Es porque las vulnerabilidades de Java son la manera más fácil de burlar las contramedidas de seguridad del sistema operativo. En este caso, una imagen vale más que mil palabras:

2011

¿Cuál es la situación en el presente año? ¿Ha cambiado algo? Algunas cosas sí, como los principales paquetes de exploits durante el primer semestre:

Aparecieron dos nuevos actores: BlackHole e Incognito. Veamos a qué vulnerabilidades apuntan:

BlackHole:

• CVE-2010-1885 HCP
• CVE-2010-1423 Insuficiente validación de argumentos de Java Deployment Toolkit
• CVE-2010-0886 Vulnerabilidad no especificada de Java en el componente Java Deployment Toolkit de Oracle Java SE
• CVE-2010-0842 Vulnerabilidad de ejecución remota no válida de códigos de índice de matriz de Java JRE Mixer Sequencer
• CVE-2010-0840 Vulnerabilidad de ejecución remota confiable en cadena de códigos de Java
• CVE-2009-1671 Desbordamientos de buffer de Java en el control de Deployment Toolkit ActiveX en deploytk.dll
• CVE-2009-0927 Adobe Reader Collab GetIcon
• CVE-2008-2992 Adobe Reader util.printf
• CVE-2007-5659 Adobe Reader CollectEmailInfo
• CVE-2006-0003 IE MDAC

Básicamente, tenemos aquí los mismos elementos que incluyen todos los paquetes, con la sola excepción de las dos primeras vulnerabilidades, CVE-2010-1885 y CVE-2010-1423, dirigidas a Java.

¿Qué hay sobre Incognito? Esta es la lista correspondiente:

• CVE-2010-1885 HCP
• CVE-2010-1423 Insuficiente validación de argumentos de Java Deployment Toolkit
• CVE-2010-0886 Vulnerabilidad no especificada de Java en el componente Java Deployment Toolkit de Oracle Java SE
• CVE-2010-0842 Vulnerabilidad de ejecución remota no válida de códigos de índice de matriz de Java JRE Mixer Sequencer
• CVE-2009-0927 Adobe Reader Collab GetIcon
• CVE-2008-2992 Adobe Reader util.printf
• CVE-2007-5659/2008-0655 Adobe Reader CollectEmailInfo
• CVE-2006-4704 Vulnerabilidad de ejecución remota de códigos Object Broker de Microsoft Visual Studio 2005WMI
• CVE-2004-0549 Método ShowModalDialog y modificación de la ubicación para ejecutar el código

Salvo por las dos últimas (CVE-2006-4704 y CVE-2004-0549), esta lista es exactamente la misma que la de BlackHole.

Entonces, ¿cuál es el veredicto? Que estos dos paquetes no añaden nada nuevo al escenario ya conocido y siguen usando los mismos exploits y apuntando a Java.

Después de este análisis, llegamos a estas conclusiones:

• Java se ha convertido en la plataforma más atacada debido a que es la vía más sencilla para burlar los principales mecanismos de protección del sistema operativo.
• Los cambios en la clasificación de los cinco paquetes de exploits más populares no tienen relación con los exploits utilizados.
• No es necesario utilizar valiosos ataques de día-cero mientras puedan explotarse antiguas vulnerabilidades en equipos carentes de los respectivos parches de seguridad.

Una vez más, los ciberdelincuentes nos demuestran cuánto les preocupa la ganancia que reportan sus inversiones y que harán lo que sea necesario para mantenerse un paso por delante de los mecanismos de seguridad informática. Si aplicamos el conocido principio: “ la seguridad es tan sólida como el eslabón más débil”, en este caso, Java es este eslabón.

En Kaspersky Lab seguiremos analizando este escenario en lo que queda del año y seguiremos muy de cerca cualquier cambio llamativo que experimenten los vectores de ataque.