Introducción al Hacking
Para empezar cuando se habla de hackear en general se habla de hackear maquinas con sistema operativo Unix. Aparte del Unix tambien 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ñias informaticas:
| AIX | Unix de IBM |
| SunOS | Unix de Sun |
| Solaris | Unix de Sun (mas 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 | Creo que no hace falta comentarlo |
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. |
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.
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.
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.
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.
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, BCrack, 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.
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:
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.
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.
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.
(Cuando pongo dos directorios significa que el fichero puede estar en cualquiera de esos dos directorios).
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
Guarda un log cada vez que un usuario se introduce en el sistema o sale del sistema.
Directorios: /var/adm/wtmp /etc/wtmp
Guarda un log del momento exacto en que un usuario entró por última vez.
Directorio: /var/adm/lastlog
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
Permite saber quién está conectado al sistema en el momento en que ejecutamos el comando.
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.
Igual que el who
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.
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.
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.
Activa un proceso llamado accounting, que es el que proporciona información al fichero acct.
Permite saber qué comandos han ejecutado los usuarios.
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.
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:
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.
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.
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 stá tratado desde un punto de vista personal. En hacking, como en casi ualquier actividad, cada maestrillo tiene su librillo. Sólo pretendo dar nos consejos prácticos y desde luego no recomiendo que se sigan al pie de a letra. Cada uno puede tener en cuenta estos consejos como base pero lo ejor es que cada uno desarrolle su propio método y su propia forma de hacer as cosas.
Puede que muchos hackers (la gran mayoría mucho mejores que yo) que lean esto o estén de acuerdo con estos consejos o incluso los consideren nocivos para a práctica del hacking. Sólo puedo repetir que se trata de mi punto de vista 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.
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.
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:
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.
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.
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:
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. Aunque 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.
Documento creado por: SHE - Sindicato de Hackers Españoles