
Ä Los documentos de IBERHACK  ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ http://www.geocities.com/SiliconValley/Park/7574ÄÄÄ
 Fecha: 13 Sep 96          
    De: Wendigo <SHE - Sindicato de Hackers Espa¤oles ->                                                        
  Para: Todos                                                                  
  Tema: Introduccion al hacking.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ


Aqui os dejo las famosas Hack Intros de Wendigo!!!

--------------------------------Cut Here-------------------------------------

Bueno, pues eso, que como alguien me ha pedido que expliquemos un poco de
qu‚ va el hacking pues yo me lanzo. Voy a empezar a explicarlo a nivel MUY
elemental y desde un punto de vista pr ctico, si alguien quiere m s detalles
te¢ricos que lo diga, el cliente siempre tiene la raz¢n. :-))))))

Otra cosa, si alguien cree que este tipo de mensajes son un co¤azo, que me
lo diga sin rodeos. :-)

Muy bien, para empezar cuando se habla de hackear EN GENERAL se habla de
hackear m quinas con sistema operativo Unix. Aparte del Unix tambi‚n existen
otros sistemas operativos para mainframes y miniordenadores como el VMS
para ordenadores VAX (de la marca DEC --> Digital Equipment Corporation),
el VM/CMS, VM/ESA, etc para ordenadores IBM, y otros sistemas operativos de
menor profileraci¢n.

Incluso los sistemas Unix se pueden clasificar en varios tipos, como el BSD,
el SYSTEM V y el POSIX, as¡ como varios sistemas desarrollados por las
diferentes compa¤¡as inform ticas:

AIX --> Unix de IBM
SunOS --> Unix de Sun
Solaris --> Unix de Sun (m s avanzado que el SunOS)
HP-UX --> Unix de Hewlett Packard
Ultrix --> Unix de DEC para plataformas VAX
OSF/1 --> Unix de DEC para plataformas ALPHA
ConvexOS --> Unix de Convex
Unicos --> Unix de Cray
Linux --> Sin comentarios. :-)

Esta subdivisi¢n de los sistemas Unix tiene m s importancia de la que parece
a primera vista, porque un bug o fallo de seguridad que funcione en uno de
los sistemas puede que no funcione en los dem s, por lo que es importante
saber en todo momento cual es el sistema en el que nos estamos moviendo.

De la misma forma, Internet no es la £nica red en la cual se puede hackear,
tambi‚n hay varias redes de X.25 que cuentan con gran n£mero de ordenadores
como Sprintnet (la antigua Telenet), Tymnet o la misma Iberpac.

Aqu¡ cuando hablemos de hackear estaremos hablando de hackear sistemas Unix
en Internet preferentemente, ya que Internet est  basada en los protocolos
TCP/IP los cuales est n mejor estudiados en cuanto a seguridad y por tanto
existen m s fuentes de informaci¢n de donde se pueden conocer sus fallos de
seguridad de las que existen para las redes X.25.

A la hora de hackear un sistema se pueden distinguir varios pasos
diferenciados.

1 - Introducirse en el sistema que tengamos como objetivo.

2 - Una vez conseguido el acceso, conseguir privilegios de root (administrador
    del sistema).

3 - Borrar nuestras huellas.

4 - Poner un sniffer (programa que monitoriza la red consiguiendo logins y
    passwords) para tener acceso a otros sistemas.

NOTA: Voy a hacer un peque¤o resumen de cada paso, lo que voy a decir est 
      basado en la generalidad pero no hay que tomarlo como dogma.



PASO UNO: Introducirse en el sistema.

Los fallos de seguridad que se aprovechan para conseguir introducirse en el
sistema est n basados casi siempre en los protocolos TCP/IP, en servicios
de red como el NFS o NIS o en los comandos "r" de Unix.

TCP/IP --> TCP = Transport Control Protocol
           IP  = Internet Protocol

           Los protocolos basados en TCP/IP que se suelen aprovechar son
           Telnet, FTP, TFTP, SMTP, HTTP, etc. Cada uno de ellos tiene sus
           propios agujeros de seguridad que se van parcheando con nuevas
           versiones de estos protocolos, pero siempre aparecen nuevos bugs.
           Explicar cada uno de los protocolos TCP/IP puede llevarnos mucho
           tiempo, as¡ que paso a otra cosa.

Servicios de red --> NFS = Network File System, es un servicio de red por el
                     cual varias m quinas llamadas clientes comparten uno o
                     varios directorios que se encuentran fisicamente en una
                     m quina llamada servidor. Una m quina cliente, a pesar
                     de no poseer fisicamente dichos directorios, puede
                     montarlos de tal forma que puede acceder a ellos como
                     si los poseyera. Otra cosa muy distinta es lo que se
                     pueda hacer con los ficheros incluidos en dichos
                     directorios (si se pueden borrar, modificar, alterar los
                     permisos, etc), lo cual depende de la configuraci¢n del
                     NFS.
                     En la mala configuraci¢n del NFS es donde estriban
                     siempre sus fallos de seguridad.

                     NIS = Network Information Service, es un servicio
                     por el cual varias m quinas comparten varios "mapas".
                     Los mapas son ficheros como passwd, hosts, etc.
                     Por ejemplo, un usuario puede entrar con la misma
                     cuenta en todas las m quinas que compartan un mismo
                     mapa de passwords. Los mapas son consultados por las
                     m quinas clientes a las m quinas que contengan los
                     mapas, que son los servidores.
                     Existe un programa llamado YPX que sirve para extraer
                     estos mapas (inclu¡do el fichero passwd, donde est n
                     inclu¡das todas las passwords de los usuarios) de un
                     servidor de NIS aunque la m quina en la que estemos no
                     sea una m quina cliente.

Comandos "r" --> Son comandos exclusivos del sistema operativo Unix. La "r"
                 es de remote. En el sistema hay un fichero llamado host.equiv
                 y cada usuario suele tener en su directorio home (el
                 directorio reservado a cada usuario para su propio uso
                 del sistema) un fichero llamado .rhosts. Dependiendo de la
                 configuraci¢n de estos dos ficheros se podr  o no acceder
                 a dicho ordenador desde otro sistema unix sin necesidad de
                 password con los comandos rlogin o rsh.

Aparte de estas formas b sicas, existen otras formas m s avanzadas de acceder
a un sistema como el IP Spoofing, fallos de seguridad en el Web y el Java,
recompilando librer¡as del telnet, UUCP, etc.

Hay dos formas b sicas de introducirse en el sistema:

1 - Entrar directamente sin necesidad de poseer una cuenta en el sistema
    objetivo.
    Por ejemplo por comandos "r" o por alg£n bug (alterar el fichero passwd
    del ordenador objetivo por rsh, alterar el fichero .rhosts de alg£n
    usuario por NFS, etc...desde luego hay formas m s avanzadas de conseguir
    esto).

2 - Conseguir el fichero passwd del sistema objetivo y crackearlo.
    El fichero passwd contiene los logins de los usuarios y su correspondiente
    password encriptadas (entre otras cosas). Para averiguar el password de
    cada usuario se utiliza un programa crackeador (existen varios, para
    unix el m s famoso es el Crack, para MS-DOS est n el JackCrack, Hades,
    Crack, etc) que encripta cada palabra de un diccionario y las compara
    con la cadena encriptada del fichero passwd, cuando las cadenas
    encriptadas coinciden entonces la palabra del diccionario que el programa
    ha encriptado en ese momento es el password buscado.


 PASO DOS: Conseguir privilegios de root una vez conseguido el acceso.

 En este caso, los fallos de seguridad que explotaremos ser n los del
 propio sistema operativo Unix, a diferencia de cuando ten¡amos que
 introducirnos en el sistema, que explot bamos los agujeros de seguridad
 de los protocolos o servicios de red.

 NOTA: De todas formas, hay que tener en cuenta que aunque explotemos los
       bugs de los protocolos TCP/IP, esto no significa que estos bugs nos
       vayan a funcionar con cualquier sistema operativo. M s bien al
       contrario, estos bugs funcionan casi exclusivamente en el sistema
       operativo Unix pero en otros sistemas operativos como VMS o VM no
       funcionar n. Estos sistemas operativos tendr n sus propios bugs
       respecto a los protocolos TCP/IP (de los cuales existe muy poca
       informaci¢n por no decir ninguna).

 Una vez introducidos en el sistema, habr  que conseguir dos cosas:

 1 - Conseguir privilegios de root.

     Esto se puede conseguir mediante varios bugs dependiendo del tipo de
     unix en el que nos estemos moviendo (aix, sun, solaris, hp-ux, etc...)
     y de c¢mo est‚ configurado dicho sistema.

     Existen varias fuentes de informaci¢n en Internet para conocer bugs,
     algunas de esas fuentes se limitan a indicar la existencia del bug
     se¤alando el tipo de unix en el que funciona y otras incluso publican en
     la red programas para explotarlos. Entre dichas fuentes de informaci¢n
     (mailing lists la mayor¡a) est n el CERT, BUGTRAQ, BoS,
     comp.security.unix, alt.2600 y un largo etc.

     En general los bugs se pueden clasificar en varias categor¡as, pero
     eso en todo caso lo mencionar‚ m s adelante, por ahora esto es un
     peque¤o resumen.

 2 - Mantener los privilegios de root.

     Existen diversas formas de mantener los privilegios de root, es decir,
     asegurarnos de que la pr¢xima vez que entremos al sistema con la cuenta
     de un usuario que posea privilegios normales, podamos conseguir
     privilegios de root de forma f cil y sin complicaciones.

     Quiz  la forma m s utilizada de conseguir esto sea el sushi (set-uid-
     shell) o tambi‚n llamado "huevo".
     Consiste en que una vez alcanzados los privilegios de root, copiamos
     un shell (el fichero /bin/sh) a un directorio p£blico (en el que un
     usuario normal pueda ejecutar los ficheros) y le cambiamos el nombre
     al que nosotros queramos. Nos aseguramos de que el shell copiado tenga
     como owner (propietario del fichero) al root y cambiamos los permisos
     del fichero con las cifras 4755. Por ahora no os preocupeis de lo que
     significan dichas cifras, pero la primera cifra, el 4, significa que
     CUALQUIER usuario que ejecute dicho fichero lo estar  ejecutando con
     los privilegios del owner. Como en este caso el owner es el root y el
     fichero en cuesti¢n es una shell, el sistema nos abrir  un shell con
     privilegios de root.

     De esta forma, la pr¢xima vez que accedamos al sistema con la cuenta
     de un usuario normal, s¢lo tendremos que cambiarnos al directorio donde
     hayamos copiado el shell, ejecutarlo y ya seremos root sin las
     complicaciones de tener que explotar un bug.

     Los sushis tambi‚n tienen sus inconvenientes, ya que pueden ser
     f cilmente localizados por los administradores (mediante el comando
     find, por ejemplo) revelando nuestra presencia en el sistema. Para
     evitar esto hay otras formas de mantener los privilegios en el
     sistema o de modificar ligeramente los sushis para que no puedan ser
     detectados tan f cilmente.


 PASO TRES: Borrar nuestras huellas.

 Este paso es importante, ya que de nada nos habr  servido habernos
 introducido en el sistema y haber conseguido el nivel de root si al d¡a
 siguiente nos han cortado el acceso debido a que hemos dejado huellas por
 todas partes.

 El sistema operativo Unix guarda varios registros (logs) de las conexiones
 de los usuarios al sistema. Existen varios ficheros y comandos que ayudan
 al administrador a conocer todos los detalles acerca de las conexiones de
 los usuarios. Aparte de estos ficheros y comandos, existen diversas
 facilidades y aplicaciones que realizan un registro continuado y exhaustivo
 acerca de las actividades del usuario dentro del sistema.

 Ficheros: (Cuando pongo dos directorios significa que el fichero puede estar
           en cualquiera de esos dos directorios).

 utmp --> Guarda un registro (log) de los usuarios que est n utilizando el
          sistema mientras est n conectados a ‚l.

          Directorios: /var/adm/utmp
                       /etc/utmp

 wtmp --> Guarda un log cada vez que un usuario se introduce en el sistema
          o sale del sistema.

          Directorios: /var/adm/wtmp
                       /etc/wtmp

 lastlog --> Guarda un log del momento exacto en que un usuario entr¢ por
             £ltima vez.

             Directorio: /var/adm/lastlog

 acct --> Registra todos los comandos ejecutados por cada usuario (aunque no
          registra los argumentos con que dichos comandos fueron ejecutados).

          Directorio: /var/adm/acct

          En algunos sistemas el fichero acct se puede llamar pacct
 Comandos:

 who --> Permite saber qui‚n est  conectado al sistema en el momento en que
         ejecutamos el comando.

 finger --> Lo mismo que el comando who, con el a¤adido de que se puede
            aplicar a otras m quinas. Es decir, podemos saber qu‚ usuarios
            est n conectados a una determinada m quina en el momento en que
            ejecutamos el comando.

 users --> Igual que el who

 rusers --> Igual que finger, pero la m quina remota debe utilizar el sistema
            operativo Unix.

 Los comandos who, finger, users y rusers toman la informaci¢n que sacan en
 pantalla del fichero utmp.

 last --> Permite saber cuando fu‚ la £ltima vez que se conect¢ un
          usuario.

 El comando last toma la informaci¢n que saca en pantalla del fichero wtmp.

 ps --> Permite saber qu‚ procesos est n siendo ejecutados por el sistema y
        que usuarios los ejecutan.

 El comando ps ofrece una informaci¢n mucho m s completa de qui‚n est 
 utilizando el sistema puesto que un usuario que no aparezca en los ficheros
 utmp o wtmp puede tener procesos ejecut ndose, por lo que el comando ps
 ofrecer  la informaci¢n de qui‚n est  ejecutando dichos procesos. En
 contrapartida, la informaci¢n que ofrece el comando ps es m s complicada de
 interpretar que la informaci¢n ofrecida por el resto de comandos.

 accton --> Activa un proceso llamado accounting, que es el que proporciona
            informaci¢n al fichero acct.

 lastcomm --> Permite saber qu‚ comandos han ejecutado los usuarios.

 acctcom --> Igual que lastcomm pero exclusivamente para Unix del tipo
             SYSTEM V.

 Los comandos lastcomm y acctcom toman la informaci¢n que sacan por pantalla
 del fichero acct (pacct en algunos sistemas)

 Por lo tanto, si queremos borrar nuestras huellas del sistema, bastar  con
 borrar cualquier log relativo a nuestro usuario de los ficheros utmp, wtmp y
 acct. Esto se puede hacer de dos formas:

 Ficheros utmp y wtmp:

 1 - No borramos los ficheros pero los dejamos con cero bytes. S¢lo se
     utiliza como £ltimo recurso por suscitar muchas sospechas por parte
     de los administradores. Hay hackers que opinan que esto es incluso
     peor que no borrar los logs.

 2 - Los ficheros utmp y wtmp no son ficheros de texto, es decir, no se
     pueden editar con un editor de textos. Sin embargo, existen programas
     llamados zappers (debido a que el programa m s famoso de este tipo se
     llama zap) que pueden borrar los datos relativos a un usuario en
     particular de estos ficheros dejando el resto de los datos relativo a
     los dem s usuarios intacto.

 Fichero acct:

 Cuando el accounting est  activado (es decir, cuando el sistema recoge
 informaci¢n acerca de los comandos ejecutados en el fichero acct) es
 bastante complicado borrar nuestras huellas, de hecho no se pueden borrar
 del todo, aunque s¡ se pueden reducir a una m¡nima informaci¢n de nuestra
 presencia en el sistema.

 1 - LO PRIMERO que hacemos nada m s entrar en el sistema es copiar el
     fichero acct a otro fichero y LO ULTIMO que hacemos antes de abandonar
     el sistema es copiar dicho fichero de nuevo al acct, de modo que los
     comandos que hemos ejecutado durante la sesi¢n no aparecen en el
     fichero acct.

     Problema: Nuestra entrada en el sistema queda registrada, as¡ como las
               dos copias.

 2 - Dejamos el fichero acct a cero bytes. Como antes, esto es bastante
     sospechoso para un administrador, adem s, algunos sistemas reaccionan
     mal y paran el proceso de accounting, para no levantar sospechas habr¡a
     que reactivarlo con el comando accton.

     Problema: Bastante sospechoso. El propio comando accton quedar¡a
               registrado como ejecutado por nuestro usuario.

 3 - Hacerse un editor para el fichero acct que borrara los datos
     correspondientes a nuestro usuario y dejara intactos los datos relativos
     al resto de los usuarios. Existen unos pocos programas que hacen esto.

     Problema: La ejecuci¢n del programa editor que borra nuestras huellas
               quedar¡a registrado como ejecutado por nuestro usuario.

 Afortunadamente, no hay muchos sistemas que tengan activado el accounting
 debido a la cantidad de capacidad que es necesaria para guardar los
 comandos ejecutados por cada usuario.


 Aparte de los ficheros utmp, wtmp, acct y lastlog, hay que tener en cuenta
 otras facilidades y aplicaciones que posee el sistema operativo Unix que
 permiten al administrador vigilar ciertos aspectos cr¡ticos relativos a la
 seguridad y al mantenimiento del sistema.

 1 - Syslog

     Syslog es una aplicaci¢n que viene con el sistema operativo Unix.
     El sistema operativo Unix se puede configurar de tal forma que
     determinados programas, procesos o aplicaciones generen mensajes que son
     enviados a determinados ficheros donde quedan registrados dichos
     mensajes. Estos mensajes son generados cuando se dan unas determinadas
     condiciones, ya sean condiciones relativas a seguridad, mantenimiento
     o simplemente de tipo puramente informativo.

     Para conseguir esto hay que configurar varias cosas.

     A - Decidir qu‚ programas, procesos y aplicaciones pueden generar
         mensajes. (Pongo los principales)

         kern --> mensajes relativos al kernel
         user --> mensajes relativos a procesos ejecutados por usuarios
                  normales.
         mail --> mensajes relativos al sistema de correo.
         lpr -->  mensajes relativos a impresoras.
         auth --> mensajes relativos a programas y procesos de autentificaci¢n
                  (aquellos en los que est‚n involucrados nombres de usuarios
                  y passwords, por ejemplo login, su, getty, etc)
         daemon --> mensajes relativos a otros demonios del sistema.

         etc...

     B - Decidir qu‚ tipos de mensajes pueden generar cada uno de esos
         programas, procesos o aplicaciones.

         emerg --> emergencias graves.
         alert --> problemas que deben ser solucionados con urgencia.
         crit --> errores cr¡ticos.
         err --> errores ordinarios.
         warning --> avisos.
         notice --> cuando se da una condici¢n que no constituye un error pero
                    a la que se le debe dar una cierta atenci¢n.
         info --> mensajes informativos.

         etc...

     C - Decidir a qu‚ ficheros van a para dichos mensajes dependiendo del
         tipo al que pertenezca el mensaje correspondiente.


     Syslog cumple su funci¢n mediante el syslogd (syslog daemon o en
     castellano el demonio syslog).

     NOTA: un demonio (o daemon) es un proceso que no tiene propietario (es
           decir, no es ejecutado por ning£n usuario en particular) y que
           se est  ejecutando permanentemente.

     El syslogd lee su configuraci¢n del fichero /etc/syslog.conf
     Dicho fichero contiene la configuraci¢n relativa a qu‚ eventos del
     sistema son registrados y en qu‚ ficheros son registrados. Los
     ficheros a los cuales se mandan los registros (logs) pueden estar
     situados en la misma m quina en la que estamos trabajando o en otra
     m quina de la red.


     C¢mo borrar las huellas relativas al syslog:

     Bien, nuestras andanzas por el sistema cuando hemos accedido a ‚l y
     cuando nos hemos convertido en root, pueden generar diversos mensajes
     registrados por el syslogd y guardados en los ficheros indicados en el
     /etc/syslog.conf

     A diferencia de los ficheros utmp, wtmp, acct y lastlog, los ficheros
     en los que se guardan los registros del syslog s¡ se pueden editar con
     un editor de textos.

     Para poder borrar estas huellas necesitamos tener privilegios de root,
     naturalmente. Bastar  con examinar el fichero /etc/syslog.conf para
     saber los ficheros que guardan los registros del syslog. Despu‚s
     miraremos cada uno de esos ficheros comprobando que no hay ning£n mensaje
     relativo a nuestra intrusi¢n en el sistema (los mensajes del estilo
     "login: Root LOGIN REFUSED on ttya" a ciertas horas de la noche son
     bastante sospechosos :-) ). En caso de que lo haya, lo borramos y
     CAMBIAMOS LA FECHA del fichero con el comando touch de forma que
     coincida la fecha del £ltimo mensaje (despu‚s de haber borrado nuestras
     huellas) con la fecha del fichero. Si no lo hacemos as¡, alg£n
     administrador demasiado suspicaz puede comprobar que las fechas no
     coinciden y deducir que alguien ha modificado el fichero (esta es una
     precauci¢n extrema pero la recomiendo por experiencia). Si es necesario,
     y SOLO si es necesario, habr¡a que cambiar la fecha de los directorios
     en los que est‚n inclu¡dos los ficheros que guardan los logs.

     Si en el fichero /etc/syslog.conf hay mensajes que se destinan a
     /dev/console eso significa que los mensajes (ya sean de error, alerta
     o emergencia) salen directamente en la pantalla del root (o sea, en la
     consola). En este caso no se puede hacer nada (que yo sepa), pero
     mensajes de este tipo suelen estar generados por alertas bastante
     graves como por ejemplo intentar acceder con la cuenta de root
     directamente o utilizar el comando su para intentar convertirse en root,
     etc. Es decir, cuanto m s sigilosos seamos a la hora de hacernos root
     y menos ruido armemos m s posibilidades tendremos de no aparecer en este
     tipo de logs.

 2 - TCP-Wrapper

     Se trata de una aplicaci¢n que proporciona una serie de mecanismos
     para el registro (logging) y filtro (filtering) de aquellos servicios
     invocados o llamados a trav‚s del inetd (internet daemon). Con esta
     herramienta el administrador posee un control absoluto de las
     conexiones hacia y desde su m quina.

     Puede, entre otras muchas cosas, filtrar un servicio de internet como
     por ejemplo el telnet, ftp, etc de forma que nadie pueda conectarse
     al sistema desde otra m quina o puede especificar una lista de m quinas
     que s¡ pueden conectarse (y las dem s no podr n). Adem s, el
     administrador es informado en todo momento y con todo lujo de detalles
     de las conexiones que se han hecho desde su m quina y hacia su m quina
     con cualquiera de los diferentes servicios de internet (telnet, ftp,
     finger, etc...)

     Como en el syslog, para borrar nuestras huellas del tcp-wrapper, tendremos
     que buscar posibles huellas mirando el archivo de configuraci¢n (alojado
     NORMALMENTE en el directorio /etc), borrar dichas huellas y cambiar las
     fechas de los ficheros correspondientes.

 Bien, hasta aqu¡ un resumen sobre c¢mo borrar las huellas. Como vereis me
 he extendido un poco m s porque me parece importante que la gente adquiera
 conciencia de que tan importante o m s que controlar el sistema (convertirse
 en root) es saber ocultarse en ‚l (aunque es una opini¢n personal).

 Puede parecer bastante pesado el borrar todas las posibles huellas que
 hayamos dejado, pero en ALGUNAS ocasiones, una vez que hayamos visto los
 ficheros de configuraci¢n es posible preparar un shell script (el equivalente
 a los ficheros batch en MS-DOS, aunque la programaci¢n en shell es
 infinitamente m s potente :-) ) que haga todo el trabajo por nosotros en
 cuesti¢n de borrar las huellas. Dicho script lo podemos dejar bien camuflado
 en el sistema para que la pr¢xima vez que entremos lo podamos ejecutar
 (utilizando como par metros el usuario con el que hayamos entrado, el
 terminal por el que hayamos entrado, la hora a la que hayamos entrado, etc..)
 ahorr ndonos todo el trabajo pesado.

 Para terminar con lo de borrar las huellas, s¢lo advertir que aunque seamos
 perfectamente invisibles en el sistema, cualquier usuario que est‚ conectado
 al mismo tiempo que nosotros podr¡a detectarnos viendo el terminal por el
 que hemos entrado (el fichero /dev/ correspondiente a nuestro terminal
 tendr¡a como propietario (owner) al usuario con el que hemos entrado en el
 sistema, y la fecha del fichero /dev/ correspondiente al terminal tambi‚n
 nos delatar¡a). Para evitar esto tendr¡amos que cambiar de owner el fichero
 correspondiente al terminal (teniendo privilegios de root naturalmente)
 al owner que tengan los otros terminales a los cuales no hay nadie
 conectado (es decir, al owner de los terminales por defecto que NORMALMENTE
 es el root).

 De todas formas, esto £ltimo, junto con lo de cambiar de fecha ciertos
 ficheros de logs, son medidas quiz  extremas, pero vuelvo a insistir que
 son muy recomendables.

 Por £ltimo, la cuesti¢n de ocultar o camuflar procesos mientras los estamos
 ejecutando es otra cuesti¢n que se tratar  en otro mensaje si teneis la
 paciencia de seguir. :-)


 Ya hemos visto de forma resumida y sin detallar algunas t‚cnicas sobre c¢mo
 conseguir acceso, conseguir privilegios y borrar nuestras huellas. Vamos a
 ver el £ltimo paso, c¢mo conseguir acceso a otros ordenadores una vez
 controlado el host que hayamos hackeado (es decir, despu‚s de asegurarnos
 que hemos borrado absolutamente todas nuestras huellas y de implantar
 alg£n sushi u otro m‚todo an logo para conseguir privilegios de root).

 Una vez controlado el host que ten¡amos como objetivo, podemos hacer todo
 lo que queramos en el sistema, aunque hay que tener en cuenta que nuestras
 acciones pueden ser registradas por el syslog, tcp-wrapper u otra utilidad
 que genere logs, por lo que cuando vayamos a irnos del sistema siempre
 tendremos que comprobar antes que no hemos dejado registros (logs).

 Es en este punto donde adquiere importancia la "filosof¡a" del hacker. La
 diferencia entre un hacker y un cracker (no me estoy refiriendo a alguien
 que rompe las protecciones de software), consiste en que un cracker accede al
 sistema para da¤arlo o corromperlo y un hacker accede al sistema simplemente
 para conseguir informaci¢n o por pura curiosidad, pero nunca corromper  ni
 borrar  ning£n fichero del sistema, sigue el lema (aunque tampoco de forma
 radical, es decir, sin tom rselo al pie de la letra) de "se ve pero no se
 toca". A esto £ltimo hay que hacer una excepci¢n , naturalmente. Los £nicos
 ficheros que el hacker modificar  o borrar  ser n los ficheros relativos a
 los logs que haya podido dejar en el sistema. Por supuesto que esto es una
 situaci¢n ideal y no realista, en la pr ctica un hacker puede que realize
 otras acciones en el sistema que puedan modificar ficheros ya existentes,
 pero siempre procurar  que los cambios sean m¡nimos.


 PASO CUATRO:

 Bien, para conseguir acceso a otros sistemas desde el host que hemos hackeado
 existen varias t‚cnicas. La m s sencilla y la primera que se suele probar es
 consultando los ficheros .rhosts de los usuarios e intentando acceder a los
 sistemas inclu¡dos en dichos ficheros mediante rlogin o rsh. Tambi‚n se
 puede intentar acceder a otros sistemas de la red con los comandos "r"
 aunque no est‚n inclu¡dos en los ficheros .rhosts o en el fichero host.equiv.

 Hay varias formas m s o menos sofisticadas que nos permitan conseguir
 informaci¢n desde el sistema en el que nos encontramos y que nos permita
 acceder a otros sistemas de la red. Quiz  el m‚todo m s famoso y m s
 eficiente sea la colocaci¢n de un sniffer.
 Un sniffer es un programa que "monitoriza" la red consultando los diferentes
 paquetes de informaci¢n que circulan por ella. Cuando alguno de esos paquetes
 cumple ciertos requisitos (por ejemplo que sea un paquete correspondiente a
 un proceso de login), guarda dicho paquete en un fichero (es decir, guarda
 un log). Cada cierto tiempo el hacker puede consultar dicho fichero que le
 proporciona informaci¢n sobre qu‚ usuario se conect¢ a una determinada
 m quina, a qu‚ m quina se conect¢ y que password utiliz¢, adem s de otros
 datos.

 C¢mo funciona un sniffer:

 La red Internet es un conjunto de subredes comunicadas entre s¡ mediante
 m quinas llamadas gateways, bridges o routers. Cada subred, a su vez, puede
 estar dividida en varias subredes y sucesivamente. Lo m s usual es que las
 m quinas est‚n organizadas en una red de tipo ethernet, y que dicha red est‚
 conectada a Internet (o a una subred de Internet) mediante sus
 corrrespondientes routers o gateways (no tiene porqu‚ ser s¢lo un router
 o gateway, una misma red puede tener varios para comunicarse con el
 exterior), que ser n las m quinas que mantengan a dicha red ethernet en
 contacto con el resto de la red.

 Las redes ethernet trabajan mandando los paquetes de informaci¢n por un
 mismo canal compartido por todas las m quinas. En la cabecera de cada
 paquete de informaci¢n est  inclu¡da la direcci¢n de la m quina a la cual va
 destinado el paquete de informaci¢n. Se supone que el paquete de informaci¢n
 s¢lo lo recibe la m quina a la cual va destinado. Las m quinas que reciben
 cualquier paquete de informaci¢n aunque no est‚n destinados a ella, se dice
 que est n en modo promiscuo.

 De esta forma, un hacker puede poner en modo promiscuo la m quina (si es que
 no lo est  ya en el momento de hackearla) y capturar TODOS los paquetes que
 circulan por la red, aunque no provengan de su m quina y aunque no est‚n
 destinados a su m quina. Normalmente se suelen capturar paquetes que cumplan
 alg£n requisito como aquellos que incluyan el momento de acceso de un usuario
 a una m quina. Teniendo en cuenta que el login y el password del usuario se
 mandan en modo texto, el hacker puede leer con toda comodidad en el fichero
 registro que genera el sniffer qu‚ password utiliza el usuario y en qu‚
 m quina lo utiliza.

 Tambi‚n se puede sniffar informaci¢n aunque el sistema no est‚ en modo
 promiscuo, pero entonces la m quina s¢lo aceptar  informaci¢n que est‚
 destinada a ella, y los £nicos paquetes de informaci¢n que monitorizar  el
 sistema ser n los paquetes destinados a ‚l, y los paquetes que provengan del
 propio sistema.

 Existen varios programas sniffers por la red, incluso algunos comerciales.
 Los m s conocidos y distribuidos en circulos underground son sniffers para
 SunOS, Solaris y Linux. Por otra parte, programas bien conocidos como
 Etherfind o Tcpdump se pueden utilizar estupendamente como sniffers, aunque
 no hayan sido concebidos para esos fines.

 Para comprobar si un sistema est  en modo promiscuo se utiliza el comando
 ifconfig -a, aunque en algunos sistemas como el OSF/1 o el IRIX (el Unix
 de Silicon Graphics) hay que especificar el interface (dispositivo mediante
 el cual el sistema intercambia informaci¢n con la red ethernet). Para
 ver los interfaces se puede utilizar el comando netstat -r.

 Para terminar, s¢lo advertir que los logs, es decir, los ficheros que utiliza
 el sniffer para guardar la informaci¢n, suelen crecer muy deprisa por lo que
 si no se tiene cuidado pueden hacerse excesivamente granden y alertar al
 administrador del sistema que al examinar los ficheros se dar  cuenta de que
 existe un hacker en su sistema. Por eso es recomendable consultar los logs
 cada POCO tiempo y dejar los ficheros a cero.


Bien, ante todo quiero advertir que el tema que voy a tratar a continuaci¢n 
est  tratado desde un punto de vista personal. En hacking, como en casi
cualquier actividad, cada maestrillo tiene su librillo. S¢lo pretendo dar 
unos consejos pr cticos y desde luego NO recomiendo que se sigan al pie de
la letra. Cada uno puede tener en cuenta estos consejos como base pero lo 
mejor es que cada uno desarrolle su propio m‚todo y su propia forma de hacer
las cosas.

Puede que muchos hackers (la gran mayor¡a mucho mejores que yo) que lean esto
no est‚n de acuerdo con estos consejos o incluso los consideren nocivos para
la pr ctica del hacking. S¢lo puedo repetir que se trata de MI punto de vista
y de MI opini¢n, y repetir que nadie se tome estas t‚cnicas como dogma, sino
que cada uno las ponga en pr ctica y despu‚s juzgue por s¡ mismo si vale la
pena utilizarlas o no.


RECOPILACION DE INFORMACION:

Bien, antes de intentar lanzarnos a hackear alg£n ordenador de la red conviene
hacer algunos preparativos. Estos preparativos a los que me refiero constan 
simplemente de una peque¤a recopilaci¢n de informaci¢n, tanto informaci¢n
general como informaci¢n del ordenador que nos hayamos marcado como objetivo.


1 - Informaci¢n general:

    Cuando menciono informaci¢n general me estoy refiriendo a la recopilaci¢n
    de bugs y programas que nos ayuden a hackear.

    Los bugs o fallos de seguridad y los programas que nos ayudan a 
    explotarlos (aprovechar dichos fallos de seguridad) pueden conseguirse 
    de varias formas:

             I - Mailing-lists de Internet:
                 
                     BoS --> Best of Security
                     Bugtraq
                     Comp.Security.Unix
                     Alt.2600
                     Linux.Security.Alert

                     etc.....


             II - FTPs o WEBs "oficiales":

                     El m s famoso es ftp.cert.org, pero existen una infinidad
                     de ellos, basta con buscar mediante cualquier Search 
                     Engine del WWW cualquier materia relacionada con la 
                     seguridad.

    En los mensajes del CERT o de las distintas listas de correo los bugs no
    se describen de manera directa. Es decir, no os dir n los pasos que teneis 
    que dar para aprovechar los fallos de seguridad, sino que lo £nico que 
    mencionar n ser  el sistema operativo al cual afecta el bug (SunOS, AIX,
    Solaris, HP-UX, Ultrix, OSF/1, Irix, etc...), cual es el resultado de
    aprovechar el bug (convertirse en root, poner los permisos que queramos
    a un determinado fichero, estrellar el ordenador....) y los parches que
    hay que aplicar al sistema para que dicho bug no pueda ser aprovechado en 
    el futuro.

    Existen unas cuantas excepciones, los llamados EXPLOITS. Son mensajes
    "oficiales" que muestran los pasos que hay que dar para aprovechar un 
    determinado fallo de seguridad, e incluyen los programas necesarios
    para hacerlo.
    
             III - FTPs, FSPs o WEBs "no oficiales":
             
                     Hay varios repartidos por Internet. Descubrirlos forma
                     parte de las labores del hacker. En los que son 
                     demasiado conocidos habr  cosas muy antiguas o que ya no
                     funcionan.

                     Es en estos sites (se llama site o host a un ordenador 
                     cualquiera de Internet) donde se consiguen las mejores
                     utilidades y programas que nos permitan explotar varios
                     bugs as¡ como varias t‚cnicas b sicas de hacking.
                     
    Un buen hacker debe ser organizado. Organizar los bugs seg£n un cierto
    criterio es fundamental a la hora de hackear un ordenador. He visto 
    gente que clasifica los bugs en distintos directorios seg£n varios
    criterios. Algunos los clasifican seg£n la fecha. Es decir, almacenan en
    un directorio los del 93, en otro los bugs aparecidos en el 94, en otro
    los del 95, etc. Otras personas, entre las que me incluyo, los organizan
    en distintos directorios seg£n los sistemas operativos a los que afecten
    o los protocolos de Internet a los que afecten. Es decir, yo tengo 
    recopilados en un directorio todos los bugs que funcionan en SunOS (todos 
    los que tengo yo, se entiende, no todos los que existen :-) ), en otro 
    todos los que funcionan en Solaris, en otro los que funcionan en HP-UX, 
    en otro los que se aprovechan fallos del sendmail, en otro los bugs
    generales que puedan funcionar en varios sistemas, en otro directorio
    los programas que me permitan borrar mis huellas, etc.

    A la hora de hackear un ordenador lo primero ser  averiguar el sistema
    operativo que utiliza, su versi¢n de sendmail, y otras cosas que explicar‚
    despu‚s. El tener organizados los bugs o los EXPLOITS as¡ como otros 
    programas de utilidad (zappers para borrar las huellas o sniffers para
    conseguir cuentas) en directorios bien diferenciados nos permitir  ahorrar
    mucho tiempo a la hora de hackear y lo m s importante (lo digo por
    experiencia), nos evitar  hacernos lios y nos ayudar  a decidirnos sobre
    qu‚ bugs intentar explotar en dicho sistema. 
    

             IV - Zines o revistas electr¢nicas:

                  Las revistas o documentos electr¢nicos son llamados
                  zines. En algunas de estas revistas o documentos est n
                  explicadas varias t‚cnicas b sicas de hacking as¡ como
                  lecciones de Unix orientadas a los hackers. Hay muchas
                  revistas de este estilo y muy buenas:

                       FAQ de 2600
                       Phrack
                       LOD Technical Journal
                       Cotno
                       Infohax

                       etc....

2 - Informaci¢n del ordenador objetivo:

    Antes de intentar hackear un ordenador normalmente se recopilan una
    serie de datos que nos ayuden a decidirnos sobre qu‚ t‚cnica de hacking
    podemos utilizar.

    Se puede conseguir informaci¢n muy variada de un determinado host 
    (ordenador), pero quiz  lo fundamental sea intentar hallar los 
    siguientes datos:

    - Su direcci¢n IP y su direcci¢n de dominio.

      C¢mo se consigue --> Si tenemos el host marcado como objetivo se 
                           suponen conocidas. Si s¢lo conocemos la direcci¢n
                           de dominio para hallar la direcci¢n IP basta
                           utilizar el comando "nslookup <direcci¢n.dominio>"

    - Tipo de sistema operativo Unix que utiliza  -->**MUY IMPORTANTE**<--

      C¢mo se consigue --> Haciendo telnet <host>

    - Versi¢n de Sendmail que utiliza 

      C¢mo se consigue --> Haciendo telnet <host> 25
                           Es decir, hacemos un telnet a la m quina pero al
                           puerto 25. Una vez conectados para salir basta  
                           utilizar QUIT o para obtener ayuda HELP.
                    
    - Si soporta RPC y en caso afirmativo averiguar qu‚ servicios RPC tiene.
    
      C¢mo se consigue --> Utilizando el comando "rpcinfo -p <host>"

    - Si exporta directorios. Es decir, si tiene NFS, y en caso afirmativo,
      averiguar qu‚ directorios exporta y a qui‚n los exporta. 
      
      C¢mo se consigue --> Utilizando el comando "showmount -e <host>"

    - Averiguar qu‚ otras m quinas hay en ese mismo dominio, y que sistema 
      operativo utilizan esas otras m quinas.

      C¢mo se consigue --> Utilizando el comando "nslookup". Cuando salga el
                           prompt del nslookup (un s¡mbolo > ) se utiliza
                           el comando "ls -d <dominio>" para obtener 
                           informaci¢n del dominio.
                           
    Con estos datos ya podemos intentar algunas t‚cnicas de hacking, en las 
    cuales profundizaremos en pr¢ximos mensajes. :-)

Por £ltimo algunos consejos importantes (repito: son consejos basados
en mi experiencia, que cada uno desarrolle sus propios recursos):

1 - En el caso de que consigais alguna cuenta para acceder al ordenador quiz 
    una vez hayais entrado no sepais muy bien c¢mo reaccionar, es decir, no
    sepais qu‚ hacer a continuaci¢n. Es en este momento donde toma importancia
    la organizaci¢n que mencion‚ antes. 

    En ning£n momento os pongais nerviosos o intenteis cosas a loco. Si veis
    que perdeis la calma lo mejor es apartarse de la pantalla diez o quince
    minutos, relajarse, y despu‚s intentar hallar un camino para conseguir
    privilegios.

    Para intentar conseguir privilegios de root es fundamental ante todo que
    hagais una distinci¢n de los bugs que podeis intentar explotar y aquellos
    que no debeis intentar explotar (debido a que si son bugs de otro sistema
    operativo Unix distinto al que estamos hackeando no servir n de nada),
    por eso os aconsej‚ la distribuci¢n en directorios de los bugs seg£n el
    sistema o protocolo al que afecten. Esa organizaci¢n os evitar  p‚rdidas
    de tiempo (con lo que aumenta la impaciencia del hacker :-) ) y os
    ayudar  a decidir las t‚cnicas de hacking que debeis intentar de las que
    no debeis intentar.

    A la hora de intentar explotar alg£n bug relativo al sistema que estemos
    hackeando tambi‚n es importante tener los exploits bien organizados y
    convenientemente editados (muchas veces los exploits vienen mezclados 
    en mensajes de texto) para que lo £nico que tengamos que hacer sea 
    subirlos por FTP al sistema y ejecutarlos (y compilarlos si no fueran 
    shell scripts).

2 - En caso de que no os funcione ning£n bug en el sistema de los que teneis,
    ante todo mucha calma. :-)

    Importante: En este caso lo que debemos buscar es dejar las menos huellas
                posibles en el sistema. Las huellas que habeis dejado hasta 
                el momento no podreis borrarlas as¡ que por mucho que os 
                preocupeis por ellas no podreis hacer nada, s¢lo esperar que
                el administrador no se d‚ cuenta de vuestras intrusiones
                (tanto en el utmp, wtmp o los logs del syslog). No intenteis
                cosas a lo loco como explotar bugs que funcionan en otros
                sistemas porque lo £nico que conseguireis ser  dejar m s
                huellas y perder el tiempo.

    Lo que s¡ podeis hacer es intentar explotar bugs que afecten a los 
    sistemas Unix en general (hay algunos) o bugs que afecten a alguno de
    los protocolos TCP/IP. Si siguen sin funcionar ninguno dedicaos a 
    explorar el sistema (hasta donde os permitan vuestros privilegios)
    para tener una visi¢n general de c¢mo est  protegido el sistema (por
    ejemplo viendo si los usuarios tienen ficheros .rhosts, si determinados
    ficheros tienen permisos set-uid, que propietario tienen determinados
    ficheros, etc...), y a partir de ah¡ teneis dos opciones PRINCIPALES (es
    decir, que puede haber m s opciones pero yo siempre utilizo una de estas 
    dos):

     I - Olvidarse durante un par de d¡as del sistema que intentamos hackear
         y aprender todo lo que podamos sobre el sistema operativo Unix que 
         utiliza esa m quina, ya sea buscando bugs m s modernos que sirvan 
         para la versi¢n del sistema que intentamos hackear como examinando 
         FAQs, documentos o p ginas html que traten sobre dicho sistema en
         general y su seguridad en particular, etc...

     II - Hackear otra m quina del mismo dominio y que sea m s f cil de 
          hackear, es decir, que sea mucho m s insegura (hay sistemas m s
          "f ciles" o "inseguros" que otros debido a que se conocen m s bugs
          sobre ellos. Seguramente el SunOS 4.1.x sea el sistema del que se
          conocen m s bugs). Este m‚todo suele ser el m s utilizado cuando
          una m quina se nos resiste debido a que existen m s recursos
          al hackear una m quina (con t‚cnicas que permiten conseguir
          privilegios de root A LA VEZ que conseguimos entrar en dicha
          m quina) desde una m quina de su mismo dominio que desde una m quina
          que no pertenezca a su dominio.

3 - Cuando no conseguimos acceder a un ordenador que pretendemos hackear el  
    recurso que m s se suele utilizar es el que hemos comentado antes. Se 
    trata de hackear otra m quina del mismo domino que sea m s insegura y
    desde esa m quina hackear la m quina que nos hemos puesto por objetivo.

      I - La forma m s sencilla es poner un sniffer en la m quina insegura
          que hemos hackeado esperando conseguir una cuenta de la m quina
          objetivo que pretendemos hackear. 

      II - Como he dicho antes, existen muchos m s recursos para hackear una
           m quina desde otra m quina de su mismo dominio de los que se pueden
           utilizar al tratar de hackearla desde una m quina que no es de su
           dominio. Por ejemplo aprovechando los ficheros .rhosts mediante 
           los comandos rlogin o rsh, comprobando si la m quina objetivo
           exporta directorios a la m quina que hemos hackeado, etc...

Para terminar un par de consejos para determinadas situaciones que se aprende
a resolverlas a base de pr ctica, pr ctica y m s pr ctica. Podeis leer un
mont¢n de documentos sobre hacking como este pero si quereis aprender a 
hackear de verdad lo mejor es la pr ctica y ponerse manos a la obra cuanto
antes, y que vosotros seais vuestros propios profesores.

4 - Nunca os de miedo de intentar hacer cosas dentro del sistema (mientras
    tengan alg£n sentido claro, como he dicho antes, no hay que hacer las
    cosas a lo loco). No penseis que os van a pillar y que os van a cerrar el
    acceso. Si os pillan y os cierran el acceso mala suerte, eso forma parte
    del aprendizaje del hacker, os vais a hackear otro sistema y se acab¢ 
    (incluso puede ser otro sistema del mismo dominio), pero siempre teneis
    que experimentar, intentar las cosas por vosotros mismos, no os limiteis
    a leerlas en un papel. Os descubrir n muchas veces y os cerrar n el acceso
    otras tantas veces, pero cada vez ireis espabilando y lo ireis haciendo
    mejor. Errores que cometisteis una o dos veces, m s adelante no los
    volvereis a cometer. En definitiva: aunque os d‚ angustia el que os 
    cierren el acceso a alg£n ordenador al que ya habiais conseguido entrar,
    no os d‚ miedo explorar el sistema y experimentar.

5 - Muchas veces intentareis compilar un programa para explotar alg£n bug y 
    os dar  errores cuando se supone que deb¡a compilar correctamente. 
    Debuggar los programas tambi‚n forma parte de las labores del hacker. 
    Con la pr ctica aprendereis a reconocer porqu‚ tal o cual c¢digo fuente 
    no compila correctamente.


--------------------------------Cut Here-------------------------------------
