Los bootkits: el desafío de 2008

El término MalWare 2.0, tan usado en nuestros análisis, describe el modelo contemporáneo de funcionamiento de los complejos programas nocivos que se formaron hacia finales de 2006. Los más claros representantes y pioneros del MalWare 2.0 son los gusanos Bagle, Warezov y Zhelatin.

Las principales características de este modelo son:

• la red de ordenadores infectados no tiene un centro de administración;
• incluye de métodos para contrarrestar activamente los intentos de analizarlo y para obtener el mando;
• envíos masivos de corta duración con códigos nocivos;
• usa de forma muy correcta los métodos de ingeniería social;
• se usan diferentes métodos de propagación y al mismo tiempo se van abandonando los más evidentes (correo electrónico);
• se usan diversos módulos (en vez de uno universal) para realizar diferentes funciones nocivas.

El desarrollo del MalWare 2.0 crea una serie de problemas a la industria antivirus. En nuestra opinión el más importante es la incapacidad de las soluciones antivirus tradicionales -basadas en el análisis por firmas o heurístico- para contrarrestar de forma fiable los ataques antivirus, y esto sin mencionar los problemas de tratamiento de los sistemas ya infectados.

Entre los incidentes acaecidos en 2008 y que hicieron patente la peligrosidad del MalWare 2.0 hay que destacar la famosa historia del rootkit Rustock. (Analizamos detalladamente Rustock en nuestro artículo “Todo sobre el rootkit Rustock“). Fue precisamente en Rustock donde se implementó una gran variedad de nuevas tecnologías, métodos y trucos que a la larga pueden ejercer una fuerte influencia en el desarrollo futuro del MalWare 2.0.

El incidente que analizaremos detalla los métodos de lucha entre los autores de virus y las compañías antivirus, mostrando al mismo tiempo la importancia de las nuevas tecnologías de defensa.

Los misteriosos “reinicios”

A mediados de agosto en varios foros de Internet aumentaron los mensajes de los usuarios que se quejaban de que sus equipos se reiniciaban después de haber visitado algunos sitios web. Pero no estaba nada claro cuál era el motivo de los reinicios. Los usuarios no observaban ninguna correlación del fenómeno con los programas instalados y el hardware. Quedaba una sola posibilidad: la causa de los reinicios estaba en los sitios después de cuya visita ocurría el reinicio.

El primer análisis del contenido de las páginas sospechosas no arrojó ningún resultado. Para infectar los equipos de los usuarios, en la mayoría de los casos, los delincuentes alteran un sitio legal e incluían enlaces a direcciones que contienen exploits. Esta técnica se llama “drive-by-download” y permite, al visitar el sitio infectado, instalar programas nocivos en el equipo del usuario de forma oculta. En este caso no se pudo detectar ni etiquetas iframe ni scripts sospechosos.

Se podía atribuir los problemas de los usuarios al reinicio automático de Windows después de instalar sus actualizaciones, sobre todo porque las fechas coincidían con la habitual publicación de parches de Microsoft. Pero resultó ser algo mucho más serio.

Durante la investigación posterior, usamos varias “máquinas virtuales” para visitar los sitios sospechosos. Pero no nos limitamos a visualizar los sitios web, sino que ejecutamos más acciones, como entrar a diferentes secciones y seguir los enlaces. ¡Y después de cierto tiempo el equipo de prueba se reinició!

El análisis del sistema mostró que se había modificado el sector de inicio del disco duro. Estas modificaciones podrían ser un indicio de la presencia de un bootkit. En el informe del primer trimestre de 2008, Kaspersky Lab publicó un artículo sobre los bootkits y los problemas que pueden causar (viruslist.com). Pero desde marzo de 2008 no se detectaron nuevas variantes del bootkit.

¿Ha vuelto a aparecer?

Los enlaces sustituidos

Después de determinar los sitios visitados y seguir los enlaces que producían el reinicio de los ordenadores, pudimos realizar un análisis más detallado.

Pero resultó que los delincuentes habían usado un método de sustituir los enlaces, que a pesar de no ser nuevo, era muy original. No se trataba de agregar al código de los sitios adulterados etiquetas iframe o scripts, ya que estas modificaciones son muy fáciles de detectar. Lo que se hacía era sustituir los enlaces “legales” del sitio por otros “nocivos”.

Un enlace “legal” tiene el siguiente aspecto:
<a href=”http://atm.n****.com“><B>atm.n****.com</B></a>

Pero después del ataque al sitio el enlace se transforma en:
<a href=”http://***.com/cgi-bin/index.cgi?dx“><B> atm.n****.com</B></a>

Para que el equipo se infecte, no basta con que el usuario visite la página del sitio dañado, sino que también debe pulsar el enlace sustituido. Esto reduce la cantidad de víctimas potenciales expuestas a la infección, pero según nuestros cálculos, la reducción es insignificante, sobre todo si la sustitución de los enlaces se ha hecho a mano y han sido escogidos con cuidado por el delincuente.

Las primeras menciones sobre los sitios con direcciones tipo ***.com/cgi-bin/index.cgi?dx aparecen en Internet aproximadamente desde principios de 2008, cuando los propietarios y usuarios de sitios legales empezaron a quejarse de los extraños enlaces que encontraban en los recursos a su cargo. Quedó claro que había muchos de estos “centros de contagio”, pero a pesar de la abundancia de los nombres de dominio, todos ellos estaban ubicados en los mismos servidores.

He aquí una pequeña parte de los sitios que encontramos:

 


Ejemplos de ubicación de los servidores que infectan a los usuarios con el bootkit (De izquierda a derecha: nombre del dominio, dirección IP del servidor, subred del servidor, Internet).

El “exploit personal”

Pero, ¿qué ocurre cuando el usuario pulsa el enlace sustituido? El servidor procesa la solicitud entrante y recibe información sobre el sitio desde el que llegó el usuario, cuál es su dirección IP, qué navegador usa y qué complementos tiene instalados. Basándose en esta información, el servidor asigna al usuario un identificador único (ID), que se almacena en el servidor.

Ejemplo de ID asignado al servidor de uno de los visitantes del sitio nocivo:
index.cgi@ac6d4ac70100f060011e964552060000000002e4f11c2e000300190000000006

En este caso, por ejemplo, las últimas cifras del ID significan que el usuario tiene instalado en su equipo el programa Acrobat Reader 6.0.

A continuación se genera un exploit para este usuario concreto. Si el usuario tiene instalada una versión vulnerable de Acrobat Reader, se le instalará un exploit que apunte a esa vulnerabilidad; si tiene Real Player, un exploit ad hoc, etc. Dependiendo del ID del usuario, el servidor genera una llave de ocultación con la que se cifra el exploit.

 


Ejemplo de código de ocultación del exploit

Los exploits instalados con más frecuencia eran los dedicados a ficheros PDF, SWF y QuickTime. La lista de las vulnerabilidades usadas por los delincuentes es bastante larga y aumenta constantemente. Las más populares son las siguientes vulnerabilidades:

• CVE-2007-5659
• CVE-2006-0003
• CVE-2006-5820
• CVE-2007-5779
• CVE-2008-1472
• CVE-2007-0018
• CVE-2006-4777
• CVE-2006-3730
• CVE-2007-5779
• CVE-2008-0624
• CVE-2007-2222
• CVE-2006-0005
• CVE-2007-0015

Después de generado, el exploit empieza a usar el programa vulnerable para ejecutarse en el sistema. Durante su funcionamiento, se descarga al equipo un programa troyano-dropper, generado por el servidor usando la llave única del servidor y el identificador del usuario almacenado en la base de datos del servidor.

Todo tiene un aspecto absolutamente inofensivo y no genera sospechas: después de que el exploit se ejecuta, el servidor lleva al usuario a la dirección real de la página que quería visitar cuando pulsó el enlace sustituido. La víctima llega a la página que quería sin darse cuenta de que su equipo fue redirigido a otro servidor e infectado.

Además, si este usuario pulsa una vez más el enlace sustituido, el exploit no repetirá el intento de infección y el usuario será remitido a la página legal. El servidor nocivo lleva una lista de todas las visitas y no permite más de una vez un único ID.

La resurrección de Neosploit

Y… surge la pregunta: ¿qué producto se usa para generar los “exploits personales” de los usuarios? Fue grande nuestra sorpresa al descubrir que se trataba de un “muerto”: el panel de administración Neosploit.

El conjunto de exploits Neosploit
A finales de julio de 2008 aparecieron mensajes (ddanchev.blogspot.com, blogs.zdnet.com) que afirmaban que la famosa banda delincuente que creó y se dedicaba a la propagación y asistencia técnica de Neosploit había dejado de existir.

En la declaración difundida por los representantes de este grupo, se notificaba:

Cuando alguna empresa abandona sus negocios con tanta brusquedad, suele ser porque el grupo ha llamado la atención de los órganos de seguridad estatales o porque los delincuentes se están preparando para dar un gran golpe y tratan de contar con coartadas.

La última versión de Neosploit, después de la cual se dejó de crear y vender nuevas versiones, fue la 2.0.17. Esta vez, en el servidor que generaba los exploits, ¡vimos el panel de administración 2.0.23!

 


Ventana principal del panel de administración

La interfaz del panel de administración de Neosploit, a pesar de su humilde apariencia, tiene poderosas funciones.

 

Ventana de creación de nuevo usuario del sistema

El panel de administración de Neosploit que se encarga de la generación de los exploits es un fichero ejecutable escrito en C++ y compilado para los sistemas operativos Linux y FreeBSD.

 


Aspecto interno del panel de Neosploit

 


Código del servidor responsable de ocultar los exploits

Neosploit está diseñado para instalarse en servidores hosting y ejecutarse de una manera rápida. Sin embargo, en el uso de Neosploit hay un problema muy serio ya que es un “producto comercial”. El problema consiste en que al comprar Neosploit, se lo puede usar para un número limitado de conexiones, algo parecido a los productos shareware que se pueden usar hasta cierto momento.

Cada vez que se intenta infectar a un usuario y generar un exploit, Neosploit se conecta con un servidor que, probablemente, lleva una cuenta de las conexiones (durante nuestra investigación este servidor estaba en Ucrania). Basándose en la cantidad de usuarios infectados los autores de Neosploit pueden controlar el uso de su “criatura” y el pago de sus servicios. Lo más probable es que si no se puede establecer conexión con este servidor, el exploit no se genere y el usuario no se contagie.

Bootkit

Después de cargarse en el sistema, el programa troyano-dropper se ejecuta con la ayuda del programa vulnerable, extrae de su cuerpo el instalador del bootkit y le transfiere el ID único del usuario.

Posteriormente, el programa instalado introduce modificaciones en el sector de arranque del disco duro y graba el cuerpo del programa nocivo en los sectores del disco.

Ejemplo de registro grabado en el sector de arranque del disco

 


Ejemplo MBR infectado

Si todas estas acciones en el sistema se realizan con éxito, el dropper le da al equipo la orden de reiniciarse. Y es precisamente este reinicio inesperado durante la navegación en Internet lo que despertó las sospechas de los usuarios y lo que les motivó a escribir en los foros para tratar de comprender lo que estaba pasando.

Después del reinicio, el bootkit intercepta una serie de funciones del sistema y empieza a funcionar a toda máquina en el sistema, pero camuflando su presencia y actuando en calidad de integrante de una red zombi (botnet).

 

Esquema de infección del usuario

El centro de control (CC) migrante

Todas las tecnologías que descubrimos durante el análisis del mecanismo de penetración del programa nocivo en los equipos nos parecieron bastante interesantes, en parte originales (sustitución de los enlaces, generación de los exploits en tiempo real para un sistema en concreto), pero no eran excepcionales. Ya las habíamos observado con anterioridad, pero antes de agosto de 2008 no se habían usado en un mismo ataque.

La verdadera sorpresa nos esperaba en el análisis de la red zombi: el centro de control (CC) todo el tiempo cambiaba de dominio.

Según los datos de nuestro análisis, el CC cambiaba de dominio de dos a tres veces por día. Por la mañana podía funcionar en aykjfgves.com, al mediodía en dmiafgves.com y en la noche en gfdpves.com. De hecho, cada vez que un equipo infectado y que es parte de la red se enciende, tiene que buscar el CC activo en ese momento.

Estas botnets son muy difíciles de detectar, y aunque se haga, no es fácil desactivarlas. En cualquier momento los delincuentes pueden desplazar el CC a cualquiera de las decenas o cientos de dominios que poseen y los investigadores se sienten impotentes. Pero incluso en el caso de que un CC sea detectado, a las dos horas cambiará de dominio y su ubicación sólo se podrá averiguar por medio del análisis de los paquetes de red de los bots, que también buscarán su “nueva casa”.

Sin lugar a dudas, este método está destinado a evitar que la competencia robe la botnet y a evadir las investigaciones de las compañías antivirus y de los órganos de seguridad.

 


Ejemplo de ubicación de los servidores de administración de la botnet.
(De derecha a izquierda: nombre del dominio, dirección IP del servidor, subred del servidor, sistema autónomo de Internet).

La generación de nombres de dominio según un algoritmo especial y el registro de los dominios correspondientes permite a los delincuentes mantener el centro de administración de la botnet en constante movimiento. Para dar de alta los dominios se usan diferentes registradores de dominios: norteamericanos, africanos, asiáticos y europeos. En los datos de registro proporcionados por los propietarios hay una huella rusa, pero los datos en sí son falsos.

En calidad de servidores hosting de los centros de administración se usan diferentes recursos ubicados en todo el mundo. El centro de administración tiene la capacidad de desplazarse a cualquier servidor hosting en pocos minutos lo que le permite mantenerse activo y evitar ser clausurado.

 


Ejemplo de ubicación del servidor que determina la conexión del nombre de dominio y la dirección IP del centro de administración de la botnet.
(De derecha a izquierda: nombre del dominio, dirección IP del servidor, subred del servidor, sistema autónomo de Internet).

Este método es similar a la tecnología Fast-Flux, usada activamente por los gusanos de la familia Zhelatin (Gusano de la tormenta). La diferencia consiste en que Fast-Flux permite cambiar constantemente las direcciones IP de los dominios nocivos, mientras que la tecnología del bootkit permite además cambiar los nombres de dominio.

En el centro de administración de la botnet hay una base de dominios registrados que pueden utilizarse para alojar el centro de administración.

Ejemplo de dominios registrados

Durante la infección primaria del equipo, en el periodo de ejecución del exploit, se carga un bootkit destinado a funcionar con el centro de administración activo en ese momento. Después de reiniciar el sistema, cuando el bootkit empieza a funcionar plenamente, el bot trata de conectarse a este centro. El programa nocivo genera un paquete de red especial basado en el ID del equipo infectado y trata de enviarlo al centro de administración que ya contiene información sobre los equipos infectados.

 


Ejemplo de paquete enviado

Si falla el intento de conectarse al centro de administración de la botnet, el bot usa un algoritmo especial para generar nombres de dominios en las zonas .com, .net y .biz. El orden de nombres de dominio generados depende de la fecha y hora en curso. El backdor trata de establecer conexión con cada uno de estos dominios y enviar el paquete generado en calidad de llave.

 


Ejemplo de listado de dominios

Cuando uno de los dominios acepta el paquete y responde con un paquete especial, el bot se conecta a éste en calidad de cliente y empieza un proceso de “relación cifrada” con el centro de administración de la botnet. El resultado de esta relación suele ser la instalación de un módulo DLL adicional en el equipo infectado.

 

Esquema parcial de funcionamiento de la botnet

El módulo espía

Desde principios de 2008 el bootkit se ha convertido en objeto de investigación de varios expertos, pero todos se limitaron a analizar el funcionamiento de su sección rootkit y de la forma en la que el cuerpo del programa nocivo se grababa en los sectores del disco duro. Algunos de los investigadores trataban de analizar con más profundidad el esquema de funcionamiento del botnet y las instrucciones de administración.

Sin embargo, todas estas investigaciones, cuyos resultados ya conocemos, no daban respuesta a lo que en nuestra opinión era la principal pregunta ¿para qué? O, en palabras más sencillas… ¿dónde está el dinero?

Para nosotros, la tarea principal era poner todos los puntos sobre las íes en la historia del bootkit. Y para ejecutarla, teníamos que entender qué era lo que el bootkit escondía en el sistema con trucos tan sofisticados.

El equipo infectado, después de su primera conexión con el centro de administración de la botnet, recibe un paquete de datos cifrados de más de 200KB. El bootkit acepta el paquete y lo descifra. En el interior del paquete hay una biblioteca DLL que el bootkit carga directamente a la memoria RAM y que no existe como fichero en el disco.

Así, el bootkit garantiza la total invisibilidad de la DLL cargada durante el análisis del sistema con métodos tradicionales y con la mayoría de los programas antivirus. ¿Recuerdan lo que hacía Rustock? También cargaba una DLL en la memoria, pero la DLL también existía en el disco del ordenador. Pero el bootkit opera de una forma más sutil.

Por supuesto, un código que existe exclusivamente en la memoria RAM del ordenador desaparece si se lo reinicia, y el sistema queda limpio, a excepción del bootkit. Pero este “inconveniente” tiene sus ventajas: los programas antivirus que revisan la memoria RAM del ordenador durante el inicio del sistema operativo no encuentran nada sospechoso por la sencilla razón de que no hay nada sospechoso. Pero tan pronto como el ordenador se conecta a Internet, el bootkit establece una conexión con el centro de administración que una vez más carga la DLL.

¿Cuál es la función de la DLL?

Recurriremos a la historia del nombre de Sinowal, según la clasificación de Kaspersky Lab. A finales de 2007, cuando apareció el bootkit, este nombre ya existía: en la categoría Trojan-Spy.Win32.Sinowal se encontraba una gran cantidad de troyanos espía que robaban datos a los usuarios, sobre todo de las cuentas de acceso a los sistemas de banca online.

Al analizar el bootkit, notamos que el algoritmo de ocultación del cuerpo del bootkit es idéntico al algoritmo de ocultación usado por Trojan-Spy.Win32.Sinowal y llegamos a la conclusión de que los autores del bootkit y el troyano espía eran los mismos. Sin tener detalles de la DLL, la única confirmación del origen común de los dos programas nocivos era la similitud de los algoritmos de ocultación.

Después de que logramos extraer la DLL de la RAM del ordenador y comprendimos los principios de su funcionamiento, obtuvimos un veredicto final: la DLL es idéntica a Trojan-Spy.Win32.Sinowal y ejecuta las mismas funciones de espionaje.

De esta manera, después de autorizar el bot en la red, se carga en el equipo infectado un módulo DLL que sirve para robar contraseñas e interceptar el tráfico de red del usuario.

Podemos decir que Sinowal es un “ladrón universal”. Al penetrar en el sistema, en un abrir y cerrar de ojos, empieza a buscar todas las contraseñas y cuentas de una serie de aplicaciones.

 


Código desensamblado del módulo de robo de contraseñas

Lista de las aplicaciones atacadas

La mayoría de las aplicaciones afectadas por el módulo de robo de información confidencial se usan para la gestión de sitios web. Esta es una información de importancia crítica para los delincuentes ya que pueden utilizar estos sitios para instalar el centro de administración de la botnet o los exploits.

Pero lo más valioso desde el punto de vista de los delincuentes son las cuentas de los sistemas bancarios.

 


Listado parcial de los sitios bancarios cuyas contraseñas roba el módulo.
En total el listado contiene unos 3.000 sitios.

Al interceptar todas las conexiones de red del equipo infectado, la DLL busca en el tráfico conexiones a los sitios bancarios. Todos los datos que el usuario introduce en estos sitios los envía de inmediato al servidor de los delincuentes.

Usando el bootkit como plataforma que tiene acceso ilimitado a los recursos del sistema operativo, el módulo espía adquiere la capacidad de hacer ataques “Man-in-the-middle”, interceptando por ejemplo la información confidencial del navegador internet.

El módulo puede ejecutar prácticamente todas las funciones de los programas espía, desde la simple intercepción de datos del teclado hasta la sustitución de las conexiones seguras SSL. Al hacer solicitudes a los sitios web mediante https, el espía puede abrir en el navegador ventanas adicionales para autorizarse y el usuario puede, por error, introducir sus datos en estas ventanas, pensando que son las del sitio bancario.

El espía puede redireccionar las solicitudes del usuario a sitios phishing.
Toda la información recogida se cifra y envía a un servidor especial.

 


Sistema de ubicación del servidor que admite conexiones SSL y es usado para redireccionar al usuario a la página phishing (De izquierda a derecha: nombre del dominio, dirección IP del servidor, subred del servidor, sistema autónomo de Internet).

 


Ejemplo de ubicación del servidor al que se enviarán las contraseñas robadas (De izquierda a derecha: nombre del dominio, dirección IP del servidor, subred del servidor, sistema autónomo de Internet).

La red maliciosa

Al analizar el esquema general del ataque, hay que tener en cuenta que todos los componentes de la red del bootkit están en constante movimiento. Como los delincuentes controlan los servidores de dominios (Name Servers), pueden cambiar rápida y fácilmente la ubicación de los exploits, el panel de administración del CC, el lugar de carga de los módulos y de la recolección de información confidencial. De hecho, esta posibilidad le confiere una gran estabilidad al sistema ya que la configuración en tiempo real de los componentes de la red se puede realizar sin hacer cambios adicionales a la configuración del bootkit y sus módulos.

 

Esquema de funcionamiento del bootkit con los servidores

Dimensiones de la infección

La difusión del primer bootkit que apareció a finales del año pasado y el rootkit Rustock se realizaba por medio de los recursos del grupo IframeBiz. La aparición del actual bootkit transcurre según un escenario totalmente diferente, mucho más tecnológico y basado en muchas de las conclusiones obtenidas después de las epidemias de Rustock y Sinowal.

Por supuesto, no se pueden tomar como indicador las quejas de los usuarios sobre el reinicio inesperado del ordenador. La respuesta definitiva sólo la puede dar la estadística de la botnet obtenida desde su centro de administración, pero nosotros no contábamos con acceso al panel de administración. De todos modos, es posible mencionar ciertas cifras.

En el momento del análisis del incidente habíamos descubierto cinco servidores principales, desde los cuales se cargaban los exploits. La cantidad total de visitas a estos servidores desde, por ejemplo, el territorio de EEUU era de cerca de 200.000 personas por día.

 

Cantidad de visitas únicas a dos sitios con exploits desde el territorio de EEUU

Como ya hemos mencionado, el panel de administración de la botnet cambia constantemente de lugar según determinado algoritmo y no todos los bots se conectan después del “traslado”.

Los gráficos que presentamos más abajo muestran los estadios de migración de algunos centros, una especie de “cola de cometa” de las conexiones de los bots y los datos sobre la cantidad de sistemas infectados. Como se puede observar, el tamaño total de la botnet alcanzó prácticamente los 100.000 bots, lo que es una cifra bastante alta. Remarcamos que en este caso se toman en cuenta sólo los usuarios norteamericanos.

 

Cantidad de visitas únicas desde el territorio de EEUU al panel de administración que se traslada al siguiente dominio

 

Cantidad de visitas únicas desde el territorio de EEUU al panel de administración que se queda en los viejos dominios

Métodos de defensa

Los autores del bootkit se tomaron muchas molestias para crear un complejo sistema con buena defensa, máxima movilidad y a prueba de balas, puliendo todas las etapas de su trabajo: desde la etapa de infección de los usuarios hasta la organización de la gestión de la botnet, y no cometieron errores ni siquiera en cosas de segunda importancia (como la introducción de iframe en el código de la página).

A pesar de las refinadas técnicas usadas por los autores del bootkit, los productos antivirus modernos deben ser capaces de evitar la penetración de códigos nocivos en el equipo.

¿Qué se puede contraponer a los ciberdelincuentes en cada etapa de la infección?
Los trucos usados por los delincuentes para inducir a los usuarios a visitar los sitios nocivos y la generación de exploits únicos no sólo tienen el objetivo de infectar la mayor cantidad posible de víctimas, sino que también están centrados a la lucha contra una serie de tecnologías antivirus existentes.

Así, la sustitución de enlaces (en vez de añadir iframe) está pensada para eludir los métodos tradicionales de análisis del tráfico web, durante el cual los iframe sospechosos se escudriñan con mucha más atención o se los bloquea totalmente.

Teniendo en cuenta las decenas o centenas de miles de casos de adulteración de sitios legales y la introducción en éstos de páginas de contenido nocivo, el método más efectivo de defensa contra este tipo de amenaza son las tecnologías de bloqueo de los sitios nocivos conocidos.

 


Kaspersky Internet Security 2009 prohíbe el acceso a una página infectada

Los exploits se generan de forma exclusiva y automática para cada nuevo usuario, el código del exploit se modifica, pero el mecanismo de ocultación sigue siendo el mismo. Esto significa que el antivirus puede detectar el script de ofuscación por medio de firmas o técnicas heurísticas.

 

Ejemplo de detección de la ofuscación de exploits

Si a pesar de todo el exploit ya hubiese sido cargado en el equipo, no se activará si el usuario tiene la costumbre de instalar los “parches” del sistema operativo y de las aplicaciones. El escáner de vulnerabilidades ayuda a detectar el software que puede ser afectado.

 


Detección de un componente del reproductor flash vulnerable

 


Descripción de las vulnerabilidades en el sitio Viruslist.com

Supongamos que el usuario tiene una aplicación vulnerable y el exploit se ha activado. En este caso se descarga al equipo el dropper del bootkit, un fichero ejecutable que se genera en el servidor a la medida de un usuario en concreto, lo que dificulta la detección por firmas.

En este estadio, el método más efectivo de defensa antivirus es la protección proactiva, capaz de analizar un nuevo fichero desconocido, determinar sus funciones y llevar a cabo el análisis heurístico de su código y comportamiento nocivo.

 


KIS 2009 analiza un fichero ejecutable…

 


… y bloquea su ejecución si el análisis detecta un peligro potencial

 

Una aplicación ha recibido un grado alto de peligrosidad a que activó la heurística de Heur.Backdoor.Generic

Si en el momento de la infección el ordenador del usuario no contaba con la protección de un buen programa antivirus, el bootkit introducido en el sistema empieza a funcionar antes del inicio del sistema operativo y del antivirus, lo que le permite controlar funciones importantes del sistema y hacerse invisible.

En este estadio es posible detectar la infección del sistema mediante el análisis del tráfico de red generado por el equipo infectado. Las solicitudes generadas por el bot durante la búsqueda del centro de administración son muy fáciles de detectar. Además, el bootkit no intercepta las funciones de red y este análisis se puede efectuar hasta en un sistema infectado. En esta etapa entra en acción el cortafuegos (firewall) con su función de sniffer de paquetes.

Una vez detectada la actividad sospechosa, el cortafuegos puede bloquearla y con esto minimizar los daños potenciales, incluso en el caso de que no se hubiese detectado el bootkit.

Se puede detectar y neutralizar el código nocivo con la ayuda de un programa antivirus que cuente con un potente antirootkit, primero en la memoria RAM del sistema…

 


Detección del rootkit en la memoria del equipo infectado

… y después en el sector de inicio del disco duro.

 


Curación del MBR

Como resultado el sistema queda completamente libre del bootkit.

 


Informe sobre la total curación del sistema realizada por KIS 2009

Conclusiones

En su tiempo, los bootkits fueron un gran paso adelante en la creación de virus. Ahora, han adquirido potentísimos instrumentos de difusión y funcionamiento en botnets.

Las tecnologías encarnadas en el rootkit Rustock le dieron al programa nocivo un amplio espectro de posibilidades para evitar ser detectado por las compañías antivirus y hacer que su análisis sea lo más complicado posible. Por su parte, el bootkit usa diferentes métodos para evitar ser detectado en las etapas tempranas de la infección, trata de contagiar a la mayor cantidad posible de usuarios y evita que la botnet sea desactivada.

Son impresionantes las dimensiones de la organización del trabajo y las soluciones técnicas aplicadas por los delincuentes: programación de profundo nivel; explotación de las vulnerabilidades de decenas de programas; transición del régimen de inicio del SO, nuevo contagio, creación de aplicaciones en C++ para sistemas *nix; protocolos criptográficos; protocolos de autorización de los bots en el sistema y un largo etcétera.

Sin duda, la programación de semejante sistema llevó varios meses, y su funcionamiento exige constantes ajustes y gastos de adquisición o creación de nuevos y nuevos exploits, dominios, servidores de hospedaje, etc.

Es poco probable que la creación, planificación, realización y soporte de toda esta estructura haya sido obra de una o dos personas. Estamos frente a una criatura de varios grupos de ciberdelincuentes, que trabajan en estrecho contacto, cada uno de los cuales responde de una parte del sistema.

La historia del bootkit refleja todo el espectro de las principales amenazas a la seguridad informática de los usuarios comunes. Sin ninguna excepción, todos los métodos y tecnologías que hemos analizado, son utilizados activamente por los delincuentes en la aplastante mayoría de los programas nocivos.

La infección mediante navegador Internet, las tecnologías rootkit, las botnets, el robo de datos de los usuarios, la criptografía, la ofuscación , la resistencia a los programas antivirus… en el tercer trimestre de 2008 tuvimos que vérnoslas con cada una de ellas por separado, pero en la historia del bootkit, estaban todas juntas.

Para contrarrestar estos sistemas es necesario usar un amplio espectro de tecnologías de defensa: antivirus web, filtración de tráfico, analizadores de comportamientos, máquinas virtuales, sistemas de análisis de tráfico de red y cortafuegos. Un antivirus moderno no sólo debe contener tecnologías de lucha contra los rootkits, sino que debe ser capaz de neutralizar sus subespecies, los bootkits.