Historias de hackers: "A la caza del ciberdelincuente"

No hace mucho os contaba en este blog la historia de un "Hacker" que, por encargo, entraba en el servidor de una empresa y robaba los datos de los clientes. Al final de la historia, el ciberdelincuente acaba entre rejas, y ésta es la historia de cómo fue cazado.

La llamada

En esta profesión no hay horarios, la llamada puede llegar en cualquier momento, y un viernes por la tarde como éste era tan buen o mal momento como otro. Supongo que la resignación se me notaba en la voz cuando me llamaron de la oficina, porque María, que estaba hoy de guardia, no paraba de repetir que no había nadie más disponible, sólo Juan, mi compañero, y yo. Normalmente acudimos con algún compañero, ya que dicen que cuatro ojos ven más que dos.
La empresa ABOGADOS S.A. ha contratado los servicios de un analista forense a través de mi empresa, ya que tienen sospechas de que se ha producido un acceso no autorizado a su servidor y un posible robo de información. Todo empezó con una alarma del firewall perimetral de la empresa, que dispone de un IDS (Intrusion Detection System) que avisó de una actividad extraña en el tráfico de red.
El administrador de sistemas piensa que ha podido ser un simple intento de ataque de denegación de servicio porque el IDS informó de un alto nivel de tráfico, pero el director de la empresa prefiere asegurarse y prefiere realizar un análisis del sistema en más profundidad.

Analizando el equipo afectado

Cuando llegamos a la oficina de la empresa procedemos a realizar una imagen del disco del equipo afectado, que se encuentra apagado. ¿Cómo habéis apagado el equipo? -pregunto.
El Administrador de sistemas de la empresa me dice que ha tirado directamente del cable porque ha leído no sé donde que si apagaba el equipo ordenadamente podría destruir alguna prueba.
Le digo que ha hecho bien mientras Juan ha conectado un disco duro al equipo para hacer la copia y termina de arrancar el ordenador desde un LiveCD. Solemos llevar un duplicador de discos, pero no nos ha dado tiempo a pasar por la oficina para recogerlo, así que vamos a hacer las cosas al modo clásico.

Usamos fdisk para comprobar los discos que hay en el sistema.

root@forensix:~# fdisk -l

Disco /dev/sda: 8589 MB, 8589934592 bytes
255 heads, 63 sectors/track, 1044 cylinders, 16777216 sectores en total
Units = sectores of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Identificador del disco: 0x000b6d59

Disposit. Inicio    Comienzo      Fin      Bloques  Id  Sistema
/dev/sda1   *          63    16016804     8008371   83  Linux
/dev/sda2        16016805    16771859      377527+   5  Extendida
/dev/sda5        16016868    16771859      377496   82  Linux swap / Solaris

Disk /dev/sdb: 21.8 GB, 21811429376 bytes
255 heads, 63 sectors/track, 2651 cylinders, 42600448 sectores en total
Units = sectores of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Identificador del disco: 0x00000000

El disco /dev/sdb no contiene una tabla de particiones válida

Tenemos por un lado el disco /dev/sda perteneciente al equipo que ha sido atacado y /dev/sdb que es el disco sobre el que vamos a volcar la imagen de /dev/sda. Como se puede observar, /dev/sdb no está formateado (es un disco nuevo) así que procedemos a particionarlo y formatearlo.
Para crear una partición usamos de nuevo fdisk.

root@forensix:~# fdisk /dev/sdb
El dispositivo no contiene una tabla de particiones DOS válida ni una etiqueta de disco Sun o SGI o OSF
Building a new DOS disklabel with disk identifier 0xa2b988b1.
Changes will remain in memory only, until you decide to write them.
After that, of course, the previous content won't be recoverable.

Atención: el indicador 0x0000 inválido de la tabla de particiones 4 se corregirá mediante w(rite)

Orden (m para obtener ayuda): n
Partition type:
   p   primary (0 primary, 0 extended, 4 free)
   e   extended
Select (default p): p
Número de partición (1-4, valor predeterminado 1): 1
Primer sector (2048-42600447, valor predeterminado 2048): 2048
Se está utilizando el valor predeterminado 2048
Last sector, +sectores or +size{K,M,G} (2048-42600447, valor predeterminado 42600447):  42600447
Se está utilizando el valor predeterminado 42600447

Orden (m para obtener ayuda): w
¡Se ha modificado la tabla de particiones!

Llamando a ioctl() para volver a leer la tabla de particiones.
Se están sincronizando los discos.

Finalmente, formateamos con el siguiente comando:

mkfs.ext4 /dev/sdb1

Montamos sobre el directorio /mnt el nuevo disco con el comando mount (es importante montar el disco de copia solamente y no el disco de la víctima, ya que al montarlo podríamos estar destruyendo pruebas).

mount -t auto /dev/sdb1 /mnt

Para crear la imagen del disco usamos el comando dd de la siguiente manera.

root@forensix:~# dd if=/dev/sda of=/mnt/victima.img
16777216+0 registros leídos
16777216+0 registros escritos
8589934592 bytes (8,6 GB) copiados, 125,385 s, 68,5 MB/s

Obtenemos la suma MD5 (hash) de la imagen para usarlo durante la cadena de custodia de la prueba. También obtenemos la suma md5 del disco de la víctima para poder compararla y verificar que coinciden.

root@forensix:~# md5sum /mnt/victima.img 
6b21bd09c7bd095f573a8205bf6c6f50  /mnt/victima.img
root@forensix:~# md5sum /dev/sda
6b21bd09c7bd095f573a8205bf6c6f50  /dev/sda

Repetimos la operación hasta obtener tres copias idénticas del disco. Es importante mantener bien la cadena de custodia de los discos junto con sus hashes MD5 de cara a que los discos sirvan de prueba ante un posible juicio.

De vuelta al laboratorio

Está empezando a anochecer y hace un poco de frío. Lo que menos me apetece es ir ahora al laboratorio, aunque mirándolo bien, al menos allí hay calefacción. Mientras Juan enchufa una de las copia a un ordenador y saco un par de cafés de la máquina. Creo que nos van a hacer falta.
Vamos a usar Autopsy (y por ende Sleuth Kit) para analizar lo que ha podido pasar, así que iniciamos un nuevo caso con la imagen del disco que hemos copiado.

Hay tres puntos de montaje. El primero es el disco completo en crudo (raw), el segundo es la primera partición, que es la que más nos interesa y, por último, la tercera se corresponde con la partición de swap, de la que llegado el caso, también podríamos obtener información útil.
Vamos a empezar seleccionando la primera partición (/1/) y pulsamos el botón analyze. En la siguiente pantalla seleccionamos el tipo de análisis File Analysis.
El primer sitio donde hay que mirar es en los logs del sistema, así que vamos a examinar el directorio /var/log en busca de información útil. Tras revisar algunos logs vemos que hay algo que nos llama la atención en /var/log/auth.log. Hay miles de líneas como las siguientes:

...
Jun  1 12:40:01 victima sshd[4078]: Failed password for pedro from 192.168.56.102 port 55092 ssh2
Jun  1 12:40:01 victima sshd[4079]: Failed password for pedro from 192.168.56.102 port 55093 ssh2
Jun  1 12:40:01 victima sshd[4080]: Failed password for pedro from 192.168.56.102 port 55101 ssh2
Jun  1 12:40:01 victima sshd[4071]: Failed password for pedro from 192.168.56.102 port 55008 ssh2
Jun  1 12:40:02 victima sshd[4068]: Failed password for pedro from 192.168.56.102 port 55005 ssh2
Jun  1 12:40:02 victima sshd[4067]: Failed password for pedro from 192.168.56.102 port 54997 ssh2
Jun  1 12:40:02 victima sshd[4077]: Failed password for pedro from 192.168.56.102 port 55084 ssh2
...

Son miles de intentos de acceso a la cuenta del usuario pedro mediante ssh. La dirección IP del atacante es 192.168.56.102. (obviamente, en un entorno real, esta no sería una dirección IP del rango local, sino una IP pública que se correspondería con un proveedor de acceso a internet).
Seguimos buscando en el log hasta que encontramos las dos líneas siguientes, que nos indican que el atacante finalmente ha tenido éxito y ha logrado entrar en el sistema como usuario pedro.

Jun  1 12:54:22 victima sshd[4967]: Accepted password for pedro from 192.168.56.102 port 42022 ssh2
Jun  1 12:54:22 victima sshd[4969]: (pam_unix) session opened for user pedro by (uid=0)

Esta información revela que el ataque ha sido por fuerza bruta o por diccionario. En todo caso, una contraseña débil ha permitido al atacante entrar en el sistema como usuario pedro.

Otro de los archivos de log que nos ha llamado la atención es /var/log/exim4/mainlog, que pertenece al servidor SMTP. Las líneas que despiertan nuestro interés son las siguientes:

2013-06-01 12:28:10 H=(terra.es) [192.168.56.102] F=<atacante@terra.es> rejected RCPT <psanchez@localhost>: Unrouteable address
2013-06-01 12:28:54 H=(terra.es) [192.168.56.102] F=<atacante@terra.es> rejected RCPT <pedro.sanchez@localhost>: Unrouteable address
2013-06-01 12:29:17 H=(terra.es) [192.168.56.102] F=<atacante@terra.es> rejected RCPT <pedrosan@localhost>: Unrouteable address

Son intentos de envío de correos a los usuarios psanchez, pedro.sanchez y pedrosan, que han sido rechazados por el servidor de correo ya que no existen en el sistema local. Coincide la IP y más o menos las horas, por lo que podemos estar seguros de que se trata del mismo atacante.
Llegamos a la conclusión de que posiblemente ha estado usando el servidor de correo para tratar de adivinar el nombre de algún usuario válido del sistema. La técnica es conocida y se trata de ir probando nombres de usuario hasta que uno de ellos sea aceptado por el servidor de correo como una dirección de correo válida.
Vamos a mirar en el directorio del usuario pedro para ver si encontramos algún archivo. Por suerte, Autopsy revela que hay tres archivos borrados en el directorio /home/pedro.

El primero es .viminfo.tmp, que es una archivo temporal del editor de textos vi. Es decir, sabemos que ha estado editando algún fichero.
Si accedemos al contenido de los inodos de este archivo, que ha sido eliminado, encontramos lo siguiente:

ASCII Contents of Fragment 1644552 in victima.img-63-16016804


# Este fichero viminfo fue generado por Vim 6.4.
# Usted puede editarlo, ..solo si tiene cuidado!

# Valor de ..encoding.. cuando se escribi.. este fichero
*encoding=utf-8


# hlsearch on (H) or off (h):
~H
# Historia de ..L..nea de ..rdenes.. (de lo m..s nuevo a lo m..s antiguo):
:wq
:q!

# Historia de ..Cadena de b..squeda.. (de lo m..s nuevo a lo m..s antiguo):

# Historia de ..Expresi..n.. (de lo m..s nuevo a lo m..s antiguo):

# Historia de ..L..nea de entrada.. (de lo m..s nuevo a lo m..s antiguo):

# Historia de ..L..nea de entrada.. (de lo m..s nuevo a lo m..s antiguo):

# Registros:
""- CHAR 0
 9

# Marcas en el fichero:
'0  16  8  /etc/passwd
'1  27  9  /etc/passwd

# Lista de saltos (el m..s reciente va primero):
-'  16  8  /etc/passwd
-'  1  0  /etc/passwd
-'  27  9  /etc/passwd

# Historia de las marcas en los ficheros (de la m..s reciente a la m..s antigua):

> /etc/passwd
 " 16 8
 ^ 16 9
 . 16 8
 + 25 11
 + 16 8

El archivo temporal de vi nos dice que se ha modificado el archivo /etc/password. Revisamos el directorio /etc y verificamos que, efectivamente, hay un archivo llamado passwd, otro llamado passwd- (que es una copia o backup del archivo, antes de haber sido modificado, creada por el editor vi) y, finalmente, otro archivo borrado llamado passwd~ que es otra copia antigua, por lo que deducimos que el atacante modificó el archivo más de una vez.

Como tenemos una copia del archivo antes de la modificación que ha hecho el editor vi, podemos compararlas. Nos llama la atención un cambio realizado sobre una de las líneas.
El contenido actual de la línea para el usuario irc es la siguiente:

irc:x:0:0:ircd:/var/run/ircd:/bin/sh

Sin embargo, en el backup vemos que antes tenía otros valores en los campos de UID (User ID) y GUID (Group ID).

irc:x:39:39:ircd:/var/run/ircd:/bin/sh

El atacante le ha asignado el UID 0 al usuario irc. El UID 0 representa al usuario root, así que para todos los efectos, el usuario irc es administrador de la máquina. Seguramente, el atacante, se ha asegurado de poder seguir accediendo como root mediante el usuario irc, aunque el usuario pedro cambie la contraseña y le cierren el paso.
Aun así, nos queda por saber cómo ha conseguido el atacante modificar el archivo /etc/password, ya que este archivo sólo lo puede editar root. Sabemos pues que ha conseguido acceso de superusuario, pero no cómo lo ha hecho.
La respuesta la encontramos en los otros dos archivos eliminados que hay en el directorio /home/pedro. Uno de ellos es un archivo de código fuente de C. Le echamos un vistazo y comprobamos que se trata de un exploit que explota una vulnerabilidad. Comprobamos que se trata de la vulnerabilidad conocida etiquetada como CVE-2009-2698, que tras una rápida búsqueda en google nos informa de que explota un bug en la función udp_sendmsg() de la implementación del protocolo UDP en versiones del kernel anteriores a la 2.6.19. Así pues ya sabemos cómo consiguió escalar privilegios hasta convertirse en administrador del servidor.
Nos queda cuestionarnos qué es lo que ha hecho el intruso en la máquina y cuál es el alcance del ataque. Examinamos el archivo /home/pedro/.bash_history, que contiene un histórico de los comandos que ha ejecutado. Desgraciadamente está vacío, por lo que deducimos que seguramente lo borró.

Seguimos indagando en los archivos borrados, pero no encontramos nada nuevo que arroje información importante.
De nuevo recurrimos a escudriñar los logs y en /var/log/exim4/mainlog encontramos información de un mail enviado por root.

2013-06-01 20:06:06 1UiqBq-00013S-QQ <= root@victima U=root P=local S=344

El contenido del mail suele almacenarse en /var/spool/mail, así que examinamos este directorio y encontramos un archivo llamado alberto (deducimos que el nombre real del usuario root de la máquina es alberto). El archivo efectivamente almacena el contenido del mail enviado.

------ This is a copy of the message, including all the headers. ------

Return-path: 
Received: from root by victima with local (Exim 4.60)
 (envelope-from )
 id 1Uiq09-00011p-3C; Sat, 01 Jun 2013 19:54:01 +0200
To: victima@terra.es
Subject: “Datos de clientes”
Message-Id: 
From: root 
Date: Sat, 01 Jun 2013 19:54:01 +0200

Clientes de la empresa
...

Hemos podido averiguar que la intención del atacante era obtener los datos de clientes de la empresa, ya que se los ha enviado por mail. Con toda esta información y tras la elaboración del informe, se presentará una denuncia y eventualmente, el juez ordenará investigar la dirección de correo a la que se envió la información.

Epílogo

La justicia en este país, por desgracia, es lenta, pero todo llega. Durante el juicio, al cual nos tocó a Juan y a mi ir a declarar, se condenó finalmente al intruso. Resulta que el correo al que se había enviado los datos no era suyo, pero durante la instrucción del caso, se había podido obtener, gracias al ISP, la dirección IP desde la que se accedió ese día a esa dirección de correo vía web, presumiblemente para descargar el listado de clientes. El intruso había usado un proxy anónimo para conectarse al servidor, pero no había guardado la misma precaución para descargarse el correo con los datos, así que se le había podido identificar.