Recordemos que se creo un par de cuentas que luego fueron eliminadas. ¿Algo raro verdad? Podría tratarse de una escalada de privilegios mediante ficheros suid, pero para ello necesitaría un usuario no privilegiado en el sistema, pero también lo ha borrado. Esto nos indica que seguramente ha instalado algún servicio que le permite autenticarse sin requerir estar en el sistema.
Para averiguar que ha podido ocurrir vamos a revisar de nuevo la líena de tiempo creada con anterioridad. Si analizamos detenidamente la fecha de implantación del RootKit veremos las siguientes entradas:
Wed Nov 08 2000 14:53:12 343586 mac. r/rrwxr-xr-x 0 0 110004 /local/bin/ssh-agent1
10 mac. l/lrwxrwxrwx 0 0 110005 /local/bin/ssh-agent -> ssh-agent1
337617 mac. r/rrwxr-xr-x 0 0 110006 /local/bin/ssh-add1
8 mac. l/lrwxrwxrwx 0 0 110007 /local/bin/ssh-add -> ssh-add1
90424 mac. r/rrwxr-xr-x 0 0 110008 /local/bin/scp1
4 mac. l/lrwxrwxrwx 0 0 110009 /local/bin/scp -> scp1
21228 mac. r/rrwxr-xr-x 0 0 110010 /local/bin/make-ssh-known-hosts1
21 mac. l/lrwxrwxrwx 0 0 110011 /local/bin/make-ssh-known-hosts -> make-ssh-known-hosts1
643674 m.c. r/rrwxr-xr-x 0 0 33115 /local/sbin/sshd1
5 m.c. l/lrwxrwxrwx 0 0 33116 /local/sbin/sshd -> sshd1
Ya con esto nos sobra para despejar dudas. Es lógico que si el atacante requiere un servicio que no está disponible en el sistema lo instale, pero que existiendo el servicio instale uno nuevo añadiendo al nombre del servicio un 1 y que los binarios del servicio original sean ahora simples enlaces dinámicos al servicio añadido por el atacante, nos indica una cosa: el servidor sobreescrito está modificado para permitir la autenticación directa del atacante sin pasar por los métodos tradicionales.
Accedemos al directorio "/reto/mnt/usr/local/bin" y analizamos los ficheros modificados por el atacante. Lo que primero nos llama la atención es el SUID del fichero ssh1. Pero más que el cliente nos interesa ver el servicio que se arranca el ssh ("sshd1") que se encuentra en "/reto/mnt/usr/local/sbin". Una forma sencilla de poder analizar el binario sshd1 es usar de nuevo un srch_strings, aunque lógicamente lo mejor sería usar el gdb, pero esto requeriría varias entradas en el blog. Veamos a continuación que strings nos muestra esto:
#srch_strings -a -td sshd1Me llaman la atención dos cosas, por un lado la primera entrada ya que esa forma de cadena me recuerda a un hash MD5, la segunda el "/usr/tmp/nap" y el trozo de código a continuación. Veamos primero que hay en "/reto/mnt/usr/tmp/nap":
...
146880 d33e8f1a6397c6d2efd9a2aae748eb02
...
148316 /usr/tmp/nap
148352 +-[ User Login ]-------------------- --- --- - -
148416 | username: %s password: %s hostname: %s
148480 +----------------------------------- ----- --- -- -- -
...
543582 md5.h
...
550891 md5passwd:(0,30)=ar(0,1);0;32;(0,2)
550927 md:(126,2)
550938 md5buffer:(0,31)=ar(0,1);0;31;(0,11)
...
# cat /reto/mnt/usr/tmp/napLo que nos imaginavamos ¿verdad?, el SSH aparte de supuestamente permitir al atacante autenticarse sin necesidad de tener usuario en el sistema, está registrando los usuarios y contraseñas que acceden al ssh. Apuntamos el usuario y la contraseña. El siguiente paso consistirá en revisar la contraseña del usuario root del entorno para comprobar si se tratan de la misma. Analizando la contraseña de Root del entorno vemos que se trata de un MD5 ($1$) con semilla "eJ2yI2DF" y hash "0cXQKjrEYcYHM/qJu2X6Z". Vamos a usar el john the ripper para comprobar si ese usuario de root es el mismo que el del sistema:
+-[ User Login ]-------------------- --- --- - -
| username: root password: tw1Lightz0ne hostname: c871553-b.jffsn1.mo.home.com
+----------------------------------- ----- --- -- -- -
# apt-get install johnCuriosamente la contraseña guardada no pertenece al usuario root del sistema... Bueno dejemos esto apartado y recordemos el MD5 visto con anterioridad en el binario ssh1. Lo que vamos a ver es que contraseña ha podido generar ese MD5. Se me ocurre una cosa barbara y es que la contraseña guardada en el fichero sea la contraseña del atacante y el registro de contraseña no tenga una comprobación para evitar que la propia contraseña del atacante sea registrada... veamos a ver:
# cd /reto/aux/
# echo "tw1Lightz0ne" > passwd
# unshadow /reto/mnt/etc/passwd /reto/mnt/etc/shadow >> patata
# john --wordlist=passwd patata
Loaded 2 password hashes with 2 different salts (FreeBSD MD5 [32/32])
guesses: 0 time: 0:00:00:00 100% c/s: 200 trying: tw1Lightz0ne
# echo "tw1Lightz0ne" | md5sum -No hay suerte. Algo se escapa... mmm claro, el salto de linea que añade el echo:
367d375770a5775c4a63d1862e2fceaf -
# echo -n "tw1Lightz0ne" | md5sumBueno, pues al final el hash que hay en el servicio corresponde con el MD5 que está guardado en el fichero, y por tanto, el propio atacante ha dejado el registro de su acceso en el log de registro del sshd modificado. Podemos apuntar el hostname "c871553-b.jffsn1.mo.home.com" como posible origen del atacante.
d33e8f1a6397c6d2efd9a2aae748eb02
Para finalizar con el SSH vamos a comprobar si el servicio se arranca en caso de que el sistema se reinicie, para ello buscaremos en los scripts de arranque:
# grep ":initdefault" /reto/mnt/etc/inittab
id:3:initdefault:
# ls -l /reto/mnt/etc/rc.d/rc3.d/
...
lrwxrwxrwx 1 root root 11 Nov 5 2000 S99local -> ../rc.local
No vemos ningún enlace que identifique al SSH, pero si analizamos todos los enlaces del directorio anterior encontramos que al final el enlace dinámico "S99local", el cual apunta al fichero "rc.local", es el encargado de arrancarlo:
# grep -i ssh /reto/mnt/etc/rc.d/rc.local
/usr/local/sbin/sshd1
Una vez finalizado la manera que tiene el atacante de acceder al servidor, vamos a seguir analizando la línea de tiempo:
Claramente se ha instalado un servidor FTP y un servidor NFS cuyo propósito es la transferencia sencilla de ficheros por parte del atacante. ¿Aunque teniendo el scp para que usar ftp? No pierdo mucho el tiempo en analizar estos servicios. Seguimos con la línea de tiempo:
Esto es interesante, se ha instalado un servicio de DNS y es crítico puesto que un DNS puede usarse para una multitud de funciones.
314 ..c. r/rrw-r--r-- 0 0 16195 /etc/pam.d/ftp
314 ..c. r/rrw-r--r-- 0 0 16195 /etc/pam.d/ftp-RPMDELETE (deleted-realloc)
8928 ..c. r/rrwxr-xr-x 1 1 17487 /bin/ftpcount
8928 ..c. r/rrwxr-xr-x 1 1 17488 /bin/ftpwho
8928 ..c. r/rrwxr-xr-x 1 1 17488 /bin/ftpwho-RPMDELETE (deleted-realloc)
484 ..c. r/rrw------- 0 0 26548 /etc/ftpaccess
456 ..c. r/rrw------- 0 0 26549 /etc/ftpconversions
39 ..c. r/rrw------- 0 0 26550 /etc/ftpgroups 1
04 ..c. r/rrw------- 0 0 26551 /etc/ftphosts
79 ..c. r/rrw------- 0 0 26552 /etc/ftpusers
180703 ..c. r/rrw-r--r-- 1010 100 109865 /man/.Ci/nfs-utils-0.1.9.1-1.i386.rpm (deleted)
Claramente se ha instalado un servidor FTP y un servidor NFS cuyo propósito es la transferencia sencilla de ficheros por parte del atacante. ¿Aunque teniendo el scp para que usar ftp? No pierdo mucho el tiempo en analizar estos servicios. Seguimos con la línea de tiempo:
Wed Nov 08 2000 14:54:25 547 .a.. r/rrw-r--r-- 0 0 26245 /etc/named.conf
33392 .a.. r/rrwxr-xr-x 0 0 30251 /bin/cp
525412 .a.. r/rrwxr-xr-x 0 0 33119 /local/sbin/named
5 mac. r/rrw-r--r-- 0 0 34293 /run/named.pid
2769 .a.. r/rrw-r--r-- 0 0 62498 /named/named.ca
422 .a.. r/rrw-r--r-- 0 0 62499 /named/named.local
525412 mac. r/rrwxr-xr-x 0 0 92809 /sbin/named
Esto es interesante, se ha instalado un servicio de DNS y es crítico puesto que un DNS puede usarse para una multitud de funciones.
Si seguimos analizando la línea de tiempo veremos como el atacante una vez instalado los servicios indicados con anterioridad elimino las fuentes de instalación:
Podemos recuperar las herramientas que uso el atacante aprovechando que el sistema de ficheros es Ext2. Recordar que cuando eliminados ficheros en Ext2, a diferencia de Ext3 y Ext4, los "punteros" (enlaces directos e indirectos) del inodo hacia los bloques no se eliminan. Y por tanto somos capaces de sabiendo el inodo del fichero eliminado, recuperar su contenido, siempre y claro está que el contenido no haya sido sobrescrito por otro fichero. Por ejemplo para el demonio de ssh haríamos:
Wed Nov 08 2000 14:56:08 18698240 ..c. r/rrw-r--r-- 1010 100 109791 /man/.Ci/ssh-1.2.27.tar (deleted)
4096 m.c. d/drwxr-xr-x 1010 100 109798 /man/.Ci
1153 ..c. r/rrwxr-xr-x 1010 100 109801 /man/.Ci/install-sshd1 (deleted)
1076 ..c. r/rrwxr-xr-x 1010 100 109802 /man/.Ci/install-sshd (deleted)
80 ..c. r/rrwxr-xr-x 1010 100 109803 /man/.Ci/install-named (deleted)
106 ..c. r/rrwxr-xr-x 1010 100 109864 /man/.Ci/install-statd (deleted)
180703 ..c. r/rrw-r--r-- 1010 100 109865 /man/.Ci/nfs-utils-0.1.9.1-1.i386.rpm (deleted)
195637 ..c. r/rrw-r--r-- 1010 100 109866 /man/.Ci/wuftpd.rpm (deleted)
71 ..c. r/rrwxr-xr-x 1010 100 109867 /man/.Ci/install-wu (deleted)
# istat honeypot.hda5.dd 109791Esos datos que se muestran la final del "Direct Blocks" es la diferencia con Ext3/4. En Ext3 o 4 no se mostrarían los números de bloques. Recuperemos el fichero y veamos si contiene las modificaciones en el SSHD vistas con anterioridad:
inode: 109791
Not Allocated
Group: 7
Generation Id: 640190586
uid / gid: 1010 / 100
mode: rrw-r--r--
size: 18698240
num of links: 0
Inode Times:
Accessed: Wed Nov 8 15:52:59 2000
File Modified: Wed Aug 9 21:52:37 2000
Inode Modified: Wed Nov 8 15:56:08 2000
Deleted: Wed Nov 8 15:56:08 2000
Direct Blocks:
238256 238257 238258 238259 ...
# icat honeypot.hda5.dd 109791 >> /reto/evidencia/ssh-1.2.27.tarVolvamos con la línea de tiempo. Las siguientes entradas que me llaman la atención son las que se encargan de modificar binarios del sistema, lógicamente se trata de los binarios modificados para implantar el Rootkit:
# ls -l /reto/evidencia/ssh-1.2.27.tar
-rw-r--r-- 1 root root 18698240 Feb 18 00:16 /reto/evidencia/ssh-1.2.27.tar
# file /reto/evidencia/ssh-1.2.27.tar
/reto/evidencia/ssh-1.2.27.tar: POSIX tar archive (GNU)
# tar xvf /reto/evidencia/ssh-1.2.27.tar
# grep -R "\[ User Login \]" *
ssh-1.2.27/sshd.c: fprintf(fp,"+-[ User Login ]-------------------- --- --- - -\n");
# grep -R "d33e8f1a6397c6d2efd9a2aae748eb02" *
config.h:#define USE_GLOBAL_PASS "d33e8f1a6397c6d2efd9a2aae748eb02"
Wed Nov 08 2000 14:56:57 4096 .a.. d/drwxr-xr-x 1010 100 109798 /man/.CiYa para finalizar vemos algo raro y que no esperaba, el "bash_history" y el home de Drosen se han creado durante los 15 minutos donde se implanto el Rootkit:
Wed Nov 08 2000 14:56:59 35168 ..c. r/rrwx------ 0 0 15639 /bin/chage
36756 ..c. r/rrwx------ 0 0 15641 /bin/gpasswd
33288 ..c. r/rrwx------ 0 0 15827 /bin/at
531516 ..c. r/rrwx------ 0 0 16523 /bin/sperl5.00503
531516 ..c. r/rrwx------ 0 0 16523 /bin/suidperl
5640 ..c. r/rrwx------ 0 0 17453 /bin/newgrp
5760 .a.. r/rrwxr-xr-x 0 0 30288 /bin/sleep
17968 ..c. r/rrwx------ 0 0 30293 /bin/ping
45388 ..c. r/rrwx------ 0 5 48410 /sbin/dump
67788 ..c. r/rrwx------ 0 5 48412 /sbin/restore
34751 ..c. r/rrwx------ 0 0 76969 /libexec/pt_chown
5896 ..c. r/rrwx------ 0 0 93297 /sbin/usernetctl
16488 ..c. r/rrwx------ 0 1 93846 /sbin/traceroute
Wed Nov 08 2000 14:59:07 4096 m.c. d/drwx------ 500 500 15395 /drosen
52 mac. r/rrw------- 500 500 15401 /drosen/.bash_history
Esto requiere contradecir lo expuesto con anterioridad, es muy posible que el usuario Drosen no sea tan legítimo como habíamos pensado primeramente.Vamos a proceder por ello a un análisis lógico del contenido del sistema de fichero para ver si podemos obtener más información de la intrusión:
# cat /reto/mnt/home/drosen/.bash_history
gunzip *
tar -xvf *
rm tpack*
cd " "
./install
exit
Nos hemos dejado algo en el análisis forense. El acceso a un directorio cuyo contenido es el espacio en blanco es una técnica bastante conocido de intentar ocultar información dentro de un directorio (junto con la ". " o ".. "). Vemos que descomprime un fichero, elimina el fichero, accede al directorio en blanco, instala algo y por último cierra la sesión... No es un comportamiento muy normal:
Como análisis superficial del incidente podemos tener una estimación de cuando se hizo, como se hizo, que se implanto en el servidor, como se conectaba el atacante al equipo y como intento el atacante ocultar sus huellas.
Para finalizar la entrada quiero indicar que aunque normalmente se emplea en cualquier análisis forense, debido a la antigüedad de este reto, me ha sido imposible usar uno de mis packs de herramientas favoritas: foremost, sorter, md5depp y hfind. El objetivo de estos es generar una lista blanca a partir de un entorno no comprometido con una configuración similar, lo que nos permitirá eliminar supuestos, y adicionálmente combinarlo con una lista negra de malware, permitiendo reducir drásticamente los ficheros a tratar.
Espero que os haya gustado. Nos vemos en la próxima entrada.
# cat /reto/mnt/etc/passwd | grep drosen | awk -F':' {'print $3'}Veamos a ver si encontramos algo que coincida con tpack:
500
# find /reto/mnt/home/drosen/ -type f -uid 500 2> /dev/null
(no sale nada interesante)
# find /reto/mnt/ -type f -iname "*tpack*"Llegado a este punto, podría decir que no se que fichero instalo el usuario :(.
(No hay suerte)
Como análisis superficial del incidente podemos tener una estimación de cuando se hizo, como se hizo, que se implanto en el servidor, como se conectaba el atacante al equipo y como intento el atacante ocultar sus huellas.
Para finalizar la entrada quiero indicar que aunque normalmente se emplea en cualquier análisis forense, debido a la antigüedad de este reto, me ha sido imposible usar uno de mis packs de herramientas favoritas: foremost, sorter, md5depp y hfind. El objetivo de estos es generar una lista blanca a partir de un entorno no comprometido con una configuración similar, lo que nos permitirá eliminar supuestos, y adicionálmente combinarlo con una lista negra de malware, permitiendo reducir drásticamente los ficheros a tratar.
Espero que os haya gustado. Nos vemos en la próxima entrada.
No hay comentarios:
Publicar un comentario