Muy bien, para empezar cuando se habla de hackear EN GENERAL se habla de
hackear maquinas con sistema operativo Unix. Aparte del Unix tambi‚n existen
otros sistemas operativos para mainframes y minicomputadoras como el VMS
para computadoras VAX (de la marca DEC --> Digital Equipment Corporation),
el VM/CMS, VM/ESA, etc para computadoras IBM, y otros sistemas operativos de
menor profileracion.Incluso los sistemas Unix se pueden clasificar en varios tipos, como el BSD,
el SYSTEM V y el POSIX, asi como varios sistemas desarrollados por las
diferentes compañias informaticas: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 subdivision 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 unica red en la cual se puede hackear,
tambi‚n hay varias redes de X.25 que cuentan con gran numero de computadoras
como Sprintnet (la antigua Telenet), Tymnet o la misma Iberpac.
Aqui 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 informacion 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, asi 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 configuracion del
NFS.
En la mala configuracion 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 (incluido el fichero passwd, donde est n
incluidas 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
configuracion de estos dos ficheros se podr o no acceder
a dicho computadora 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 librerias 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 algun bug (alterar el fichero passwd
del computador objetivo por rsh, alterar el fichero .rhosts de algun
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 teniamos 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
informacion 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 como est‚ configurado dicho sistema.
Existen varias fuentes de informacion 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 informacion
(mailing lists la mayoria) est n el CERT, BUGTRAQ, BoS,
comp.security.unix, alt.2600 y un largo etc.
En general los bugs se pueden clasificar en varias categorias, 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 proxima 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 publico (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 note preocupes 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 cuestion es una shell, el sistema nos abrir un shell con
privilegios de root.
De esta forma, la proxima vez que accedamos al sistema con la cuenta
de un usuario normal, solo 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 dia
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 entro por
ultima 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 informacion que sacan en
pantalla del fichero utmp.
last --> Permite saber cuando fu‚ la ultima vez que se conecto un
usuario.
El comando last toma la informacion 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 informacion 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 informacion de qui‚n est ejecutando dichos procesos. En
contrapartida, la informacion que ofrece el comando ps es m s complicada de
interpretar que la informacion ofrecida por el resto de comandos.
accton --> Activa un proceso llamado accounting, que es el que proporciona
informacion 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 informacion 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. Solo se
utiliza como ultimo 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
informacion acerca de los comandos ejecutados en el fichero acct) es
bastante complicado borrar nuestras huellas, de hecho no se pueden borrar
del todo, aunque si se pueden reducir a una minima informacion 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 sesion no aparecen en el
fichero acct.
Problema: Nuestra entrada en el sistema queda registrada, asi 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 habria
que reactivarlo con el comando accton.
Problema: Bastante sospechoso. El propio comando accton quedaria
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 ejecucion del programa editor que borra nuestras huellas
quedaria 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 criticos relativos a la
seguridad y al mantenimiento del sistema.
1 - Syslog
Syslog es una aplicacion 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 autentificacion
(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 criticos.
err --> errores ordinarios.
warning --> avisos.
notice --> cuando se da una condicion que no constituye un error pero
a la que se le debe dar una cierta atencion.
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 funcion 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 ningun usuario en particular) y que
se est ejecutando permanentemente.
El syslogd lee su configuracion del fichero /etc/syslog.conf
Dicho fichero contiene la configuracion 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.
Como 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 si 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 ningun mensaje
relativo a nuestra intrusion 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 ultimo mensaje (despu‚s de haber borrado nuestras
huellas) con la fecha del fichero. Si no lo hacemos asi, algun
administrador demasiado suspicaz puede comprobar que las fechas no
coinciden y deducir que alguien ha modificado el fichero (esta es una
precaucion extrema pero la recomiendo por experiencia). Si es necesario,
y SOLO si es necesario, habria que cambiar la fecha de los directorios
en los que est‚n incluidos 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 aplicacion 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 si 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 configuracion (alojado
NORMALMENTE en el directorio /etc), borrar dichas huellas y cambiar las
fechas de los ficheros correspondientes.
Bien, hasta aqui un resumen sobre como borrar las huellas. Como veras 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 opinion 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 configuracion es posible preparar un shell script (el equivalente
a los ficheros batch en MS-DOS, aunque la programacion en shell es
infinitamente m s potente :-) ) que haga todo el trabajo por nosotros en
cuestion de borrar las huellas. Dicho script lo podemos dejar bien camuflado
en el sistema para que la proxima 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, solo advertir que aunque seamos
perfectamente invisibles en el sistema, cualquier usuario que est‚ conectado
al mismo tiempo que nosotros podria detectarnos viendo el terminal por el
que hemos entrado (el fichero /dev/ correspondiente a nuestro terminal
tendria 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 delataria). Para evitar esto tendriamos 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 ultimo, junto con lo de cambiar de fecha ciertos
ficheros de logs, son medidas quiz extremas, pero vuelvo a insistir que
son muy recomendables.
Por ultimo, la cuestion de ocultar o camuflar procesos mientras los estamos
ejecutando es otra cuestion que se tratar en otro mensaje si tenes la
paciencia de seguir. :-)
Ya hemos visto de forma resumida y sin detallar algunas t‚cnicas sobre como
conseguir acceso, conseguir privilegios y borrar nuestras huellas. Vamos a
ver el ultimo paso, como conseguir acceso a otros computadoras una vez
controlado el host que hayamos hackeado (es decir, despu‚s de asegurarnos
que hemos borrado absolutamente todas nuestras huellas y de implantar
algun sushi u otro m‚todo an logo para conseguir privilegios de root).
Una vez controlado el host que teniamos 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 "filosofia" 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 informacion o por pura curiosidad, pero nunca corromper ni
borrar ningun 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 ultimo hay que hacer una excepcion , naturalmente. Los unicos
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
situacion 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 minimos.
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 incluidos 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 incluidos en los ficheros .rhosts o en el fichero host.equiv.
Hay varias formas m s o menos sofisticadas que nos permitan conseguir
informacion 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 colocacion de un sniffer.
Un sniffer es un programa que "monitoriza" la red consultando los diferentes
paquetes de informacion 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 informacion sobre qu‚ usuario se conecto a una determinada
m quina, a qu‚ m quina se conecto y que password utilizo, adem s de otros
datos.
Como funciona un sniffer:
La red Internet es un conjunto de subredes comunicadas entre si 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 solo 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 informacion por un
mismo canal compartido por todas las m quinas. En la cabecera de cada
paquete de informacion est incluida la direccion de la m quina a la cual va
destinado el paquete de informacion. Se supone que el paquete de informacion
solo lo recibe la m quina a la cual va destinado. Las m quinas que reciben
cualquier paquete de informacion 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
algun 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 informacion aunque el sistema no est‚ en modo
promiscuo, pero entonces la m quina solo aceptar informacion que est‚
destinada a ella, y los unicos paquetes de informacion 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 informacion con la red ethernet). Para
ver los interfaces se puede utilizar el comando netstat -r.
Para terminar, solo advertir que los logs, es decir, los ficheros que utiliza
el sniffer para guardar la informacion, 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 continuacion
est tratado desde un punto de vista personal. En hacking, como en casi
cualquier actividad, cada maestrillo tiene su librillo. Solo 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 mayoria 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. Solo puedo repetir que se trata de MI punto de vista
y de MI opinion, 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 si mismo si vale la
pena utilizarlas o no.
RECOPILACION DE INFORMACION:
Bien, antes de intentar lanzarnos a hackear algun computador de la red conviene
hacer algunos preparativos. Estos preparativos a los que me refiero constan
simplemente de una pequeña recopilacion de informacion, tanto informacion
general como informacion del computador que nos hayamos marcado como objetivo.
1 - Informacion general:
Cuando menciono informacion general me estoy refiriendo a la recopilacion
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, note dir n los pasos que tenes
que dar para aprovechar los fallos de seguridad, sino que lo unico 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 computador....) 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 computador
cualquiera de Internet) donde se consiguen las mejores
utilidades y programas que nos permitan explotar varios
bugs asi como varias t‚cnicas b sicas de hacking.
Un buen hacker debe ser organizado. Organizar los bugs segun un cierto
criterio es fundamental a la hora de hackear un computador. He visto
gente que clasifica los bugs en distintos directorios segun varios
criterios. Algunos los clasifican segun 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 segun 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 computador lo primero ser averiguar el sistema
operativo que utiliza, su version de sendmail, y otras cosas que explicar‚
despu‚s. El tener organizados los bugs o los EXPLOITS asi 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.
2 - Informacion del computador objetivo:
Antes de intentar hackear un computador normalmente se recopilan una
serie de datos que nos ayuden a decidirnos sobre qu‚ t‚cnica de hacking
podemos utilizar.
Se puede conseguir informacion muy variada de un determinado host
(computador), pero quiz lo fundamental sea intentar hallar los
siguientes datos:
- Su direccion IP y su direccion de dominio.
Como se consigue --> Si tenemos el host marcado como objetivo se
suponen conocidas. Si solo conocemos la direccion
de dominio para hallar la direccion IP basta
utilizar el comando "nslookup <direccion.dominio>"
- Tipo de sistema operativo Unix que utiliza -->**MUY IMPORTANTE**<--
Como se consigue --> Haciendo telnet <host>
- Version de Sendmail que utiliza
Como 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.
Como 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.
Como 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.
Como se consigue --> Utilizando el comando "nslookup". Cuando salga el
prompt del nslookup (un simbolo > ) se utiliza
el comando "ls -d <dominio>" para obtener
informacion del dominio.
Con estos datos ya podemos intentar algunas t‚cnicas de hacking, en las
cuales profundizaremos en proximos mensajes. :-)
Por ultimo algunos consejos importantes (repito: son consejos basados
en mi experiencia, que cada uno desarrolle sus propios recursos):
1 - En el caso de que consigas alguna cuenta para acceder al computador quiz
una vez hayas entrado no sepas muy bien como reaccionar, es decir, no
sepas qu‚ hacer a continuacion. Es en este momento donde toma importancia
la organizacion que mencion‚ antes.
En ningun momentote pongas nerviosos o intentes cosas a loco. Si ves
que perdes 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
hagas una distincion de los bugs que podes intentar explotar y aquellos
que no debes intentar explotar (debido a que si son bugs de otro sistema
operativo Unix distinto al que estamos hackeando no servir n de nada),
por esote aconsej‚ la distribucion en directorios de los bugs segun el
sistema o protocolo al que afecten. Esa organizacionte evitar p‚rdidas
de tiempo (con lo que aumenta la impaciencia del hacker :-) ) yte
ayudar a decidir las t‚cnicas de hacking que debes intentar de las que
no debes intentar.
A la hora de intentar explotar algun 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 unico que tengamos que hacer sea
subirlos por FTP al sistema y ejecutarlos (y compilarlos si no fueran
shell scripts).
2 - En caso de que note funcione ningun bug en el sistema de los que tenes,
ante todo mucha calma. :-)
Importante: En este caso lo que debemos buscar es dejar las menos huellas
posibles en el sistema. Las huellas que habras dejado hasta
el momento no podras borrarlas asi que por mucho quete
preocups por ellas no podras hacer nada, solo esperar que
el administrador no se d‚ cuenta de vuestras intrusiones
(tanto en el utmp, wtmp o los logs del syslog). No intentes
cosas a lo loco como explotar bugs que funcionan en otros
sistemas porque lo unico que conseguiras ser dejar m s
huellas y perder el tiempo.
Lo que si podes 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 dondete permitan tus privilegios)
para tener una vision general de como 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 ahi tenes 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 dias 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 version 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 computador 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 practica, practica y mas practica. Podes leer un
monton de documentos sobre hacking como este pero si queres aprender a
hackear de verdad lo mejor es la pr ctica y ponerse manos a la obra cuanto
antes, y que vos seas tus propios profesores.
4 - Nunca te de miedo de intentar hacer cosas dentro del sistema (mientras
tengan algun sentido claro, como he dicho antes, no hay que hacer las
cosas a lo loco). No penses que te van a cazarr y que te van a cerrar el
acceso. Si te cazarn y te cierran el acceso mala suerte, eso forma parte
del aprendizaje del hacker, te vas a hackear otro sistema y se acabo
(incluso puede ser otro sistema del mismo dominio), pero siempre tenes
que experimentar, intentar las cosas por vos mismos, no te limites
a leerlas en un papel.vos descubrir n muchas veces y te van a cerrar n el acceso
otras tantas veces, pero cada vez ires espabilando y lo ires haciendo
mejor. Errores que cometistes una o dos veces, m s adelante no los
volveras a cometer. En definitiva: aunque te d‚ angustia el que te
cierren el acceso a algun computador al que ya habias conseguido entrar,
no te d‚ miedo explorar el sistema y experimentar.
5 - Muchas veces intentaras compilar un programa para explotar algun bug y
te van a dar errores cuando se supone que debia compilar correctamente.
Debuggar los programas tambi‚n forma parte de las labores del hacker.
Con la pr ctica aprenderas a reconocer porqu‚ tal o cual codigo fuente
no compila correctamente.
Esta es una guia basica del Hacking,hay muchas metodologias,y se requiere de un fuerte respaldo en conocimientos.
Ok? asi es como trabaja un hacker y como se mueve,ahora ya sabes por encima mas o menos proteger tu sistema.Si,lo se,tiene muchisimos errores de ortografia,perdon por eso,no pude terminar con todo. En La proxima
revista continuaremos con este tema para ir profundizando cada vez mas.
Me comprometo a respoder cualquiera de tus dudas y guiarte por el camino que elijas seguir,estoy a tu disposicion,manda tu e-mail.
