Tienda Wifi

Tienda Wifi
CiudadWireless es la tienda Wifi recomendada por elhacker.NET

Buscador

Entradas Mensuales

Suscripción

¿Quieres recibir las últimas novedades del blog en tu correo?

¡Suscríbete al feed!

Foro de elhacker.net - Noticias

elhacker.NET en Facebook

Entradas populares

PostHeaderIcon Rootkits (III)





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.

  • –tksb: Otro shell script, identificado como “sauber – by socked”, usado para borrar cualquier entrada de los logs que contenga la cadena pasada como parámetro.
  • –bin/ssh-only.tgz : Este archivo contiene una versión modificada del cliente ssh. Estacopia está “tuneada” para loguear cualquier combinación de usuario/contraseña que seintroduzca por los usuarios que ejecuten el programa. Si analizamos el binario podemosconcluir que esta información se guardará en el fichero /lib/ldd.so/tkps.
  • –bin/ssh.tgz : Este archivo contiene una copia de sshd, así como los ficheros deconfiguración y las claves pertinentes. Esta copia está comprimida con la herramientaUPX.
  • –conf.tgz : Una serie de ficheros de configuración usados por el rootkit. Los archivosfile.h, hosts.h, lidps1.so, log.h, y proc.h, están en texto plano que contienen una lista deficheros, procesos, conexiones de red, etc... que deben ser ocultados por los binariosmodificados, de forma que el usuario no pueda verlos. Por defecto, estos ficheros pareceque intentan ocultar cualquier rastro de actividad relacionada con IRC, así comocualquier tipo de actividad de red.
  • –lib.tgz: Este fichero contiene una copia modificada de las bibliotecas libproc.so.2.0.6.Esta biblioteca usa los archivos de configuración /usr/include/proc.h y/usr/include/hosts.h, y usa un esquema simple de codificación basada en XOR para codificar ambos archivos y que no sean mostrados por la herramienta strings. 

Siguiendo los pasos del Setup:


Finalmente, vamos a ver como el rootkit ensambla todas estas herramientas en el sistema infectado.Cuando es ejecutado, el script Setup lleva a cabo las siguientes tareas:

  • –Descomprime y extrae todos los archivos .tgz: bin.tgz, conf.tgz, lib.tgz, ssh.tgz, and ssh-only.tgz. Después de lo cual los .tgz originales son borrados.
  • –Se asegura que el script corre bajo permisos de superusuario.
  • –Mata el proceso syslogs para prevenir el logueo de las acciones siguientes.
  • –Intenta comprobar si ya existe una versión previa del rootkit, en tal caso borrará todoslos archivos pertinentes y matará los procesos asociados.
  • –Busca en los logs conexiones remotas activas, y si existen, mostrará los hostnamesasociados.
  • –Guarda encriptados los parámetros que se indicaron anteriormente (o los valores por defecto si no se le suministran: dpass=password dport=12345) en los archivos/etc/ld.so.hash y /lib/libext-2.so.7.
  • –Configura una copia del sshd para que escuche en el puerto indicado, esta es copiada a/usr/sbin/xntps y se añade al /etc/rc.d/rc.sysinit para que corra en el arranque del sistema.
  • –Se calcula el hash MD5 para todos los binarios del sistema reemplazados, y guarda suvalor encriptado en /dev/srd0. Después de esto los ficheros son reemplazados por suscopias modificadas.
  • –Hay una porción que aunque en principio está comentada, se puede usar para para reemplazar el cliente ssh con la copia modificada que ya fue comentada anteriormente.
  • –Copia algunas scripts (tks, tkp, y tksb) en el directorio /lib/ldd.so/
  • –Si el archivo /lib/libncurses.so.5 no existe, lo creará enlazándolo (enlace débil) a/lib/libncurses.so.4.
  • –Imprime información sobre todo el proceso y el resultado, y manda un mail con información del sistema a una dirección de correo hard-codeada.
  • –Muestra las primeras entradas de las reglas de Iptables usadas por el sistema.
  • –Antes de finalizar, reinicia los demonios syslogd, inetd y xinetd.


Para Finalizar:

A lo largo de este artículo hemos podido ver como funcionan los rootkits de nivel de usuario, algo que ya se comentó en el artículo anterior. Primero mediante un análisis de caja negra y después adentrándonos en los elementos que componen internamente el rootkit para ver finalmente como se combina todo esto y se implementa en el sistema final.

Estos rootkits son los más simples y fáciles de detectar como ya vimos con el uso de Tripwire, no así, no dejan de ser peligrosos en caso de no ser detectados y son bastante fáciles de usar. Os dejo con una imagen en la que se muestra un sistema final infectado, donde se observan 2 puertos a la escucha, entre ellos el backdoor en el puerto 5555, por el que accederemos al sistema comprometido, y una vez dentro veremos que si listamos los procesos activos y el puerto asociado esta puerta trasera no aparece: