Cómo se cierra un agujero negro

Hoy en día, la explotación de vulnerabilidades en programas legítimos es uno de los métodos más comunes de infección de ordenadores. Según nuestros datos, los ataques más usuales contra los usuarios son los así llamados exploits para las vulnerabilidades en Oracle Java. Sin embargo, las soluciones de seguridad de hoy son capaces de neutralizar eficazmente los ataques drive-by lanzados mediante paquetes de exploits. En este artículo analizaremos la forma en que un equipo se infecta con el paquete de exploits BlackHole y los principales mecanismos de protección a nuestro alcance.

Paquetes de exploits

Por lo general, en lugar de usar un exploit individual, los atacantes prefieren elaborar paquetes listos para usar, conocidos como paquetes de exploits (exploit packs).  De esta manera pueden mejorar considerablemente la efectividad de su ‘penetración’ ya que cada ataque puede utilizar uno o más exploits para las vulnerabilidades en el software instalado en el equipo atacado.

Mientras que antes los exploits y los programas maliciosos que descargaban en el equipo atacado tenían los mismos creadores, hoy en día este segmento del mercado negro opera según el modelo Software como Servicio (SaaS, por sus siglas en inglés). Como resultado de la división del trabajo, cada grupo de ciberdelincuentes se especializa en un área específica: algunos crean y venden paquetes de exploits, otros inducen a los usuarios a dirigirse hacia las páginas que lanzan exploits (tráfico dirigido), y otros escriben los programas maliciosos que se distribuyen mediante ataques drive-in. Hoy, si un ciberdelincuente quiere infectar equipos con, digamos, una variante del troyano ZeuS, todo lo que tiene que hacer es comprar un paquete de exploits listo para usar, configurarlo y llegar a tantas víctimas potenciales que visiten su sitio malicioso (página de aterrizaje) como sea posible.

Los atacantes recurren a una variedad de métodos para desviar a los usuarios hacia la página de aterrizaje de un paquete de exploits. El mayor riesgo al que se enfrenta el usuario es el de sitios web legítimos hackeados y la inyección de scripts de elementos iframe en su código. En este caso, basta con que el usuario visite un sitio conocido para que se produzca un ataque drive-in y se active silenciosamente un paquete de exploits. Los ciberdelincuentes también pueden usar sistemas legítimos de publicidad, como enlazar banners y avances con páginas maliciosas. Otro método preferido de los ciberdelincuentes consiste en distribuir enlaces a la página de aterrizaje mediante mensajes spam.

Infección de ordenadores de usuarios mediante paquetes de exploits: diagrama general

Existen muchos paquetes de exploits disponibles en el mercado: Nuclear Pack, Styx Pack, BlackHole, Sakura y otros. Más allá de los diferentes nombres, todas estas ‘soluciones’ funcionan de la misma manera: cada paquete de exploits incluye una variedad de exploits y un panel de administración. Asimismo, el funcionamiento de todos los paquetes de exploits se basa esencialmente en un mismo algoritmo.

Uno de los paquetes de exploits más populares en el mercado es el llamado BlackHole (agujero negro). Incluye exploits para vulnerabilidades en Adobe Reader, Adobe Flash Player y Oracle Java. Para maximizar su efecto, los exploits de este paquete se modifican de forma constante. A principios de 2013, analizamos tres exploits del paquete BlackHole para Oracle Java, razón por la que elegimos BlackHole para ilustrar los principios del funcionamiento de los paquetes de exploits.

Dentro del agujero negro

Hay que tomar en cuenta que toda la información sobre exploits, los contenidos de las páginas de aterrizaje, así como otros datos específicos tratados en este artículo (en especial los nombres de los métodos y clases, y los valores de las constantes), era válida en el momento en que se realizó nuestra investigación. Los ciberdelincuentes continúan desarrollando BlackHole: con frecuencia modifican el código de uno u otro exploit para evitar que las soluciones antivirus lo detecten (por ejemplo, pueden cambiar el algoritmo decodificador que utiliza uno de los exploits). En consecuencia, algunos códigos pueden variar respecto a los que mostramos en los siguientes ejemplos; sin embargo, los principios fundamentales de funcionamiento son invariablemente los mismos.

Página de aterrizaje de un paquete de exploits

La página de aterrizaje de un paquete de exploits sirve para determinar los parámetros de entrada y tomar decisiones sobre las acciones posteriores del paquete de exploits. Los parámetros de entrada incluyen la versión del sistema operativo instalado en el equipo atacado, las versiones del navegador y sus plugins, el idioma del sistema, etc. En general, los exploits que se usan para atacar un determinado sistema se seleccionan según los parámetros de entrada. Si el software para el que está diseñado el paquete de exploits no se encuentra en el ordenador atacado, entonces no se lleva a cabo el ataque. Otra razón para que el ataque no se realice es para evitar que los contenidos del paquete de exploits caigan en manos de los expertos antivirus de las compañías de soluciones de seguridad o de otros investigadores; por ejemplo, los ciberdelincuentes podrían bloquear direcciones IP que usan las compañías de investigación antivirus (crawlers, robots, servidores proxy), evitar que los exploits se activen en máquinas virtuales, etc.

La siguiente imagen de captura de pantalla muestra un código de la página de aterrizaje del paquete de exploits BlackHole.

Imagen de captura de pantalla de la página de aterrizaje del paquete de exploits BlackHole

Basta echar un vistazo a esta imagen para ver que el código JavaScript está ofuscado y la mayor parte de los datos están codificados.

Una visita a esta página de aterrizaje activa la ejecución del código inicialmente cifrado.

Este algoritmo, en su totalidad, podría haberse implementado con unas cuantas líneas de código, pero los ciberdelincuentes usaron técnicas especiales (marcadas con óvalos amarillos en la imagen de captura de pantalla) para dificultar su detección:

1.  se genera deliberadamente una excepción con el comando “document.body*=document”;
2.  se verifica el estilo del primer elemento <div> mediante el comando “document.getElementsByTagName(“d”+”iv”)[0].style.left===”””; observemos que con este propósito se inserta un elemento <div> vacío (en la segunda línea);
3.  se llama “if(123)”, que no tiene sentido, ya que esta expresión no siempre es verdadera;
4. se descomponen los nombres de las funciones para después concatenar las partes.

Además de estos trucos, los ciberdelincuentes realizan numerosos cambios mínimos en el código para dificultar la detección por el método de firmas. Aunque nuestro motor antivirus, por ejemplo, incluye un emulador de scripts y ningún cambio sencillo en constantes y operaciones afectará la eficacia de la detección, los trucos que acabamos de describir también pueden dificultar el funcionamiento del emulador.

Después de descifrarlo, el código aparece en RAM (nos referiremos a esto como el “script descifrado”). Consta de dos partes:

La primera es un módulo que se basa en la biblioteca gratuita PluginDetect, que sirve para determinar las versiones y capacidades de la mayoría de los modernos navegadores y sus plugins. Los ciberdelincuentes recurren a una variedad de bibliotecas, pero este módulo es un elemento clave en cualquier paquete de exploits. BlackHole emplea PluginDetect para seleccionar los exploits apropiados y que después se descargarán, dependiendo del software instalado en el equipo atacado. Por ‘apropiado’ entendemos aquellos exploits que tienen las mayores posibilidades de ejecutarse y de activar programas maliciosos en un determinado equipo.

La segunda es un código responsable del procesamiento de los resultados producidos por las funciones PluginDetect y de descargar los exploits seleccionados y activarlos.

En marzo de 2013, BlackHole usó exploits para las siguientes vulnerabilidades:

1. Versiones 1.7 a 1.7.х.8 de Java – CVE-2012-5076;
2. Versiones de 1.6 a 1.6.х.32, o menores a 1.6 de Java – CVE-2012-0507;
3. Versiones 1.7.х.8 a 1.7.х.10 de Java – CVE-2013-0422;
4. Versiones menores a 8 de Adobe Reader  – CVE-2008-2992;
5. Versiones 8, o de 9 a 9.3 de Adobe Reader – CVE-2010-0188;
6. Versiones 10 a 10.2.158 de Adobe Flash– CVE-2011-0559;
7. Versiones 10.3.181.0 a 10.3.181.23 y menores a 10.3.181 de Adobe Flash– CVE-2011-2110.

A continuación analizamos los exploits para las vulnerabilidades en Java.

Tres en uno

Tres exploits para Java se basan en el mismo mecanismo:

obtienen privilegios y descargan el programa malicioso (payload), que a su vez descarga y activa el archivo objetivo. Estos tres exploits también generan el mismo archivo .class de Java. Este es un claro indicio de que es la misma persona, o grupo, responsable del diseño de estos tres exploits. La única diferencia es la técnica empleada para obtener privilegios ilimitados para el archivo .class.

El archivo .class puede descargar y activar archivos, descifrando los parámetros autorizados por del script descifrado. Para dificultar aún más su detección, el archivo malicioso descargado suele estar cifrado y, por tanto, no comienza con un encabezado PE. El archivo descargado suele descifrarse en la memoria con el algoritmo XOR.

La autorización de los parámetros por el script descifrado es una forma conveniente para cambiar rápidamente los enlaces que llevan a programa malicioso descargado: sólo hay que modificar los datos en la página de aterrizaje del paquete de exploits sin tener que recompilar el applet malicioso de Java.

Las tres vulnerabilidades mencionadas arriba se conocen como fallas lógicas. Resulta imposible controlar los exploits para estas vulnerabilidades mediante herramientas automáticas como el monitoreo de integridad de la memoria o la generación de excepciones. Esto significa que estos exploits no se pueden detectar mediante las tecnologías DEP o ALSR de Microsoft ni con otras herramientas automáticas similares. Sin embargo, existen tecnologías capaces de hacerlo; un ejemplo de ellas es la Prevención automática de Exploits (AEP, por sus siglas en inglés) de Kaspersky Lab.

Protección antiexploits para Java

A pesar de los esfuerzos de los ciberdelincuentes, las soluciones de seguridad actuales pueden neutralizar eficazmente los ataques drive-in lanzados por paquetes de exploits. Por lo general, la protección contra los exploits incluye un paquete integrado de tecnologías capaces de neutralizar estos ataques en diferentes etapas.

Líneas arriba hemos descrito los principios de funcionamiento del paquete de exploits BlackHole. Ahora demostraremos, usando las soluciones de Kaspersky Lab como ejemplo, cómo funciona la protección en cada etapa de un ataque lanzado por BlackHole mediante exploits para Java. Ya que la forma de funcionamiento de otros paquetes de exploits es similar a la de BlackHole, la estructura de la protección que analizamos aquí puede muy bien aplicarse a ellos.

Protección por etapas contra un ataque drive-in

A continuación analizaremos qué componentes de la protección interactúan con el código malicioso y cuándo lo hacen.

Primera etapa: se bloquean los desvíos hacia la página de aterrizaje

El ataque se inicia inmediatamente después de que el usuario llega a la página de aterrizaje del paquete de exploits. Sin embargo, el componente web antivirus de la solución de seguridad puede bloquear el ataque antes de que se inicie, es decir, antes de que se active el script en la página de aterrizaje. Este componente de la protección verifica la dirección de la página web antes de que ésta se active. En esencia, se trata de una sencilla verificación de la URL de la página en una base de datos de enlaces maliciosos, pero que puede prevenir que el usuario visite la página de aterrizaje del paquete de exploits, siempre y cuando su dirección ya sea conocida como un recurso malicioso.

Es por esto que resulta crucial que los desarrolladores de soluciones antivirus añadan los enlaces maliciosos en sus bases de datos lo antes posible. Las bases de datos de URLs maliciosas pueden estar en el equipo del usuario o en la nube (es decir, en un servidor remoto). En este caso, las tecnologías de nube ayudan a minimizar la demora con la que un producto de seguridad empieza a bloquear un nuevo enlace malicioso. De este modo, se reduce el ‘tiempo de respuesta’ porque la solución de seguridad instalada en el equipo del usuario recibe la información sobre la nueva amenaza inmediatamente después de que ésta queda registrada en la base de datos de enlaces maliciosos, sin tener que esperar su actualización.

A su vez, los ciberdelincuentes se ven obligados a cambiar los dominios que usan para alojar las páginas de aterrizaje del paquete de exploits para evitar que las soluciones de seguridad las bloqueen. Esto definitivamente reduce la rentabilidad de su negocio.

Segunda etapa: detección por el módulo file antivirus

Si de alguna manera el usuario llega a la página de aterrizaje del paquete de exploits, entonces entran en acción los componentes del módulo file antivirus (el detector estático y el analizador heurístico). Estos componentes analizan la página de aterrizaje del paquete de exploits en busca de códigos maliciosos. A continuación analizaremos los principios de funcionamiento, las ventajas y los defectos de cada componente.

• El detector estático emplea firmas estáticas para detectar códigos maliciosos. Estas firmas sólo se activan con algunos fragmentos específicos del código, en particular con algunas secuencias de bytes específicas. Este es el método de detección de amenazas que se usaba en las primeras soluciones de seguridad cuyas ventajas son reconocidas:  alto rendimiento y facilidad para almacenar firmas. Todo lo que el detector hace para llegar a un veredicto es comparar la suma de verificación o la secuencia de bytes del código analizado con los registros en la base de datos antivirus. Las firmas tienen un tamaño de decenas de bytes y son fáciles de comprimir, lo que facilita su almacenamiento. El defecto más significativo del detector estático es la facilidad con la que una firma puede ‘evadirse’. Todo lo que el ciberdelincuente necesita hacer para que el detector no detecte un objeto es cambiar un solo byte. Este defecto lleva a otro, pues se necesita una gran cantidad de firmas para cubrir una gran cantidad de archivos, lo que ocasiona que el volumen de las bases de datos crezca rápidamente.
• El analizador heurístico también usa bases de datos, pero con un principio de funcionamiento completamente diferente. Se basa en el análisis de objetos, es decir, recopila y realiza un análisis inteligente de los datos de los objetos, identifica patrones, estadísticas, etc. Si los resultados de este análisis coinciden con una firma heurística, entonces el objeto queda detectado como malicioso. La principal ventaja de la firma heurística reside en que le permite a la solución antivirus detectar una gran cantidad de objetos similares, siempre y cuando las diferencias entre ellas no sean significativas. El defecto está en que, comparado con el proceso de firmas estáticas, el analizar heurístico puede resultar muy lento, lo que afecta el rendimiento del sistema. Por ejemplo, si una firma heurística no está diseñada eficazmente, es decir, si requiere una gran cantidad de operaciones para realizar sus verificaciones, puede afectar el rendimiento del sistema en el equipo en el que está instalada la solución antivirus.

Para evitar la detección heurística de un objeto, los ciberdelincuentes necesitan realizar mínimos cambios en el código del objeto (script, programa o archivo ejecutable). Este proceso, hasta cierto punto, puede automatizarse.

Para evitar la detección heurística, un diseñador de programas maliciosos tiene que averiguar qué mecanismos se usan para detectar el objeto. Una vez que ha analizado parcial o completamente el algoritmo, tiene que realizar cambios que para evitar que la firma heurística detecte el código del objeto malicioso.

Es obvio que ‘evadir’ la firma heurística inevitablemente le cuesta al ciberdelincuente más tiempo que hacerlo con las firmas estáticas. Esto significa que las firmas heurísticas tienen un mayor ‘tiempo de vida’. Por otra parte, después de que los autores del programa malicioso han modificado el objeto para que evada la detección heurística, al desarrollador de soluciones antivirus también le cuesta tiempo crear una nueva firma.

Como hemos mencionado líneas arriba, una solución antivirus utiliza diferentes juegos de firmas para analizar la página de aterrizaje. A su vez, los autores de programas maliciosos modifican sus objetos en la página de aterrizaje del paquete de exploits para evadir ambas detecciones de firmas. Si bien es suficiente descomponer los hilos en caracteres para evitar las firmas estáticas, para evadir las firmas heurísticas es necesario recurrir a las características más sutiles que ofrece JavaScript: funciones inusuales, comparaciones, expresiones lógicas, etc. En la primera parte de este artículo mostramos un ejemplo de este tipo de ofuscación. Es en esta etapa que suele detectarse el programa malicioso debido a la excesiva ofuscación del código, lo que puede considerarse como una característica de los objetos maliciosos.

Además de las bases de datos almacenadas en el disco duro del equipo, algunas firmas se encuentran en la nube. Estas firmas suelen ser muy simples, pero gracias al nuevo tiempo de respuesta, extremadamente breve (hasta cinco minutos desde la creación de la firma a su disponibilidad en la nube), los equipos de los usuarios quedan bien protegidos.

Tercera etapa: detección de exploits por firmas

Si la solución de seguridad falla en reconocer la página de aterrizaje del paquete de exploits, entonces se activa esta detección. Este método verifica qué plugins del navegador están instalados (Adobe Flash Player, Adobe Reader, Oracle Java, etc.), y decide qué exploits se descargarán y se ejecutarán. Seguidamente, la solución analiza cada exploit descargado de la misma manera en que analizó la página de aterrizaje del paquete de exploits, mediante el módulo antivirus y las firmas en la nube. A su vez, los atacantes tratan de evadir esta detección mediante ciertas técnicas, similares a las descritas anteriormente.

Cuarta etapa: detección proactiva de exploits

Si ninguno de los componentes responsables de la protección reactiva (método de firmas) ha detectado nada sospechoso en el análisis de los contenidos del paquete de exploits, y se ha ejecutado un exploit, entonces entran en acción los módulos de protección proactiva. Estos móndulos monitorean en tiempo real el comportamiento de las aplicaciones en el sistema y detectan cualquier actividad maliciosa.

Se clasifica cada aplicación en base a la información proporcionada por el análisis heurístico, a los datos de la nube, y a otros criterios como “Confiable”, “Con baja restricción”, “Con alta restricción” o “No confiable”. El Control de Aplicaciones limita la actividad de cada aplicación en base a esta categorización. A las aplicaciones en la categoría “Confiable” se les permite realizar todo tipo de actividades, a las de la categoría “Con baja restricción” se les niega el acceso a recursos como el almacenamiento de contraseñas, a las del grupo “Con alta restricción” no se les permite realizar cambios en las carpetas del sistema, etc. Un módulo llamado Application Control incorporado en todos los productos de Kaspersky Lab analiza las aplicaciones que se activan y las que se están ejecutando. Este componente monitorea la ejecución de programas en el sistema mediante anzuelos de bajo nivel.

Además de los mencionados, se utilizan las firmas de comportamiento de flujo (BSS, por sus siglas en inglés) que describen las actividades maliciosas para detectar comportamientos peligrosos de las aplicaciones. Analistas antivirus desarrollan estas firmas y después se las compara con el comportamiento de las aplicaciones que se están ejecutando. Esto permite que la protección proactiva detecte nuevas versiones de programas maliciosos que no estaban incluidas en las categorías “No confiable” o “Con alta restricción”. Debemos notar que este tipo de detección es el más efectivo, ya que se basa en el análisis de la actividad en tiempo real de las aplicaciones en lugar del análisis estático o heurístico. Asimismo, neutraliza por completo las técnicas de ofuscación y cifrado de códigos porque éstas no afectan en modo alguno el comportamiento de los programas maliciosos.

Para un control más riguroso de las aplicaciones, a fin de evitar que se exploten sus vulnerabilidades, utilizamos una tecnología llamada Prevención Automática de Exploits (AEP, por sus siglas en inglés). El componente AEP monitorea cada proceso que se activa en el sistema. En particular, verifica las pilas (stacks) de llamadas en busca de anomalías, verifica el código que inicia cada proceso, etc. Asimismo, realiza verificaciones selectivas de las bibliotecas dinámicas incorporadas en los procesos.

Todas estas medidas evitan que se activen procesos maliciosos resultantes de la explotación de vulnerabilidades. En realidad, esta es la última línea defensiva contra los exploits en caso de que se hayan rebasado los otros componentes de seguridad. Si una aplicación, como Oracle Java o Adobe Reader, tiene un comportamiento sospechoso como resultado de una explotación, la solución antivirus bloqueará la aplicación legítima vulnerable evitando que el exploit cause daños.

Puesto que la protección en esta etapa se basa en el comportamiento del programa, los ciberdelincuentes se ven obligados a recurrir a técnicas sofisticadas y que consumen muchos recursos para evadir la protección proactiva.

Quinta etapa: detección del programa malicioso descargado

Si un exploit logra pasar desapercibido, intentará descargar un programa malicioso (payload) y ejecutarlo en el equipo del usuario.

Como mencionamos anteriormente, el archivo malicioso suele estar cifrado para dificultar su detección, lo que significa que no comienza con un encabezado PE. El archivo descargado suele descifrarse en la memoria con el algoritmo XOR. Entonces el archivo se activa desde la memoria (por lo general, se trata de una biblioteca dinámica) o se instala en el disco duro para después activarlo desde esta unidad.

El truco de descargar un archivo cifrado PE le permite al programa malicioso engañar a las soluciones antivirus porque estas descargas se parecen a los flujos ordinarios de datos. Sin embargo, es esencial que el exploit active un archivo ejecutable descifrado en el equipo del usuario. Y una solución antivirus someterá este archivo a todas las formas de protección que hemos descrito en este artículo.

Conclusión

Los paquetes de exploits son sistemas integrados para atacar ordenadores. Los ciberdelincuentes dedican su tiempo y esfuerzos para mantener la eficacia de los sus paquetes de exploits y minimizar las detecciones. A su vez, las compañías antivirus no cesan en sus esfuerzos por mejorar continuamente sus soluciones de seguridad. Los desarrolladores de soluciones antivirus tienen ahora a su disposición una serie de tecnologías capaces de neutralizar los ataques drive-in en todas sus etapas, incluyendo las de explotación de vulnerabilidades.