913 lines
46 KiB
Plaintext
913 lines
46 KiB
Plaintext
|
||
Ä 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-------------------------------------
|