Usando TCT
Ahora, paso por paso, intentaremos instalar la aplicación The Coroners Toolkit, que nos servirá para recoger la información sobre el sistema de ficheros y analizarla. La herramienta no es un ejecutable que realiza todas las tareas, sino es una colección de utilidades diseñadas para efectuar una tarea determinada, siendo importante entender el funcionamiento de cada una de ellas para poder entender la función del toolkit en su totalidad.
- El primer pasoes de desempaquetar el archivo tct-1.09.tar.gz y copiarlo al directorio /usr/local/tct-1.09, luego debemos leer detenidamente el fichero de instrucciones de instalación INSTALL.
La instalación de la aplicación debe ser realizada en una partición donde haya mucho espacio ya que algunas aplicaciones suelen generar una cantidad grande de información de salida por ejemplo unrm y lazarus.
Ahora reconfiguremos los scripts utilizando perl reconfig, ya que TCT utiliza rutas completas.
Limpiamos bien la distribución con un make clean; make all.
Leemos documentación del directorio docs/ para conocer los detalles de funcionamiento del Toolkit.
1. ls -l docs
total 34 | |||
---|---|---|---|
-rw-r--r-- | 1 root | root | 8572 Mar 28 12:41 README |
-rw-r--r-- | 1 root | root | 7162 Mar 28 12:39 grave-robber.README |
-rw-r--r-- | 1 root | root | 13944 Jan 16 13:34 lazarus.README |
-rw-r--r-- | 1 root | root | 2830 Mar 27 15:07 mac.README |
- Montamos la partición que debemos analizar en modo solo lectura y nodev, bajo algún punto de montura.
mount -r /dev/hdd2 /mnt
- Suponiendo que siendo root arrancamos la aplicación grave-robber para que empiece a analizar el sistema de ficheros y procesos y guardar los datos de los inodes en el fichero data/activalink.com/base y data/activalink.com/base.S(binarios sUID), el estado del sistema en el directorio data/activalink.com/command_out/ etc...
bin/grave-robber -m /mnt
Grave-robber, inicialmente realizará un análisis de todas las carpetas que están en el $PATH y a continuación empezará a analizar lapartición montada /mnt. El análisis suele tardar bastante tiempo, según el tamaño de la partición que queremos analizar. Aparte de los inodes se guarda el estado general del sistema, es decir el output de las herramientas de monitorización del sistema comops, top, w etc.
Una vez terminado el trabajo del grave-robber, copiamos los ficheros passwd y group del sistema comprometido al directorio tct-1.09/ para que los tengamos a mano ya que en breve estaremos analizándolos. Para que se pueda distinguirlos luego renombramos estos ficheros passwd.victim o utilicemos el nombre del host comprometido.
Ejecutamos luego la utilidad mactime especificando una fecha anterior del compromiso (consideremos que la actividad del intruso ha acabado hoy, pero no vamos a especificar hora). Necesitaremos pasar los resultados de ejecución de mactime a un fichero para que luego se pueda examinar su contenido con tranquilidad:
bin/mactime -p passwd.victim -g group.victim /mnt 06/01/2000 > victim.mactime
En la utilidad mactime hubo un bug en las versiones anteriores que hacía que la aplicación no funcione correctamente si se utilizaba la opción -p. Entonces hacíamos un "work around", incorporando temporalmente el contenido del fichero /etc/passwd de la máquina víctima coincidir con él de nuestro sistema. En la versión actual este bug está solucionado.
- Hacemos una copia del fichero antes de empezar el análisis:
cp victim.mactime victim.mactime.evidence
- Entonces podemos empezar analizando el fichero victim.mactime.evidence. Usando el editor de texto favorito, empecemos a revisarlo y marcar la actividad sospechosa. Sugiero que pongamos los tags [MARK] para que luego con grep podamos localizar nuestros apuntes.
. . . | |||
---|---|---|---|
Feb 13 2000 01:10:50 | 50148 mca -rwxr-xr-x root | root | /x/dev/. |
Feb 13 2000 01:10:52 | 564 m.c -rw-r--r-- root | root | /x/etc/profile |
Feb 13 2000 01:11:00 | 5 mac -rw-r--r-- root | root | /x/lib/sp |
[MARK] | 18110 .a. -rw-r--r-- root | root | /x/lib/tp |
Feb 13 2000 01:12:08 | 0 ..c -rw-r--r-- root | root | /x/dev/ttyag |
25 ..c -rwxr-xr-x root | root | /x/dev/ttyfg | |
23 ..c -rwxr-xr-x root | root | /x/dev/ttypg | |
373176 ..c -rws--x--x root | root | /x/lib/... | |
8268 ..c -rwxr-xr-x root | root | /x/lib/go | |
20164 ..c -rwsr-xr-x root | root | /x/usr/bin/xcat | |
183780 ..c -rwxr-xr-x root | root | /x/usr/sbin/find | |
Feb 13 2000 01:30:00 | 8268 .a. -rwxr-xr-x root | root | /x/lib/go |
Feb 14 2000 10:42:03 1166856 .a. -rw-r--r-- root | root | /x/var/log/boot.log | |
Feb 14 2000 10:45:3518110 m.c -rw-r--r-- root | root | /x/lib/tp | |
Feb 14 2000 10:57:422998 m.c -rw-r--r-- root | root | /x/etc/inetd.conf~ | |
Feb 14 2000 11:01:47168 .a. -rw-rw-r-- root | root | /x/root/.saves-1380-dragon~ | |
Feb 14 2000 11:18:38160 m.c -rw-r--r-- root | root | /x/etc/hosts.allow.old | |
Feb 14 2000 11:18:55347 m.c -rw-r--r-- root | root | /x/etc/hosts.deny.old | |
Feb 14 2000 11:19:088 m.c -rw-r--r-- root | root | /x/etc/hosts.deny | |
Feb 14 2000 11:22:53168 m.c -rw-rw-r-- root | root | /x/root/.saves-1380-dragon~ |
Feb 14 2000 11:30:302998 .a. -rw-r--r-- rootroot/x/etc/inetd.conf~
[MARK]
Feb 14 2000 11:31:2520164 .a. -rwsr-xr-x rootroot/x/usr/bin/xcat Feb 14 2000 11:34:10868 m.c -rwxr-xr-x rootroot/x/etc/rc.d/rc.local . . .
Después de repasar todo el listado de cambios históricos, puede que tengamos alguna pista para seguir o puede que no. En el peor de los casos debemos modificar la fecha especificada y cambiarla a la anterior del compromiso, intentándolo de nuevo, o mirar más detenidamente. Durante el examen del documento se prohibe distraerse ya que la concentración es muy importante en este momento.
Otra opción es recuperar ficheros borrados con el la utilidad unrm y luego examinarlos con el programa strings. Las dos utilidades unrm y lazarus generan muchísima información y debemos tener bastante espacio libre en la partición. Podemos determinar la cantidad de espacio en disco duro que necesitamos, calculando de forma aproximada a partir del informe de df.
# df /mnt | ||
---|---|---|
Filesystem | 1k-blocks | Used Available Use% Mounted on |
/dev/hdb2 | 3028881 | 16045511267697 56% /mnt |
En nuestro ejemplo df muestra que tenemos 1267697 bloques sin ocupar, que significa que unrm puede llegar a generar aproximadamente 1.2 Gb de información. Encontremos una partición libre y almacenemos allí el dump (Importante: en el ejemplo utilizo el punto de montura del sistema comprometido y no del sistema de análisis):
bin/unrm /dev/hdb2 > /data/victim.hda2.unrm
- Pero si disponemos de más espacio (más de 1.2Gb) y mucho más tiempo para practicar con lazarus que procesará el espacio libre en el disco duro y intentará recuperar ficheros por sus tipos. lazarus genera una salida en formato HTML, que nos va a dar la oportunidad de verla a través del navegador.