Con este primer post, vamos a introducir una serie de artículos en los que trataremos en profundidad los rootkits, desde un repaso histórico, pasando pos los fundamentos, los distintos tipos, hasta un análisis profundo de una serie de rootkits.

Los posts corren a cargo de Hendrix y de un servidor, esperemos que sean de vuestro agrado, y sin más dilación...

Muchos usuarios habrán oído hablar de los rootkits... Tienen ya una dilatada historia, aunque en sus orígenes provienen del entorno de los Sistemas Operativos Unix y sus derivados.

Originalmente los rootkits fueron diseñados para realizar funciones en beneficio del usuario, aunque posteriormente, y de ahí su actual “popularidad”, pasaron a ser usados por los hackers para diversos propósitos.

Alrededor del 2004 empezaron a aparecer los primeros ejemplares para los Sistemas Operativos Windows, creciendo exponencialmente el número de estos. Fue en este momento cuando el término “rootkit” saltó a la palestra y empezaron a refinarse enormemente hasta llegar a los ejemplares que tenemos hoy en día.

En este artículo vamos a tratar de definir un poco más técnicamente que es un rootkit, como actúa, y porque puede ser tan potencialmente peligroso.



Un poco de historia y definición

El origen del término “rootkit” se encuadra dentro de los Sistemas Operativos Unix, en donde el usuario con mayor privilegio dentro del árbol jerárquico del Sistema es el superusuario o usuario root (raíz), si a esto le añadimos el término “kit”, tenemos una serie de herramientas que ayudan al atacante a mantener los privilegios administrativos. Es importante destacar esto, mantener, ya que si previamente no hemos conseguido privilegios de root nuestras posibilidades se verán mermadas enormemente.

Si un intruso fuese capaz de reemplazar los binarios básicos para la administración del Sistema Operativo mediante el uso de un rootkit, este se garantizaría el acceso como superusuario de una forma en la que no levantaría sospechas y sería bastante difícil de de descubrir.

Los rootkits conocidos de más antigüedad datan de principio de los 90, en concreto uno escrito por Lane Davis y Stecen Dake para SunOS, aunque también se conoce una especie de exploit equivalente a un rootkit hecho por Ken Thompson de Laboratorios Bell contra un laboratorio naval en California para ganar una apuesta.

Es importante no confundir los rootkits con virus o gusanos. La principal diferencia reside en el método de propagación y en la ocultación. Como los rootkits, los virus también alteran componentes Software del sistema, sin embargo, un virus está diseñado para dañar y en algún caso proveer servicios adicionales al atacante, de forma que será más fácil detectarlo por sus efectos. Un gusano está diseñado normalmente para escanear vulnerabilidades y aprovecharse de ellas para propagarse a otros hosts conectados, siguiendo una especie de bucle infinito. De nuevo, esto modifica el estado del host lo suficiente como para que haya indicios de que algo anormal está sucediendo, pudiéndose detectar y mitigar. Finalmente, un rootik está diseñado para mantener su propia integridad y permanecer oculto de cara al usuario y así poder proveer al atacante un acceso seguro y en muchas ocasiones de larga duración.

Un rootkit diseñado e implementado adecuadamente puede permanecer fácilmente oculto y operativo durante años sin dar ningún signo de su presencia al usuario final o a los administradores, esto suele suceder en redes empresariales donde la ingente cantidad de hosts y sistemas en general hace bastante difícil su detección si no se da mucho “el cante”.

A continuación pongo algunos datos históricos relacionados con los rootkits:

• 1989: Encontrados primeros “Zappers” en sistemas hackeados.

• 1994: Primeros rootkits para SunOS

• 1996: Primeros rootkits para Linux

• 1997: Aparición de LKM's (Loadable Kernel Module) en "Phrack"

• 1998: “Non-LKM kernel patching” propuesto por Silvio Cesare

• 1999: Adore LKM kit lanzado por TESO

• 2000: Lanzamiento de T0rnkit v8

• 2001: Primeras muestras de KIS y SucKit

• 2002: “Sniffer backdoors” empiezan a integrarse en los rootkits

Funcionalidades:

Aunque hay que tener en cuenta el cambio de escenario que supone trabajar en un Sistema Operativo o en otro, hay una serie de funcionalidades básicas que todo rootkit implemente (o debería) y que pasamos a comentar brevemente:

• Mantenimiento del acceso
• Destruir/ocultar evidencias
• Recopilación de información

• Mantenimiento del acceso

Esto suele estar asociado con el uso de backdoors, tanto locales como remotas. Primero consideremos los backdors remotos (aplicaciones que permiten un acceso remoto de forma trasparente para el host infectado). Algunos de los métodos usados son los siguientes (ordenados por nivel ascendente de ocultación):

• Telnet o Shell en un puerto TCP

Un atacante podría simplemente conectarse al sistema vía telnet o una shell “pegada” al viejo inetd (normalmente en un puerto alto). La primera opción es fácilmente detectable por el sistema y apenas se usa. La segunda nos servirá para evadir a los administradores despistados o poco hábiles, ya que no generará logs como telnet. El backdoor basado en inetd.conf data de los años 80 e incluso antes. Puede ser fácilmente descubierto buscando entradas extrañas en /etc/inetd.conf. Algo similar se puede conseguir “troyanizando” cualquier demonio que cree un socket y se quede a la escucha, como por ejemplo: sshd, ftpd, sendmail, named, httpd, etc...

• SSH (el normal, o troyanizado en un puerto alto)

Usado por muchos atacantes novatos, suele ser común generar un nuevo demonio ssh que corra en un puerto alto. Provee beneficios sobre la opción anterior, como el uso de encriptación en la comunicación (nos saltamos a los IDS's). Los ssh propios no dejarán evidencias en los logs, así como normalmente se ocultarán a los ojos de las herramientas adminitrativas como netstat o top.

Un escaneo desde fuera indicará puertos altos abiertos.

• CGI Shell

Un rootkit puede contener un script CGI que se aloje en el Servidor Web. Suele ser implementado como una medida “desesperada” ya que en caso de que el administrador detecte el rootkit, seguiremos teniendo este backdoor. El script ejecutará comandos de alto nivel (hay que tener en cuenta que normalmente con permisos del user “nobody” o “httpd”) y mostrará la salida en el navegador.

La ventaja es que este tipo de shells no abren ningún puerto, simplemente usan técnicas de “piggibacking” en conexiones existentes.

• UDP Listener

Los servicios que se sirven de UDP suelen ser más difíciles de escanear que los que usan TCP, por lo que son menos propensos a dar “el cante”. Obviamente deberá de implementarse algún pseudo-protocolo de comunicación, ya que ningún protocolo estandar de acceso remoto corre sobre UDP.

• Reverse Shell/Telnet

Un backdoor que abre una conexión desde la víctima hacia el atacante suele ser mejor que una conexión regular, ya que la víctima no deberá de abrir ningún puerto ( con lo que nos saltamos casi siempre la protección del firewall). Las conexiones pueden ser opcionalmente encriptadas (cryptcat, wrappers SSL, etc.) saltándonos también el IDS. Sin embargo algunos administradores considerarán sospechoso que sus sistemas abran conexiones no estandar a sistemas remotos, bloqueándolos con un simple firewall.

• ICMP “telnet”

Se puede tunelizar cualquier cosa sobre otra (o eso dicen!), un ejemplo es este. Los mensajes de control ICMP como los Echo Request o los Echo Reply pueden ser construidos para llevar payloads en forma de instrucciones. Muchos tipos de mensajes ICMP son permitidos en el firewall debido a razones de rendimiento. Este tipo de backdoors no serán reflejados por ejemplo con un netstat ni descubiertos con un escaneo de puertos. Sin embargo algunos IDS's pueden estar al tanto de patrones inusuales en comunicaciones ICMP usados por los backdoors.

• Reverse tunneled shell

Este tipo de shell nos ayuda cuando tenemos bloqueadas las conexiones salientes. En la mayoría de los entornos hay cierto tipo de conexiones que se permiten y se tratan como normales (por ejemplo la navegación web, puerto 80). Una shell HTTP remota imitará una conexión normal de un navegador hacia el exterior, cumpliendo plenamente con el protocolo HTTP, llegando incluso a ser funcional a través de proxis HTTP (como Squid). El backdoor puede ser activado por un paquete “mágico”, por un temporizador, etc.

• Backdoor activado por paquetes “mágicos”

Esto es una mezcla entre las reverse shell y los backdoors de conexión directa. El backdoor abre un puerto, ejecuta un comando, o inicia una sesión desde la víctima en la que sólo permite la entrada de un tipo específico de paquete, como por ejemplo un segmento TCP con un número de secuencia determinado o ciertos flags activados.

• “No-listener” backdoors (basados en sniffar)

Este tipo de comunicación ofrece un alto grado de ocultación. En este caso, el backdoor no abre ningún puerto, si no que empieza a sniffar tráfico de red. En el momento en el que recibe un paquete “mágico” (no tiene porque proceder de la máquina infectada, sino de alguien a quien tenga acceso, i.e. en la misma LAN) ejecuta una acción y manda una respuesta. Esta respuesta es enviada usando una IP spoofeada de forma que la conexión no pueda ser rastreada (es posible un rastreo limitado basado en analizar tráfico de la capa 2 para encontrar la MAC origen). Este es un método difícil de implementar, pero muy bueno.

• Covert channel backdoor:

Si somos capaces de diseñar nuestro propio sistema de señalización e imbuirlo en algún protocolo de red legítimo, será indetectable casi con toda seguridad por cualquier software de seguridad existente. Hay muchas formas de llevarlo a cabo y muchas factores a tener en cuenta, pero vamos a poner un ejemplo sencillo. Imaginemos: que el número de secuencia inicial de una conexión TCP no es aleatorio si no que sigue un patrón, que el Servidor Web modifica ligeramente el formato de una página web para mandar un byte o 2, … las posibilidades son infinitas.

En cuanto a los backdoors locales, trabajan de diversas formas, por ejemplo troyanizado herramientas administrativas que requieren privilegios de root. Muchas herramientras estandar de Unix SetUidadas son reemplazadas por los atacantes con el fin de obtener privilegios de root “bajo demanda”. Ping, xterm y la mayoría de los demonios de red pueden ser usados para ese propósito. Algunos kernel-rootkits simplemente dan privilegios de root a algún usuario especificado que no aparece con UID 0 en el /etc/passwd.

Mientras que los rootkits normalmente requieren privilegios de root para su instalación, ofrecen muchas formas y muy diversas de mantener estos privilegios, de forma que si por ejemplo el “principal” backdoor que era un SSH troyanizado es descubierto, tenemos otras 5 formas más de seguir entrando al sistema!.

La escalada local de privilegios se provee en forma de binarios SetUidados modificados, /bin/login troyanizados, copias de /bin/bash/ SetUidados en lugares raros, etc.

• Destruir/ocultar evidencias

Otro elemento crucial de cualquier rootkit es la eliminación de evidencias. Esto consiste en borrar cualquier evidencia de un ataque ya realizado o de un pre-ataque, y previniendo generar nuevas evidencias.

El borrar las evidencias existentes implica hacerlo en varios logs del sistema, registros de auditoría (como sucede en los BSD al procesar las cuentas), logs de aplicación, históricos de la shell, etc. Hay decenas de herramientas dedicadas a esto. Los métodos más comunes consisten en el borrado y la edición de dichos ficheros, aunque no suelen ser muy fiables y uno acaba haciéndolo a mano.

Matando y/o modificando el demonio del syslog suele significar saltarnos los procesos de auditoría. La mayoría de los scripts de instalación de rootkits llevan a cabo de manera automática esta tarea y algunos incluso notifican al usuario del descubrimiento de algunas trazas de logueo remoto (entradas del tipo @loghost en /etc/syslog.conf). Otras operaciones incluyen el prevenir la creación de nuevos registros que guarden las sesiones del atacante.

Ocultar la evidencia de la intrusión es uno de los puntos fuertes de los LKM rootkits (luego se verá en que consisten). En contra de la mayoría de los rootkits que se dedican a reemplazar los binarios del sistema, los LKM rootkits se introducen en el kernel del sistema y reemplazan o modifican las llamadas al sistema usadas para interactuar entre el contexto de usuario y el del núcleo. En este caso, el núcleo mismo del Sistema se ve comprometido, con lo que consecuentemente los componentes del sistema que usen las llamadas corruptas se verán afectadas a beneficio del atacante.

En la mayoría de los casos un rootkit tratará de esconder:

- Sus propios ficheros

- Otros ficheros generados a posteriori por el atacante

- Procesos del atacante (sniffers, backdoors, etc.)

- Conexiones de red “comprometidas”

• Recopilación de información

Si unimos a la ya de por si previsible dificultad de encontrar un rootkit, que uno de los propósitos del atacante puede ser simplemente “escuchar” de manera transparente todo lo que ocurre a su alcance, sin apenas interactuar con el exterior, tenemos la receta perfecta.

En ocasiones puede llegar a ser muy jugoso cierto tipo de información, así que un rootkit debe de proveer algún mecanismo (normalmente sniffers) para capturar toda la información que se genere y se mueva a nuestro alrededor, para después analizarla off-line.