Bueno, pues después de daros la plasta con la parte “teórica”, vamos a ver algo más práctico, para empezar analizaremos el modus-operandi de un rootkit que trabaja en espacio de usuario. Ya se
explicó someramente como trabajan estos, y para ejemplificarlo que mejor que ponernos manos a laobra a despiezar un rootkit de este tipo, en este caso “shv6”.

Para ello nos vamos a servir de una VM con un Ubuntu Server instalado, con el únic oañadido de que contará con tripwire, programa que sirve para comprobar la integridad de los archivos instalados en nuestro sistema y que nos ayudará a ver mejor los cambios que se llevan acabo en el sistema por este tipo de rootkits.

Análisis de la integridad del sistema con ayuda de Tripwire:

Antes de analizar los diferentes archivos y scripts que componen el rootkit, vamos a hacer un análisis de caja negra para ver que podemos sacar en claro sobre el funcionamiento de este.

Lo primero que haremos, después de instalar tripwire y configurarlo correctamente para nuestro propósito, será recolectar la información actual de los archivos que deseamos monitorizar,dicha información se almacena en una base de datos especial definida en los archivos de configuración del programa.

Una vez hecho esto, procederemos a ejecutar el script de instalación del rootkit (setup). A este script le podemos introducir opcionalmente 2 parámetros:

• contraseña para entrar por el backdoor que se creará
• puerto donde se alojará este backdoor Como se puede ver en la siguiente imagen ambos parámetros fueron usados (pass, 5555).

Una vez instalado el rootkit (con algunos warnings y errores que pueden ser fácilmenteacotados y eliminados, ya que en la mayoría de las ocasiones son debidos al intento de manipulación de archivos que no existen o que varían en su nombre/ruta de una distribución a otra),vamos a ver que nos dice Tripwire sobre los cambios hechos en el sistema por nuestro amiguito...

Con la orden “tripwire -m c” comprobamos la integridad del sistema:

Y este es el resumen del resultado:






Como podemos observar en la imagen anterior, el sistema ha sufrido un número importante de cambios: binarios, ficheros de configuración, bibliotecas, etc..

.En la siguiente imagen podemos ver como el reporte de Tripwire va indicando uno por uno los ficheros que han sido modificados (en la imagen sólo se muestra unos pocos, pero salen todos):

Análizando los scripts y binarios del rootkit:

Una vez que sabemos que archivos son creados/modificados por el rootkit, vamos a analizar los componentes de shv6 (los más importantes), para ver que hace exactamente en el sistema.

• –shv6.tar.gz: El rootkit comprimido.
• –bin.tgz : Colección de ejecutables usados por el rootkit, incluyendo copias modificadasde los siguientes ejecutables del sistema: encrypt, ifconfig, dir, encrypt, find login, ls,lsof, md5sum, netstat, ps, pstree, slocate, syslogd, y top. Estas modificacioens sonhechas para evitar la detección del rootkit, así como las actividades del atacante en lamáquina comprometida.Adicionalmente, se incluyen otras utilidades que serán detalladas a continuación: pg, sz,tkp, tks, y tksb.
• –pg: Un binario ejecutable en formato ELF, el cual provee una interfaz simple en linea decomandos para la función de biblioteca crypt, usando “db” como valor estático para elsalt. Se usa para encriptar contraseñas usadas por otros componentes del rootkit.
• –sz: Un shell script (/bin/sh), en cuyos comentarios se puede identificar como “Fileresizer v2.3”, y cuyo propósito es el de añadir ceros a un fichero hasta que este alcanceel tamaño de otro fichero suministrado como parámetro. Esto se puede usar para cambiar el tamaño de un binario reemplazado de forma que alcance el tamaño del original.
• –tkp: Otro script, esta vez en Perl, en los comentarios nombrado como “hdlp2 version2.05”, se usa para parsear la salida de LinSniffer de forma que sólo muestre información“interesante” en la captura.