Search Results for: análisis forense

El antiguo reto de la honeynet (II)

22 de febrero de 2011 Por

Tras la entrada introductoria y preparatoria del otro día, hoy vamos a empezar con el reto. Lo primero que suelo hacer una vez obtenido los datos iniciales (vistos en la anterior entrada) es crearme una línea de tiempo a nivel de sistemas de ficheros y luego le sumo los datos obtenidos con la lógica que contiene el sistema de ficheros… Seguramente se estarán preguntando que es eso de la lógica que contiene el sistema de ficheros. Es lo que normalmente se denomina “artifacts“. Por ejemplo un fichero ejecutable cuyo dueño ya no existe en el sistema pero el fichero sigue existiendo, un usuario creado con permisos de administración, shellbags, históricos, logs, etc.

Comencemos obteniendo la línea de tiempos del sistema de ficheros. Para ello nos crearemos un directorio, volcaremos la línea de tiempo a un fichero con la herramienta “fls”, unificaremos los datos con un “cat” puesto que el reto presenta distintas imágenes, para finalizar traduciendo y ordenando con “mactime”. Es importante recordar que se nos indicó que la hora del sistema era GMT+6 y este dato deberá ser introducido a la herramienta mactime. Por ello debemos obtener el timezone correspondiente a GMT+6, por ejemplo de esta web. Con el timezone ya podemos ejecutar las ordenes necesarias para obtener la línea de tiempo:

# mkdir /reto/carving/timeline
# for i in `ls honeypot.hda*`; do fls -rp -m / $i > /reto/carving/timeline/$i; done
# cd /reto/carving/timeline
# cat * >> timeline
# mactime -z CST -b timeline >> lineaTiempo

Una vez obtenida, tenemos que estudiar el fichero lineaTiempo muy a fondo. Es importante recordar la fecha del incidente y buscar ficheros cuyos metadatos y datos hayan sido modificados. Pese a que el atacante haya usado herramientas como wipe, srm, touch para borrar sin rastro o cambiar la fecha, es muy complicado que modifique todos los ficheros y directorios a los que ha tenido acceso. Recordemos que el incidente fue a las 23:11 del 7 de noviembre de 2000.

Para analizar la línea de tiempo es necesario entender un poco que se muestra en el fichero lineaTiempo. Cada línea indica un fichero y están ordenadas por fecha, de más antiguas a menos. La línea tiene una serie de columnas que identifican de izquierda a derecha la fecha, el tamaño, MACB, permisos, UID, GID, número de inodo (importantísimo) y nombre del fichero.

Teniendo en cuenta que el ataque fue realizado el 7 de noviembre por la noche, tenemos que buscar modificaciones realizadas por esa fecha. Analizando la línea de tiempo vemos que el 8 de noviembre, unas horas después de detectar el exploit, se han hecho modificaciones algo sospechosas sobre algunos ficheros. Principalmente me llama la atención lo siguiente:

Wed Nov 08 2000 14:25:53 2836    .a.. r/rr-xr-xr-x 0 0 17088 /bin/uptime
Wed Nov 08 2000 14:26:15 0       m.c. r/rrw-r--r-- 0 0 26217 /etc/hosts.deny
Wed Nov 08 2000 14:26:51 1024    .a.. d/drwxr-xr-x 0 0 62497 /etc/rc.d/init.d
Wed Nov 08 2000 14:29:27 63728   .a.. r/rrwxr-xr-x 0 0 16125 /bin/ftp
Wed Nov 08 2000 14:33:42 1024    .a.. d/drwx------ 2 2 58465 /spool/at
Wed Nov 08 2000 14:45:18 161     .a.. r/rrw-r--r-- 0 0 26216 /etc/hosts.allow
                         0       .a.. r/rrw-r--r-- 0 0 26217 /etc/hosts.deny
                         31376   .a.. -/rrwxr-xr-x 0 0 93839 /$OrphanFiles/
                                                             OrphanFile-93839 (deleted)
Wed Nov 08 2000 14:45:19 63      .a.. r/rrw-r--r-- 0 0 26573 /etc/issue.net
Wed Nov 08 2000 14:45:24 1504    .a.. r/rrw-r--r-- 0 0 18147 /etc/security/console.perms
Wed Nov 08 2000 14:51:37 2129920 m... -/rrw-r--r-- 500 500 8133 /$OrphanFiles/
                                                                OrphanFile-8133 (deleted)
                         5324    .a.. r/rrwxr-xr-x 1010 100 109808 /man/.Ci/sp.pl
                         132785  .a.. r/rrwxr-xr-x 1010 100 109809 /man/.Ci/qs
                         350996  .a.. r/rrwxr-xr-x 1010 100 109812 /man/.Ci/syslogd

...

Wed Nov 08 2000 14:52:09 9        m.c. l/lrwxrwxrwx 0 0 23 /.bash_history -> /dev/null
                         9        m.c. l/lrwxrwxrwx 0 0 46636 /root/.bash_history -> 
						              /dev/null

(Y un ejército de ficheros huérfanos...)

¿Os acordáis de las tablas realizadas en la primera entrada? Si las consultamos obtenemos que m-c corresponde a la modificación del contenido del fichero. Si analizamos que ficheros han sido modificados obtenemos que “/etc/hosts.deny” y los history han sido modificados. Por un lado tenemos el típico enlace dinámico del bash_history al /dev/null para evitar que registre (¿porque no usar unset HISTFILE que canta menos? El atacante sabrá…), por otro lado tenemos que el hosts.deny ha sido modificado, con lo que probablemente se habrá eliminado alguna restricción de conexión con otros hosts (estaría bien tener acceso a las copias de seguridad previas al incidente para ver la configuración del fichero). También llama la atención el directorio “/man/.Ci”, apuntamos para repasar.

A su vez, vemos que existe un fichero huérfano (fichero eliminado cuyo padre también ha sido eliminado), que indica que el propietario es el usuario 500. Apuntamos; es importante revisar si el usuario existe en /etc/passwd. Por otro lado hay que destacar que el enlace dinámico a /dev/null ha sido realizado después de eliminar el fichero, por lo que es posible que obtengamos las órdenes ejecutadas en el bash_history a partir de los bloques libres (tras la eliminación, el bloque ha quedado asignado como libre, pero la información no ha sido eliminada).

Vamos a obtener los bloques, en crudo o raw, no asignados a ningún inodo, y por tanto, los bloques libres con el objetivo de buscar en ellos órdenes, firmas de malware u otro tipo de documentos. Para ello primeramente nos crearemos el directorio “/reto/carving/unallocated”, y estando en el directorio “/reto/dd” volcaremos los bloques sin asignar en el directorio unallocated:

# mkdir /reto/carving/unallocated
# for i in `ls honeypot.hda*`; do blkls -f ext2 $i > ../carving/unallocated/$i; done

Ahora ya tenemos los bloques libres, veamos a ver si encontramos alguna orden referente a los bash_history o host.deny. Para ello nos creamos un fichero en /reto/etc/ficheros que contenga ficheros que vamos a ir necesitando para el caso:

# echo "bash_history" > /reto/etc/ficheros
# echo "hosts.deny" >> /reto/etc/ficheros
# cd /reto/carving/unallocated
# srch_strings -a -td -5 * | grep -i -f /reto/etc/ficheros

  723938826 rm -rf /root/.bash_history
  723938853 ln -s /dev/null /root/.bash_history
  723938889 rm -rf /.bash_history
  723938911 ln -s /dev/null /.bash_history
  723938942 rm -rf ~games/.bash_history

...

  32494603 chmod a-w ~/.bash_history
  92321290 rm -rf /root/.bash_history
  92321317 ln -s /dev/null /root/.bash_history

...

  92321564 ln -s /dev/null /usr/games/.bash_history
  211349515 chmod a-w ~/.bash_history

...

  160623032 rm -rf /etc/hosts.deny
  160623055 touch /etc/hosts.deny
  212043412 @@contents /etc/hosts.deny 8

A partir de los resultados anteriores, vemos claramente la orden de eliminación del fichero hosts.deny, así como la creación con posterioridad. Lo mismo para los bash_history. Con lo anterior sacamos la conclusión de que a las 14:26:15 del miércoles 8 de noviembre el fichero hosts.deny fue modificado y a las Wed Nov 08 2000 14:52:09 se borraron las huellas del history. Se podría intentar sacar el contenido antiguo del fichero hosts.deny intentando pensar qué texto podría contener. Si pensamos detenidamente un tag típico sería el ALL por lo que con la orden

# srch_strings -a -td -3 * | grep "ALL:"

se podría obtener la línea del bloque donde se encuentra la información, pero en este caso, no da resultados. Ahora nos toca analizar más detenidamente la línea donde se ilustra la eliminación del fichero hosts.deny: “160623032 rm -rf /etc/hosts.deny”. Ese valor 160623032 identifica el byte donde la cadena fue encontrada. Como sabemos el tamaño del bloque es 1024 por tanto dividímos los 160623032 entre 1024 y nos quedamos con la parte entera, es decir, 156858. Ahora pensemos: estamos analizando los bloques libres de una imagen raw, por tanto necesitamos saber qué bloque real ocupa el bloque libre 156858 en la imagen completa, para ello usamos blkcalc:

# blkcalc /reto/dd/honeypot.hda8.dd -u 156858 
188701

Ahora ya sabemos que en el bloque de la imagen completa está la orden “rm -rf /etc/hosts.deny”. Veamos ahora el contenido del bloque, el cual debería corresponder con la parte del fichero “bash_history” que intentó ocultar el atacante:

# blkcat /reto/dd/honeypot.hda8.dd 188701

...

exit
uptime
rm -rf /etc/hosts.deny
touch /etc/hosts.deny
rm -rf /var/log/wtmp
touch /var/log/wtmp
killall -9 klogd
killall -9 syslogd
rm -rf /etc/rc.d/init.d/*log*
echo own:x:0:0::/root:/bin/bash >> /etc/passwd
echo adm1:x:5000:5000:Tech Admin:/tmp:/bin/bash >> /etc/passwd
echo own::10865:0:99999:7:-1:-1:134538460 >> /etc/shadow
echo adm1:Yi2yCGHo0wOwg:10884:0:99999:7:-1:-1:134538412 >> /etc/shadow
cat /etc/inetd.conf | grep tel
exit

Efectivamente, vemos que se trata del bash_history real, donde por un lado se ha hecho una purga de los logs y de los demonios que lo generan. Por otro lado se han creado dos usuarios, “own” y “adm1”. El primero con privilegios de root y el segundo con uid 5000. Con esto queda demostrado que el equipo ha sido comprometido.

El siguiente paso es comprobar que acciones adicionales han sido llevadas a cabo por el atacante y que utilidad estaba obteniendo éste del servidor. Para ello vamos a montar el entorno en forma de solo lectura y comenzar a comprobar las huellas obtenidas con anterioridad del sistema de ficheros:

  • ¿Initd sigue teniendo la puerta trasera?
  • Usuario 500, ¿quien es?
  • ¿Usuario own existe?
  • ¿Usuario adm1 (5000) existe?
  • ¿Que hay en el directorio /man/.Ci”

Para montar el sistema de ficheros he creado una script de forma que ejecutándolo monte o desmonte el sistema. Lo he creado en el directorio “/reto/dd” con nombre montar.sh y posteriormente le he asignado permisos de ejecución:

# touch /reto/dd/montar.sh
# chmod u+x /reto/dd/montar.sh
# vim /reto/dd/montar.sh

#!/bin/bash --
if [ "$1" == "1" ];
then
 /bin/mount -o loop,ro,noatime,noexec /reto/dd/honeypot.hda8.dd /reto/mnt/
 /bin/mount -o loop,ro,noatime,noexec /reto/dd/honeypot.hda1.dd /reto/mnt/boot/
 /bin/mount -o loop,ro,noatime,noexec /reto/dd/honeypot.hda6.dd /reto/mnt/home/
 /bin/mount -o loop,ro,noatime,noexec /reto/dd/honeypot.hda5.dd /reto/mnt/usr/
 /bin/mount -o loop,ro,noatime,noexec /reto/dd/honeypot.hda7.dd /reto/mnt/var/
else
 /bin/umount /reto/mnt/boot/
 /bin/umount /reto/mnt/usr/
 /bin/umount /reto/mnt/var/
 /bin/umount /reto/mnt/home/
 /bin/umount /reto/mnt/
fi

De esta forma, ejecutando “/reto/dd/montar.sh 1” monto el entorno y con “/reto/dd/montar.sh 0” lo desmonto. Así que ya sabéis, a montar el entorno toca:

# /reto/dd/montar.sh 1

Una vez montado comprobamos las consultas anteriores:

  • Las modificaciones en el servicio inetd durante el ataque no existe.
  • El usuario 500 es Drosen y existía antes del ataque.
  • El usuario own y adm1 no existen.
  • El directorio /man/.Ci existe: 
    # find /reto/mnt/ -type d -name ".Ci"
/reto/mnt/usr/man/.Ci

El siguiente paso consistirá en analizar el directorio “/reto/mnt/usr/man/.Ci” para revisar que hay dentro y ya les adelanto que nos encontramos una jungla:

# ls /reto/mnt/usr/man/.Ci
addn  backup  chmod-it  do  fix  killall  paki  q  rmS  snap  sniff.pid  syslogd
a.sh  addps  bx  clean  find  inetd  needz  pstree  qs  scan  snif  sp.pl  tcp.log

Empleemos con los ficheros anteriores la herramienta “file” que me permite clasificar los ficheros:

# file * | grep -v ELF | grep -v directory
a.sh: ASCII text
addps: POSIX shell script text executable
chmod-it: ASCII text
clean: ASCII text
do: ASCII text
needz: POSIX shell script text executable
rmS: POSIX shell script text executable
snap: POSIX shell script text executable
sniff.pid: ASCII text
sp.pl: a /usr/bin/perl script text executable
tcp.log: empty

Veamos que contienen los ficheros:

  • El fichero “a.sh” contiene la eliminación de binarios y parada de los servicios de esos binarios, todo apunta a que esto es el paso previo a la implantación de un RootKit a nivel de aplicación (porque como sea a nivel de núcleo difícil lo tenemos).
  • El fichero “addps” introduce en el fichero “/dev/ptyp” procesos, que según indica la propia documentación, son aquellos procesos que se quieren ocultar. Al mostrar el contenido del fichero vemos lo siguiente: 
    ...
2 snif
2 pscan
2 slice2
2 snif
2 pscan
2 telnet
2 x
2 xscan
2 ssh
...
  • El fichero “needz” muestra la dirección web de las herramientas pico y screen.
  • El fichero “rmS” elimina paquetes de software “ssh”, “wuftpd” y “nfs”.
  • El fichero “sp.pl” es un script en perl que levanta el sniffer “LinSniffer”, que escucha en una serie de puertos donde los password se transmiten en claro. Existe también un fichero Sniff.pid que contiene un número, que todo apunta a que se trata del PID del proceso, y por tanto, podemos creer que el sniffer llegó a ejecutarse…
  • El fichero “tcp.log” está vacío.
  • El fichero “do” contiene la eliminación de los usuarios “own” y “adm1” que encontramos al recuperar el bash_history real del usuario. Por tanto ya sabemos a ciencia cierta que el atacante creó dos usuarios, uno de ellos root, y que posteriormente los eliminó, por lo que todo indica que ha conseguido acceso a la máquina sin necesitar usuarios en el entorno.
  • El fichero “chmod” cambia permisos a varios binarios, volviéndolos igual o más restrictivos que los de serie en la distribución. Esto huele cada vez más a rootkit a nivel de aplicación.
  • El fichero “clean” ejecuta el fichero “snap” introduciéndole varias opciones. Ahora veremos que contiene “snap”.
  • El fichero “snap” es una shell en bash que dado una palabra quita todo rastro de esa palabra en los logs.

En cuanto a los directorios tenemos “backup”, “paki” y “scan”:

  • El directorio “backup” contiene los binarios de archivos importantes como ifconfig, ps o ls. He realizado una simple comprobación para ver si los binarios que están en backup son los mismos que los que tiene instalados el servidor, pero no, difieren: 
    # md5sum backup/ls ../../../bin/ls
5ec59b9c05706b4ce65adf44d0d3ab24 backup/ls
06be0dbe8e41a0266eeeeeb1c1b4c818 ../../../bin/ls
  • El directorio “paki” contiene dos herramientas. La primera es el código del stream y la segunda es slice2 cuya finalidad es la denegación de servicio (DoS).
  • El directorio “scan” contiene un gran número de ficheros cuyo objetivo es escanear host de la red e intentar ejecutar exploits sobre la máquina y crear puertas traseras. Si analizamos el código del “amd” vemos que intenta explotar vulnerabilidades en el RPC. Curiosamente es la misma vulnerabilidad con que ha sido comprometido el servidor.

En definitiva se trata de un RootKit a nivel de aplicación que permite mantener el control de la máquina, sniffar el tráfico de esta, atacar otras máquinas, ocultar huellas, ocultar procesos, etc. Buscando un poco por internet por si fuera un RootKit conocido he encontrado esta entrada que detalla bastante bien el RootKit.

El último paso a llevar a cabo es comprobar cómo consigue el atacante conectar a la máquina. Acordaos que hemos visto ficheros que borraban los instaladores de varios servicios. A su vez 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. Lo más recomendado es volver a la línea de tiempo por si pudiera proporcionarlos un poco más de información.

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 y adicionalmente añada 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.

Accedamos al directorio “/reto/mnt/usr/local/bin” y analicemos los ficheros modificados por el atacante. Lo que primero nos llama la atención es el SUID del fichero ssh1. Pero más que eso nos interesa ver el servicio que se arranca el SSH (“sshd1”) que se encuentra en el “/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 dedicadas únicamente al gdb. Bien veamos qué strings nos muestra esto:

# srch_strings -a -td sshd1
...
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)
...

Me llaman la atención dos cosas: por un lado la primera entrada ya que esa forma de cadena me recuerda mucho al hash de un MD5, y 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”:

# cat /reto/mnt/usr/tmp/nap
+-[ User Login ]-------------------- --- --- - -
| username: root password: tw1Lightz0ne hostname: c871553-b.jffsn1.mo.home.com
+----------------------------------- ----- --- -- -- -

Lo que pensaba: 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. Revisamos la contraseña del usuario root del entorno y 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 el usuario de root identificado en el fichero es el mismo que el del sistema:

# apt-get install john
# 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

Curiosamente 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 qué contraseña ha podido generar ese MD5. Se me ocurre una cosa bárbara 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 se registre… veamos a ver:

# echo "tw1Lightz0ne" | md5sum -
367d375770a5775c4a63d1862e2fceaf  -

No hay suerte. Algo se escapa… mmm claro, el salto de línea que añade el echo:

# echo -n "tw1Lightz0ne" | md5sum
d33e8f1a6397c6d2efd9a2aae748eb02

Bueno, 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 usuarios y contraseñas. Podemos apuntar el hostname “c871553-b.jffsn1.mo.home.com” como posible origen del atacante.

Para finalizar con el SSH vamos a comprobar si el servicio se inicia 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:

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 se trata de algo crítico, puesto que un DNS puede usarse para una multitud de funciones. Si seguimos analizando la línea de tiempo veremos cómo el atacante una vez instalado los servicios indicados con anterioridad eliminó las fuentes de instalación:

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)

Podemos recuperar las herramientas que usó el atacante aprovechando que el sistema de ficheros es Ext2. Recordar que cuando eliminamos ficheros en Ext2, a diferencia de Ext3 y Ext4, los “punteros” (enlaces directos e indirectos) del inodo hacia los bloques donde se almacena los datos no se eliminan. Por tanto somos capaces de, sabiendo el inodo del fichero eliminado, recuperar su contenido, siempre y claro está que el contenido no haya sido sobreescrito por otro fichero. Por ejemplo, para el demonio de ssh:

# istat honeypot.hda5.dd 109791
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 ...

Esos datos que se muestran al 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:

# icat honeypot.hda5.dd 109791 >> /reto/evidencia/ssh-1.2.27.tar
# 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"

Ya tenemos un ssh troyanizado para la colección. Volvamos 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:

Wed Nov 08 2000 14:56:57     4096 .a.. d/drwxr-xr-x 1010 100 109798 /man/.Ci
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

Ya para finalizar vemos algo raro y que no esperaba: el “bash_history” y el home de Drosen se han creado durante los 15 minutos en los que se implantó el Rootkit:

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 en un principio. 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:

# cat /reto/mnt/etc/passwd | grep drosen | awk -F':' {'print $3'}
500
# find /reto/mnt/home/drosen/ -type f -uid 500 2> /dev/null

(no sale nada interesante)

Veamos a ver si encontramos algo que coincida con tpack:

# find /reto/mnt/ -type f -iname "*tpack*"

(No hay suerte)

Llegado a este punto, podría decir que no sé qué fichero instaló el usuario. Seguramente si se analizara la línea de tiempo con más detenimiento podríamos obtener dicho fichero.

Como análisis superficial del incidente podemos tener una estimación de cuándo se hizo, cómo se hizo, qué se implantó en el servidor, cómo se conectaba el atacante al equipo y como intentó el atacante ocultar sus huellas. Para finalizar la entrada quiero indicar que aunque normalmente se emplea en cualquier análisis forense uno de mis packs de herramientas favoritas: foremost, sorter, md5depp y hfind, , debido a la antigüedad de este reto me ha sido imposible usarlo en este caso. El objetivo de estos programas es generar una lista blanca a partir de un entorno no comprometido con una configuración similar, lo que nos permitirá eliminar supuestos, adicionalmente combinarlo con una lista negra de malware, permitiendo reducir drásticamente los ficheros a tratar.

Espero que les haya gustado, y todo sea dicho, si se han leído toda la entrada se merecen un premio. Nos vemos en la próxima entrada.

El antiguo reto de la honeynet (I)

16 de febrero de 2011 Por

En esta y la siguiente entrada trataré el reto de análisis forense de la honeynet (proyecto Honeynet). Aunque antiguo, es la base de un análisis forense en un entorno Linux y creo que se pueden aprender muchas cosas. Existe una infinidad de soluciones tanto en blogs como en libros sobre la resolución del reto. En mi caso voy a seguir los pasos que seguí para la resolución de éste. Les advierto que tanto este como el siguiente artículo de la serie son algo largos, así que tómenselos con calma.

Preparando el entorno del reto

Comenzaremos montando una máquina virtual Linux. Primero instalaremos en el equipo anfitrión VirtualBox en su versión 4. A su vez nos descargaremos una imagen ISO de una distribución Linux. En mi caso he usado la Ubuntu 10.04. puesto que ya la tenia descargada. Una vez tengamos creada la máquina virtual instalaremos las LinuxAdditions.

[Read more…]

La orden shun

1 de septiembre de 2010 Por

Como cada día 1 de septiembre desde hace unos años, volvemos a la carga con el blog; y como cada día 1 de septiembre desde hace unos años esperamos que las vacaciones hayan sido provechosas en todos los sentidos, que hayan descansado y que vuelvan con las pilas cargadas para los meses que nos quedan (sólo 11) hasta el próximo periodo de descanso estival. Tras el mes de agosto, vamos a comenzar con la marcha habitual en Security Art Work, en este caso con un post de José Luis acerca del filtrado en los dispositivos ASA de Cisco. Vamos allá…

Si en nuestra organización disponemos de un IPS, cuando éste detecta un ataque suele filtrar de forma inmediata el tráfico proveniente de la dirección IP atacante; no obstante, si simplemente tenemos un IDS, una vez que nuestros sistemas de detección han detectado y notificado una actividad potencialmente sospechosa, la primera función que suele llevar a cabo el personal de seguridad es el filtrado manual de las conexiones en el firewall corporativo para, posteriormente, realizar un análisis más minucioso del ataque, una análisis forense e incluso, en caso de ser necesario, proceder a denunciar el hecho ante las FFCCSE. En cualquier caso, la velocidad de respuesta a la hora de llevar a cabo el filtrado de la dirección IP que nos ataca es crítica, ya que cuanto más tiempo pueda tener acceso el atacante a nuestros sistemas, mayor será el daño que nos cause, por ejemplo dejando puertas abiertas para conexiones futuras o directamente robando información.

Aunque debemos tener perfectamente procedimentados y probados los pasos a seguir como respuesta a un ataque -o intento de ataque-, lo cierto es que durante esos momentos de ‘tensión’ lo primero que se suele hacer es, al menos, filtrar todo tipo de acceso desde la IP atacante a nuestros sistemas. En este post se va a tratar una forma rápida y sencilla para llevar a cabo el filtrado de conexiones sospechosas en sistemas firealls ASA de Cisco Systems, los cuales integran otros sistemas como VPN o IPS.

A la hora de integrar un IPS en el sistema ASA, lo habitual es contar con una tarjeta hardware dedicada en el propio equipo o con sensores distribuidos en la red que recopilan la informacion del ataque y envían las órdenes de filtrado al firewall. Puesto que asuminos que no tenemos este tipo de sistemas -si los tuviéramos, el filtrado sería automático, como hemos comentado-, podemos usar directamente la orden shun de ASA para filtrar direcciones concretas de forma cómoda; incluso mediante la creación de varios scripts, podríamos integrar un IDS como Snort con un firewall ASA.

El funcionamiento de la orden shun es sencillo. Su función es básicamente la de finalizar las conexiones ACTUALES y denegar las nuevas conexiones, basándose en una serie de parámetros como pueden ser la dirección IP origen, la dirección o puerto destino, el tipo de protocolo, etc. A su vez, también registra las conexiones filtradas hasta que las direcciones son habilitadas de nuevo en el firewall. Por ejemplo, si nuestro IDS ha detectado un potencial ataque desde una IP externa (para este ejemplo, tomamos la dirección privada 192.168.1.1) hacia nuestro servidor web (con dirección 10.20.20.1), podemos proceder a filtrar la IP externa en nuestro firewall:

ASA# shun 192.168.1.1
Shun 192.168.1.1 successful
401002: Shun added: 192.168.1.1 0.0.0.0 0 0
401004: Shunned packet: 192.168.1.1 ==> 10.20.20.1 on interface outside
401004: Shunned packet: 192.168.1.1 ==> 10.20.20.1 on interface outside
401004: Shunned packet: 192.168.1.1 ==> 10.20.20.1 on interface outside
401004: Shunned packet: 192.168.1.1 ==> 10.20.20.1 on interface outside

Comprobamos que hemos aplicado shunning IDS y aumentan los contadores de tráfico bloqueado:

ASA# show shun stat
outside=ON, cnt=134
inside=OFF, cnt=0
intf2=OFF, cnt=0

Shun 192.168.1.1 cnt=9, time=(0:00:10)

Si en un futuro necesitamos habilitar de nuevo el tráfico desde la dirección IP que hemos bloqueado, podemos hacerlo mediante la siguiente orden:

ASA# no shun 192.168.1.1
401003: Shun deleted: 192.168.1.1

Como vemos, Cisco ASA proporciona una orden rápida y sencilla para bloquear completamente a un atacante en nuestro cortafuegos. Aunque lo ideal es tener un sistema IPS que filtre los ataques de forma automática, en caso de que esto no sea posible, el filtrado manual se vuelve un proceso critico, por lo que debe ser procedimentado y conocido por el personal de seguridad. Y por supuesto debe ser probado de forma periódica, ya que como sabemos, los momentos de tensión son los peores para ponerse a probar…

Monitorizando usuarios en Solaris

9 de junio de 2010 Por

Como llevo algunas noches de insomnio me ha dado por refrescar, tras algunos años olvidados en un cajón, aspectos de monitorización de usuarios en Solaris (Solaris 10, para ser exactos); y la verdad es que de lo que conocía -dejé de administrar máquinas Solaris “en serio” en su versión 7- a lo que me he encontrado en las nuevas versiones del operativo, hay alguna que otra diferencia que sorprende gratamente, y es que a pesar de que ahora sea un producto de Oracle, Solaris sigue siendo Solaris :)

Como siempre, para generar trazas “en serio” de la actividad de los usuarios podemos utilizar el Basic Security Module, habilitado mediante bsmconv(1M) y que nos dirá hasta qué usuario pestañea demasiado delante de la consola :) ¿Problemas? Alguno que otro… para empezar, requerimos reiniciar el sistema, cosa que ya de por sí a nadie le gusta mucho… y para continuar, tenemos el problema histórico del volumen de datos que generamos: por muy bien que configuremos el módulo de auditoría, incluso si lo hacemos por usuario, la cantidad de registros que se almacenan en la máquina no deja de ser considerable… y lo peor de todo: la marcha atrás tras habilitar BSM en nuestro sistema implica de nuevo detener servicios (la orden bsmunconv hay que lanzarla en runlevel 1).

Aunque BSM es la solución correcta y definitiva si necesitamos un registro de auditoría al detalle, me ha sorprendido en Solaris 10 DTrace, un framework que permite monitorizar en tiempo real y sin parada de sistema determinados aspectos tanto del núcleo como del espacio de usuario; este framework incorpora un lenguaje de programación propio (“D”), que nos permite registrar, de forma sencilla, actividad en el sistema de cara a detectar problemas, a “tunear”, o simplemente a monitorizar determinada actividad en la máquina (accesos a un fichero, cambios en inodos, etc.). Por supuesto, para esto último no es tan completo como BSM -que insisto, es la solución correcta-, pero nos puede servir para sacarnos de más de un apuro en cuanto a conocer qué hacen nuestros usuarios.

Un ejemplo de monitorización sencilla: ¿qué órdenes ejecuta un determinado usuario? Mediante dtrace(1M), es trivial obtener esta información: ponemos “vigilantes”, generadores de información, en las llamadas al sistema exec() y familia, y la condición de que el UID del usuario que usa estas llamadas – que pasaremos como argumento al programa- sea uno en concreto; si esto se cumple, imprimimos la información que nos interesa:

# cat t.d
syscall::exec:return, syscall::exece:return
/ uid==$1 /
{
printf("%s %-20Y %S\n", probefunc, walltimestamp, curpsinfo->pr_psargs);
}
# dtrace -s prueba.d 100
dtrace: script 'prueba.d' matched 2 probes
CPU ID FUNCTION:NAME
0 108 exece:return exece 2010 Jun 9 18:54:17 ls
0 108 exece:return exece 2010 Jun 9 18:54:28 more prueba.d
#

Seguro que el código se puede mejorar, ya lo sé :) Más cosas que nos pueden interesar de la actividad de un usuario: archivos abiertos, conexiones de red…todo esto es bastante sencillo obtenerlo mediante dtrace(1M), sus probes y las condiciones adecuadas; podemos poner todo junto, y en bonito (para que nos muestre la información más legible, básicamente) en un script que invocaremos desde línea de órdenes:

# cat luser.d
#pragma D option quiet
/*
* Ejecucion de ordenes
*/
syscall::exec:return, syscall::exece:return
/ uid==$1 /
{
printf("%s %-20Y %S\n", probefunc, walltimestamp, curpsinfo->pr_psargs);
}
/*
* Acceso a FS
*/
syscall::open:entry, syscall::creat:entry,
syscall::open64:entry, syscall::creat64:entry,
syscall::unlink:entry, syscall::rename:entry
/ uid==$1 && strstr(stringof(copyinstr(arg0)), "/proc") == NULL /
/* Nos quitamos de la condicion el acceso a procfs */
{
printf("%s %Y %s\n", probefunc, walltimestamp, stringof(copyinstr(arg0)));
}
/*
* Acceso a red / TCP
*/
::tcp_send_data:entry
{
self->lport=((unsigned int) args[0]->tcp_tcph->th_lport[0] < <8) + (unsigned int) args[0]->tcp_tcph->th_lport[1];
dig1=(unsigned int) args[0]->tcp_tcph->th_fport[0];
dig2=(unsigned int) args[0]->tcp_tcph->th_fport[1];
dig1=dig1< <8; self->rport=((unsigned int) args[0]->tcp_tcph->th_fport[0] < <8) + (unsigned int) args[0]->tcp_tcph->th_fport[1];
srcaddr=(unsigned int) (args[0]->tcp_ipha->ipha_src);
dstaddr=(unsigned int) (args[0]->tcp_ipha->ipha_dst);
self->octect[0]=srcaddr>>3*8 & 0xFF;
self->octect[1]=srcaddr>>2*8 & 0xFF;
self->octect[2]=srcaddr>>1*8 & 0xFF;
self->octect[3]=srcaddr>>0*8 & 0xFF;
self->octect[4]=dstaddr>>3*8 & 0xFF;
self->octect[5]=dstaddr>>2*8 & 0xFF;
self->octect[6]=dstaddr>>1*8 & 0xFF;
self->octect[7]=dstaddr>>0*8 & 0xFF;
self->ok=1;
}
::tcp_send_data:entry
/ self->ok && uid==$1 /
{
printf("%s %Y %d.%d.%d.%d:%d -> %d.%d.%d.%d:%d\n", probefunc,walltimestamp,self->octect[0],self->octect[1],self->octect[2],self->octect[3], self->lport,self->octect[4],self->octect[5],self->octect[6],self->octect[7],self->rport);
self->ok=0;
}
#

Al invocarlo mediante dtrace(1M), la salida que obtendremos será similar a la siguiente -con muchos más datos que habrá que filtrar, no estoy ahora para pulir el código que, insisto, es un simple ejemplo y tendrá N fallos y mejoras-):

tcp_send_data 2010 Jun 9 19:00:37 192.168.1.2:22 -> 192.168.1.5:37963
tcp_send_data 2010 Jun 9 19:00:38 192.168.1.2:22 -> 192.168.1.5:37964
tcp_send_data 2010 Jun 9 19:00:38 192.168.1.2:22 -> 192.168.1.5:37963
exece 2010 Jun 9 19:00:38 cat /home/toni/fbsd-como\0
open 2010 Jun 9 19:00:38 /var/ld/ld.config
open 2010 Jun 9 19:00:38 /lib/libc.so.1
open 2010 Jun 9 19:00:38 /platform/SUNW,Ultra-5_10/lib/libc_psr.so.1

Así, mediante dtrace(1M), y de una forma muy sencilla, estamos en disposición de monitorizar muchísimas acciones -en este caso de un usuario concreto- que pueden servirnos para incrementar considerablemente la seguridad de nuestros sistemas Solaris desde el punto de vista de monitorización de la actividad (aparte de para resolver algún problema en las máquinas). Por supuesto, con un ratito de búsqueda en Google tendremos acceso a un montón de ejemplos de programas en D que podemos adaptar y aprovechar para crear un luser.d en condiciones :)

En definitiva, dtrace(1M) es una herramienta que no conocía más que de oídas y que, a poco que he empezado a tocarla, me ha sorprendido muy gratamente (tanto por su capacidad como por su sencillez) para la monitorización de ciertas actividades concretas del sistema o de nuestros usuarios, sin necesidad de meternos en el “gran” BSM… además, puede ser muy útil en aquellos casos en los que BSM no esté habilitado de antemano, por ejemplo si nos enfrentamos a un análisis forense de una Solaris comprometida… en fin, que seguiremos informando :) Por cierto, ¿alguien se anima a explicarnos algo similar en Linux, Windows, AIX, etc.? Sé que Dtrace se ha migrado -o se está migrando- a BSD, pero no sé si tenemos algo de capacidades similares en otros entornos (es que ya no soy técnico :)

La importancia de los registros de sistema

22 de marzo de 2010 Por

Habitualmente, todos los profesionales que nos dedicamos en mayor o menor medida a la seguridad nos vemos en la necesidad de gestionar incidentes de seguridad; para ello, nuestra mayor fuente de información suelen ser los registros o logs de los sistemas implicados, tanto a nivel de comunicaciones (routers, cortafuegos, IDS, etc) como a nivel de sistema (Unix, Windows, Linux, etc.) y de aplicación (servidor web, servidor de correo, etc.). Desgraciadamente, es habitual que cuando el potencial cliente ha contactado con nosotros, su personal técnico, siempre con buena intención, haya realizado acciones que invalidan parcial o incluso totalmente los registros y con ello cualquier vía de investigación: formateo de servidores, borrado de logs, limpieza manual de entradas, etc. Como es natural, esto limita sensiblemente la información del incidente que se puede obtener, por lo que es imprescindible que no se lleven a cabo acciones que puedan modificar “la escena del crimen”, casi de la misma manera que puede verse en una película policíaca. No obstante, dejemos eso para una entrada sobre análisis forense y pasemos al análisis de los registros.

A la hora de analizar estos logs nos encontramos principalmente dos problemas. El primero es su fiabilidad ya que ante un sistema comprometido, es inevitable preguntarse: ¿cómo de fiables son nuestros registros?, puesto que probablemente hayan sido alterados o borrados. El segundo problema tiene mucho que ver con la correlación temporal de la información contenida en los registros implicados en el incidente, generando preguntas del tipo: ¿las fechas de los diferentes sistemas se encuentran sincronizadas? ¿Qué sucedió antes y qué después? ¿De qué volumen de logs del incidente dispongo? ¿Hasta cuándo puedo retroceder?

Para el primero de los problemas la opción más habitual es contar con un sistema syslog que reciba los registros de los diferentes sistemas y dispositivos de red distribuidos por la organización, ubicado en un servidor que haya sido convenientemente securizado, limitando el número de servicios que ofrece y controles de acceso, entre otros. Esto permite tener la relativa seguridad de que la información que estamos manejando en la gestión de incidente es veraz. Además, tener los registros duplicados en el sistema de origen y en el servidor syslog permite a posteriori comparar ambos, y detectar así posibles modificaciones que proporcionen información sobre el atacante. Aunque este tipo de configuraciones son relativamente comunes en entornos donde hay mayoría de sistemas Unix/Linux, es raro encontrarlas en entornos Wintel, aunque las ventajas son similares.

En relación con la correlación de registros en el análisis del incidente, es vital que podamos determinar el orden de los acontecimientos, razón por la que el objetivo de control 10.10 Monitorización de la norma ISO 27001 requiere la existencia de un servidor NTP de sincronización que asegure que las fechas de los registros guardan un orden real; de lo contrario, en un entorno que los sistemas y dispositivos de red están no sincronizados en un rango de unos pocos minutos, la reconstrucción puede ser para volverse loco. También para este aspecto un sistema syslog es muy útil, ya que ordena de manera automática los mensajes recibidos de los distintos agentes.

Si no se dispone de un servidor syslog (o éste se limita a recibir la información de los dispositivos de red, dejando fuera los sistemas) y el volumen de información es reducido, la correlación de eventos se puede llevar a cabo de forma manual, aunque lo habitual es usar herramientas de correlacion de logs o alertas que nos permitan obtener información concreta en el menor tiempo posible, aspecto crítico en la gestión de incidentes. Esto no evitará que tengamos que revisar los logs con más detalle posteriormente, ya que aparte de obtener información adicional podría ser necesario presentar una denuncia antes las autorizades competentes, pero sí que facilita y acelera la puesta en marcha de las acciones necesarias para reducir el impacto del incidente en los primeros momentos. Con sistemas automatizados de detección, correlación y alerta, sería posible según los patrones configurados y por lo tanto, potencialmente detectables, anticiparnos al incidente; por ejemplo, pensemos en un ataque externo ocasionado por un nuevo gusano, cuyos patrones de conducta están reportados y de los que existen reglas para detectarlo o filtrarlo en nuestros sistemas (IDS/IPS).

Una visión global de estos aspectos es la que proporciona el proyecto Dshield junto con el Internet Storm Center de Sans Institute. A través de este proyecto, es posible enviar los logs de nuestros sistemas para detectar patrones globales de ataques futuros, formando de este modo un sistema de detección de intrusos distribuido a nivel global, que categoriza las amenazas en 4 niveles: verde, amarillo, naranja y rojo, dependiendo de su impacto potencial. Para evitar proporcionar información sensible al proyecto, como podrían ser las direcciones IP que están siendo atacadas, lo cual podría ocasionar posibles pérdidas para las empresas objetivos del ataque (daño a la imagen corporativa, desconfianza de clientes, etc), dependiendo del tipo de sistema, es posible enmascarar dichas direcciones, de forma que se puede ocultar total o parcialmente la dirección IP. El proyecto dispone de un gran listado de sistemas que soportan el envío de logs al sistema de correlación de forma más o menos automatizada, entre los cuales podemos encontrar dispositivos de grandes fabricantes como Cisco o CheckPoint. Una vez analizados y correlados los logs recibidos, es posible obtener las alertas generadas por el Storm Center, como por ejemplo un listado de direcciones IP potencialmente atacantes, para filtrarlas en nuestros sistemas.

Para finalizar, debemos tener en cuenta que ni el proyecto Dshield, ni el ISC de Sans, ni una correcta gestión de registros garantizan la protección de nuestra red, pero sí que constituyen mecanismos adicionales de reducción de riesgos. Y ya saben que todo suma.

(Entrada elaborada conjuntamente con Manuel Benet)

Retención de documentación y aspectos legales

12 de noviembre de 2009 Por

(La entrada de hoy es la quinta colaboración de Francisco Benet, que como ya les hemos comentado anteriormente es un amigo de algunos de nosotros —y familia de algún otro— que tiene gran experiencia en la gestión e integración de sistemas, protección de datos de carácter personal y evaluación de soluciones de integración de software y hardware, entre otros aspectos. Esperamos que les guste.)

La documentación de una empresa es como su vida misma, ya que define generalmente su negocio. Esta es la razón por la que la retención de documentos es un factor clave para las organizaciones. Podemos definir la retención de documentos como el periodo de tiempo que un documento (ya veremos cómo definir que es un documento) debe estar ‘vivo’ o ‘accesible’ para poder ser usado; es como aquel traje que sólo nos ponemos para ir a la misa del gallo: debe estar ahí para el día que lo necesitemos.

Hoy y aquí intentaremos acercar un poco más este aspecto legal y técnico tan poco ‘trabajado’.

Para empezar, todo este ’embrollo’ debe comenzar, cómo no, con la generación de una política, que esté en consonancia con la Política de Clasificación de la Información (ver estas dos entradas sobre el tema). Hay que destacar que un aspecto crítico en todo este jaleo es el aspecto legal, ya que el documento en sí mismo puede tener unos aspectos legales importantes que constituyen el principal handicap (y que veremos más adelante).

Por tanto, en la definición de dicha política esta altamente implicado el departamento legal, tanto para definir los periodos de retención, como para poder traducir todos los requerimientos legales en la definición del par categoría del documento-período de retención. Otros participantes deberán ser Dirección y el Responsable de Seguridad, como responsables y encargados de implantar y hacer cumplir dicha política (aunque la figura puede ser otra). Otro de los principales problemas que no debemos olvidar es la destrucción de la información no necesaria; esto deberá estar plasmado en la política.

[Read more…]

Ante todo mucha calma

5 de noviembre de 2009 Por

Son muchas las recomendaciones hechas por ITIL en su Gestión de Incidencias, todas útiles y de implantación obligatoria. Eso sí, ITIL no te las va a resolver, sino que te va a ayudar para establecer un proceso para gestionar cada una de las incidencias, aprender de ellas, ser más proactivos y reactivos, obtener mejoras de cada una de ellas y aplicarlas a la infraestructura IT que se tenga, que no es poco…

Saber reaccionar ante una incidencia es fundamental, y más aun si conlleva una pérdida de servicio. En este tipo de casos la experiencia es el rasgo más valorado para saber afrontarlas. Por mucha preparación técnica que se tenga, es difícil mantener la compostura y tener la serenidad suficiente para poder abstraerse de la presión y analizar la situación.

[Read more…]

Un USB lleno de fotos

14 de octubre de 2009 Por

(La entrada de hoy es la cuarta colaboración de Francisco Benet , un amigo de algunos de nosotros —y familia de algún otro— que tiene gran experiencia en la gestión e integración de sistemas, protección de datos de carácter personal y evaluación de soluciones de integración de software y hardware, entre otros aspectos. Esperamos que les guste.)

Continuamente con el rabillo del ojo miraba hacia ambos lados, pero ya no quedaba casi nadie en la oficina. Tampoco le interesaba quedarse solo; había que aparecer y desaparecer, como en un día normal, como en una situación normal. Al fin y al cabo era un día ‘normal’ para todos… excepto para Ramón.

[Read more…]

Black Hat USA ’09

8 de octubre de 2009 Por

bhComo todos los veranos, este año se ha celebrado la Black Hat, un conjunto de conferencias donde se desvelan las ultimas tendencias en seguridad, cubriendo con detalle la parte técnica aunque también cada vez mas la parte organizativa y social. Aunque desgraciadamente no he podido asistir a estas charlas, tantos los papers comos los slides están disponibles en la web en la parte de archivos Blackhat.

Muchos equipos investigadores esperan a este evento para desvelar sus descubrimientos, por lo que creo que son de lectura obligatoria para aquellos que quieren ver por dónde van las ultimas tendencias y el “state of the art” en el mundo de la seguridad.

Tras echar un vistazo a las presentaciones, uno tiene la impresión que nada es seguro, ya sean teléfonos móviles, parquímetros, infraestructuras eléctricas, medidas antihacking, certificados SSL, la virtualización, la nube, o cualquier tipo de hardware que puedan imaginar. Los malos pueden incluso leer tu teclado desde el enchufe de tu ordenador, así que la única opción parece ser volver a las cuevas. En fin, que para cualquier “maldad” que puedan imaginar ya hay quien se dedica a aplicarla… y en estas charlas se pueden ver muchas de ellas.

[Read more…]

Peritajes informáticos

27 de abril de 2009 Por

Cuando una organización sufre determinados incidentes de seguridad (por ejemplo, una intrusión), se plantea la realización de un análisis forense, en el que se tratan de obtener y presentar evidencias electrónicas del problema acaecido; adicionalmente, en ocasiones —no siempre, aunque si se ha producido un delito debería ser así—, es necesario efectuar una denuncia, y es entonces cuando surge la necesidad de realizar un peritaje informático por parte de un perito cualificado.

Un peritaje informático tiene como objeto dar respuesta técnica a una serie de cuestiones planteadas bien por una de las partes bien por el propio juez; dicha respuesta, por muy complejos que sean el desarrollo o las bases de la misma, debe ser concisa y sencilla (pensemos que la tienen que interpretar personas que no tienen por qué estar familiarizadas técnicamente con el objeto del informe). Así, siempre es conveniente incluir un apartado de “conclusiones” dentro de nuestro informe, en el que en base a todo lo desarrollado en el cuerpo del mismo, se muestren de forma resumida las respuestas a las cuestiones planteadas.

Para poder realizar y defender un informe pericial no es necesario, a priori, ningún requisito especial; no obstante, en la práctica suele ser positivo para que el informe sea tenido en cuenta por el juez, bien disponer de una titulación académica adecuada al objeto del informe, o bien disponer de una experiencia profesional en el campo al que el informe hace referencia. Dicho de otra forma, yo podría presentar un informe pericial acerca de los problemas de salud que un determinado individuo dice padecer y dar mi opinión acerca de si estos problemas han influido en la comisión de un delito, pero como no soy médico, mi informe sería poco más que papel mojado ante un tribunal. Por este motivo, cuando estamos tratando casos en los que entran en juego la informática o las telecomunicaciones, tanto el juez como las partes tratarán de buscar peritos Ingenieros Informáticos o de Telecomunicación. Las empresas de seguridad que tienen entre su catálogo de servicios, dentro de los aspectos de gestión de incidentes, los peritajes, disponen —o deben disponer— de Ingenieros cualificados para realizar estos informes; además, los Colegios Oficiales disponen en muchos casos de turnos de actuación profesional (algo equivalente al turno de oficio para los abogados) para aportar peritos en aquellos casos en los que se solicitan (por ejemplo, en la Comunidad Valenciana, el Colegio Oficial de Ingenieros en Informática dispone de este turno de actuación).

Los que hemos realizado y defendido informes periciales —tanto de parte como judiciales— ante un juez, nos hemos tenido que enfrentar en muchas ocasiones a los principales problemas que bajo mi punto de vista existen a la hora de emitir un informe; en este orden:

— Incapacidad técnica para la emisión del dictamen.

Si hay que realizar un informe acerca de un individuo que se ha roto una pierna, desde el juzgado buscarán a un traumatólogo, no a un neurocirujano, por muy médico que este sea. Obvio, ¿verdad? Pues cuando entra en juego la tecnología, esto no es tan obvio… exagerando un poco, si asesinan a alguien dándole golpes con un portátil, es fácil que se busque a un Ingeniero Informático para emitir el informe en cuestión. Ante casos de este tipo, el perito debe ser tajante: se rechaza la realización del informe por incapacidad técnica. Por muy perito informático que yo sea, rechazaré una pericia relacionada con el mal funcionamiento de un SAP, porque desconozco técnicamente su funcionamiento y no me siento capacitado para hablar con propiedad sobre este entorno —y más cuando delante tengo a gente que puede estar jugándose penas de cárcel—.

— Técnicamente, todo es posible.

Por muy obvia que para un técnico sea una cuestión, para un juez o un abogado no lo es tanto; así, si estamos realizando un informe en el que se indica que un individuo ha utilizado su ordenador para atacar sistemas de terceros, y al individuo en cuestión se le incauta un equipo lleno de herramientas de hacking (con sus correspondientes accesos directos en el escritorio), ficheros de contraseñas, logs de chats… el acusado siempre puede decir que todo eso “se lo han puesto por la WiFi” y que él no sabe nada. Y cuando nos pregunten si eso es técnicamente posible, tendremos que decir que sí (aunque insistamos en la baja probabilidad por N motivos). En función del juez que lleve el caso, se declarará al acusado inocente.

— Contraposición de visiones: juristas y peritos.

Como hemos dicho antes, cuando realizamos un informe pericial debemos responder desde un punto de vista técnico a una serie de cuestiones que se nos plantean; es vital no incluir nunca opiniones personales no fundadas, y también es importante no entrar en el ámbito del abogado o del juez: un perito nunca puede decir, por muy obvio que técnicamente le parezca, que el acusado es culpable o inocente. Los aspectos jurídicos no entran de ninguna manera en el ámbito de actuación de un perito. De la misma forma, el perito no puede admitir —esto suele suceder en los informes de parte, no en los judiciales— opiniones legalistas que no se correspondan con la estricta realidad: si en nuestro informe decimos que algo es “altamente improbable” queremos decir sólo eso, que es altamente improbable, y no que es imposible (un término que seguramente para el abogado será mucho más directo y efectivo, y por tanto tratará que incluyamos en el informe, pero que técnicamente puede no ser cierto).

Finalmente, un problema que no es exclusivo de los peritos, sino que quizás es generalizado en el sistema judicial: para defender durante quince minutos nuestro informe, seguramente invirtamos toda una mañana en los juzgados. Ante esto, paciencia: es lo único que podemos hacer como peritos :)