Estos días ando aprendiendo a
usar las herramientas que componen el paquete sleuthkit, para tratar
de implementarlas en un desarrollo en el que ando metido en el
trabajo. Sleuthkit es un compendio de utilidades desarrolladas por
Brian Carrier, a partir del trabajo de Wietse Venema y Dan Farmer
(TCT, The coroner's toolkit), añadiendole muchas
características nuevas como el soporte para sistemas ntfs.
Generalmente, la gente que se dedica al
análisis forense profesionalmente tiende a usar aplicaciones
muy especializadas como es el caso de EnCase,
Ilook (el primero vale
un pastón, el segundo solo está disponible para cuerpos
policiales) o el hermano pobre para sistemas *nix: Autopsy. Autposy
es un interfaz web, con soporte para casos, investigadores, máquinas
etc, y que es capaz de presentar homogéneamente toda la
información que es capaz de recuperar las herramientas de
sleuthkit.
Puesto que el programa que estoy
escribiendo no tiene interacción con el usuario, necesitaba
conocer que posibilidades había desde la línea de
comandos para hacer uso de las herramientas, que información
suministraban y de que manera podía procesar automáticamente
esa información. La mejor manera de hacerlo es sin lugar a
dudas instalando el paquete y trabajar sobre alguna imagen. Estuve
mirando por honeynet , pero no
encontré nada que valiera para lo que quería hacer. Aún
así recomiendo ese sitio para la gente interesada en temas de
seguridad, es increible lo que se puede aprender y encima gratis.
Después recordé que rediris había hecho hace un
año o dos un reto de análisis forense, en el que
colgaron las imágenes de un sistema comprometido, para que las
personas interesadas pudieran destriparlo y elaborar sus informes.
Así que me he pasado por allí y he comprobado que
todavía las tenían. Quiero decir que no me dedico a
esto y que voy a meter la pata seguramente en muchas cosas,
seguramente me salte procedimientos y normas elementales en esta
ciencia, pero ya he dicho que mi único propósito es
averiguar como funcionan las herramientas de sleuthkit. La idea es
hacerlo sin montar las imágenes obtenidas y usando solamente
herramientas GNU y las propias de sleuthkit.
Una vez que tenemos el fichero hay que
descomprimirlo:
amphora@hamlet:~/tmp/honeynet/reto$ tar -jxvf 192.168.3.10.tar.bz2
192.168.3.10-hda1.dd
192.168.3.10-hda5.dd
192.168.3.10-hda6.dd
192.168.3.10-hda7.dd
192.168.3.10-hda8.dd
192.168.3.10-hda9.dd
ficheros.txt
En el fichero ficheros.txt, se encuentra la suma md5 de las imágenes
y una descripción de cual era su punto de montaje, así
que borramos el fichero bz2 que ya no nos sirve y le echamos un
vistazo a ficheros.txt
amphora@hamlet:~/tmp/honeynet/reto$ rm 192.168.3.10.tar.bz2
amphora@hamlet:~/tmp/honeynet/reto$ cat ficheros.txt
b258f21b93e0eaa1f605dfd47d3f66f4 192.168.3.10-hda1.dd /boot
0b826f207f81bbc294bd059302a3558a 192.168.3.10-hda5.dd /usr
87669b6e6939619cdbc8ff8dfba574c4 192.168.3.10-hda6.dd /home
29ac32347b0bdda0659c061b46dce9e4 192.168.3.10-hda7.dd /var
4eed1213ed2aaa48f26e3edffd8a888d 192.168.3.10-hda8.dd /
c7da26612f6f7b318fb79064e2909500 192.168.3.10-hda9.dd swap
Comprobamos que está todo correcto
amphora@hamlet:~/tmp/honeynet/reto$ md5sum *.dd
b258f21b93e0eaa1f605dfd47d3f66f4 192.168.3.10-hda1.dd
0b826f207f81bbc294bd059302a3558a 192.168.3.10-hda5.dd
87669b6e6939619cdbc8ff8dfba574c4 192.168.3.10-hda6.dd
29ac32347b0bdda0659c061b46dce9e4 192.168.3.10-hda7.dd
4eed1213ed2aaa48f26e3edffd8a888d 192.168.3.10-hda8.dd
c7da26612f6f7b318fb79064e2909500 192.168.3.10-hda9.dd
Ahora que tenemos las imágenes descomprimidas, es necesario
pararse a pensar.
¿Que sabemos del sistema que
vamos a analizar?
Aparentemente nada, pero solo hay que
tirar del hilo para descubrir que sabemos muchas cosas.
En la página de rediris nos
dicen que es una máquina linux y que ha sido comprometida
(esto último es importante, podiamos volvernos locos buscando
evidencias cuando no hay nada por buscar)
Puesto que la máquina se puso en
internet para que fuera comprometida, se puede deducir que el ataque
vino desde ahí. También es importante tenerlo claro,
porque el análisis se hace de otra manera si ha sido
comprometida fisicamente.
Bien, si es una máquina linux y
el ataque ha venido desde internet, ¿Por donde se colaron?
Ahora sería interesante saber que servicios corría el
ordenador en el momento de ser atacado, sin embargo yo voy a seguir
otra vía. ¿Que hace un delincuente una vez que ha
cometido un delito? Tratar de ocultar las evidencias que lo implican,
o hagan salir a la luz el mismo hecho del delito.
¿Donde pueden estar esas
evidencias? Por todas partes, pero hay dos sitios que se suelen usar
mucho: /tmp y /var/tmp. Todo el mundo tiene permiso de escritura en
esos directorios, al menos habitualmente es así en cualquier
distribución de linux, y es un punto seguro donde el atacante
subira sus herramientas, rootkits etc.
Puesto que /tmp es un sitio con mucho
movimiento y en este caso además no está en una
partición aparte (muy mal hecho) voy a ir primero por /var,
así de paso le hechamos un vistazo a los logs.
Vamos a buscar primero todo lo que haya
sido borrado.
amphora@hamlet:~/tmp/honeynet/reto$ fls -f linux-ext2 -p -r -d 192.168.3.10-hda7.dd
r/r * 32141(realloc): lib/slocate/slocate.db.tmp
r/r * 30136: lock/subsys/atd
r/r * 28121: lock/makewhatis.lock
r/r * 38165: run/xinetd.pid
r/r * 38165: spool/mqueue/xfg7MMQ5J07358
r/r * 38170: spool/mqueue/dfg7MMQ5J07358
r/r * 38171: spool/mqueue/tfg7MMQ5J07358
r/r * 38171: spool/mqueue/qfg7MMQ5J07358
r/r * 26110(realloc): spool/cron/tmp.7216
r/r * 20087: tmp/.,/manu.tgz
r/r * 22125(realloc): tmp/.,/psybnc/psybnc
d/d * 20086(realloc): tmp/tmpwhatisDzGQKA
r/r * 34146(realloc): ftp/etc/ld.so.cache~
r/r * 14100: ftp/nerod/tmp
r/r * 13: tmpzlib-devel-1.1.3-22.i386.rpm
Dos cosas, he puesto linux-ext2 a tientas, podría haber sido
otro tipo de ficheros, y habría que comprobar también
si tiene sistema de journaling. En un fichero journal, se pueden
encontrar cosas interesantes. Y otra, el comando de arriba habría
que ejecutarlo con la opción -l, que nos dá muchisima
más información, como uids,guids, tiempos etc, pero
aquí me estropeaba la maquetación.
Así a simple vista canta mucho
que en el directorio tmp/ haya algo con un punto y una coma “.,”
es una forma muy burda de ocultar algo a los ojos de un administrador
o usuario, pero que funciona, sobre todo cuando el directorio
contiene muchas entradas y al hacer un “ls” se pierde
enseguida por la parte de arriba del terminal. Si alguno habeis
estudiado código de rootkits, habreis visto que es una forma
muy común de esconder cosas.
Bien, hemos dicho entonces que teníamos
dos ficheros muy sospechosos y que además han sido borrados,
vamos a tratar de recuperarlos.
amphora@hamlet:~/tmp/honeynet/reto$ icat -f linux-ext2 192.168.3.10-hda7.dd 20087 >manu.tgz
amphora@hamlet:~/tmp/honeynet/reto$ icat -f linux-ext2 192.168.3.10-hda7.dd 22125 >psybnc
Empecemos primero por el que está sin comprimir:
amphora@hamlet:~/tmp/honeynet/reto$ file psybnc
psybnc: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.0.0, statically linked, stripped
Hiede, apesta. ¿Un binario estático, oculto y borrado?
...blanco y en botella...
Si le extraemos las cadenas podemos ver
cositas como estas:
...
...
psyBNC
2.2.2BETA
.-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-.
,----.,----.,-. ,-.,---.,--. ,-.,----.
| O || ,-' \ \/ / | o || \| || ,--'
| _/ _\ \ \ / | o< | |\ || |__
|_| |____/ |__| |___||_| \_| \___|
Version 2.2.2BETA (c) 1999-2001
the most psychoid
and the cool lam3rz Group IRCnet
`-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=tCl=-'
...
...
Name of the bouncer set to '%s'.
User %s quitted (from %s)
:%s!%s@%s QUIT :good bye
ACTION
%s%s%s
:irc.psychoid.net PONG irc.psychoid.net :%s
Por lo poco que lo he mirado, es una especie de servidor para irc.
Vamos con el segundo:
amphora@hamlet:~/tmp/honeynet/reto$ tar -zxvf manu.tgz
emech/
emech/mech.set
emech/mech.session
emech/emech.users
emech/mech.levels
emech/emech.users.save
emech/httpd
emech/mech.pid
emech/LinkEvents
Esto es un bot para el irc, no voy a explicar cada uno de los
ficheros, porque el artículo se haría eterno y no es el
propósito, pero cabe destacar que httpd es un binario que
permite controlar el bot vía web.
Continuemos. Antes cuando ejecute el
comando fls, lo hice con el parámetro -d, que indica que solo
muestre los ficheros borrados, si lo hacemos sin esa opción
nos mostrará todo lo que hay en la partición. Y entre
otras cosas interesantes he encontrado algo que llama la atención,
no lo voy a investigar, pero estoy seguro de que me responde a otra
de las preguntas ¿Por donde se han colado?
amphora@hamlet:~/tmp/honeynet/reto$ fls -f linux-ext2 -p -r 192.168.3.10-hda7.dd
...
...
r/r 30143: ftp/nerod.tar.gz
d/d 14065: ftp/nerod
d/d 18075: ftp/nerod/sshd
r/r 18076: ftp/nerod/sshd/ifconfig
r/r 18077: ftp/nerod/sshd/init.sshd
r/r 18078: ftp/nerod/sshd/install.log
r/r 18079: ftp/nerod/sshd/sshd
...
r/r 14084: ftp/nerod/linsniffer
r/r 14085: ftp/nerod/login
r/r 14086: ftp/nerod/ls
r/r 14087: ftp/nerod/md5bd
r/r 14088: ftp/nerod/me
r/r 14089: ftp/nerod/netstat
r/r 14090: ftp/nerod/ps
r/r 14091: ftp/nerod/pstree
Parece evidente que el intruso, se metio por el ftp y ha subido los
tipicos binarios que componen un rootkit. El porque de que se
encuentren ahí y no hayan sido borrados u ocultados, lo
desconozco, quizá no le dió tiempo o bien era un poco
zoquete.
Lo siguiente que he intentado ha sido
recuperar el fichero log/xferlog característico de los
servidores ftp, pero me ha sido imposible. Entonces he optado por ver
los últimos logins efectuados en la máquina. Para ello,
he recuperado mediante icat a wmtp y ofrecía algo así:
amphora@hamlet:~/tmp/honeynet/reto$ sudo last -f ./wmtp
root tty1 Fri Aug 23 12:33 gone - no logout
ftp ftpd7052 200.47.186.114 Fri Aug 23 00:22 gone - no logout
ftp ftpd7049 200.47.186.114 Fri Aug 23 00:21 gone - no logout
ftp ftpd6590 218.146.115.18 Thu Aug 22 08:26 gone - no logout
root tty1 Wed Aug 21 19:03 - 19:05 (00:02)
reboot system boot 2.4.2-2 Wed Aug 21 19:01 (946+05:32)
Un vistazo a log/messages nos lo vuelve a confirmar:
...
Aug 22 06:26:29 localhost ftpd[6590]: ANONYMOUS FTP LOGIN FROM 218.146.115.18 [218.146.115.18], mozilla@
Aug 22 08:30:43 localhost ftpd[6595]: lost connection to a213-84-155-131.adsl.xs4all.nl [213.84.155.131]
Aug 22 08:30:43 localhost ftpd[6595]: FTP session closed
Aug 22 08:31:37 localhost ftpd[6596]: lost connection to a213-84-155-131.adsl.xs4all.nl [213.84.155.131]
...
Aug 22 22:21:05 localhost ftpd[7049]: ANONYMOUS FTP LOGIN FROM 200.47.186.114 [200.47.186.114], mozilla@
Aug 22 22:22:48 localhost ftpd[7052]: ANONYMOUS FTP LOGIN FROM 200.47.186.114 [200.47.186.114], mozilla@
Aug 23 00:25:03 localhost kernel: Kernel logging (proc) stopped.
Aug 23 00:25:03 localhost kernel: Kernel log daemon terminating.
Inmediatamente después de esos accesos la máquina
comienza a reiniciarse, desconozco si en ese momento tiraron del
cable los de rediris, o la reinicio el intruso por algún
motivo.
Para el que quiera seguir jugando, que
le eche un vistazo a la partición hda6, y verá como se
creo un usuario con nombre nerod, que seguro tiene uid 0 en
/etc/password. Sería interesante ver cual fue el fallo del
servidor ftp( si es verdad que se colaron por allí) etc, pero
yo ya he cumplido y más o menos tengo claro que puedo esperar
de sleuthkit y como usarlo que ese era el propósito, además
de mantenerme entretenido toda una tarde de un jueves santo.
