Aula Macedonia


Breve Introducción al Mundo del Hacking


Artículo realizado por
Pedro Ferrera "BaDBoY"





Capítulo 5
Ocultarse en un sistema. Seguir hackeando en otros sistemas.

En esta unidad aprenderéis:




Si estáis aquí se supone que sabéis:

El sistema de logs de UNIX

Antes que nada, ¿ Qué es un log ? Un log es un fichero encargado de registrar cualquier tipo de actividad informática. Existen logs para todo tipo de actividad: logs que registran conversaciones en IRC, logs que registran las acciones de un jugador en un juego... Y por supuesto, logs que registran las actividades de cualquier usuario en un sistema. Antes he comentado que cuando entramos en un sistema UNIX, todo lo que hacemos queda registrado en logs. Eso tiene su parte de verdad, aunque muchas veces no es siempre así, y eso lo veremos más adelante.

Un hacker tiene que aprender a modificar adecuadamente cada log para asegurarse que no va a ser descubierto por el admin del sistema. Existen muchos tipos de logs diferentes que pueden estar o no activados en un sistema UNIX. Ciertos logs están vinculados a daemons (procesos que se ejecutan constantemente).

Los logs más importantes son:

Log/s Daemon o Proceso asociado

ACCT ACCT (ACCOUNTING) No es un daemon

SYSLOG SYSLOGD (SYSLOG DAEMON)

TCP-WRAPPER INETD (INTERNET DAEMON)

UTMP, WTMP y LASTLOG

1- ACCT

Acct proviene de la palabra Accounting. El log Acct solo funciona si el proceso de Accounting está activado. Este proceso se puede ejecutar mediante el comando Accton. El fichero puede encontrarse generalmente en el directorio /var/adm/.

Lo que hace el Accounting es registrar todos los comandos que ejecuta cualquier usuario dentro del sistema, sin exclusión alguna. Esto genera unos logs muy grandes especialmente si el sistema recibe muchas conexiones diarias, por eso este proceso no está siempre activado. Generalmente, lo que hacen los admins es activar otros logs para vigilar lo que hacen los usuarios con ciertos programas como SU, CU, etc.

Si el proceso de Accounting está activado, es muy dificil no dejar ninguna huella en el sistema, por estos motivos:

- Podemos parar el proceso de Accounting en el momento en el que entamos al sistema, pero el fichero Acct registraría el comando que para dicho proceso. Es una alternativa bastante tonta.

- Podemos borrar el fichero Acct. Una alternativa muy estúpida ya que el admin no tardaría en darse cuenta al querer echarle una ojeada a dicho fichero y el sistema generaría muy probablemente mensajes críticos que alertarían al admin.

- Podemos dejar el fichero a 0 bytes. Esto supone muchos problemas:

1 - El admin tendría que tragarse que nadie ha entrado en el sistema desde que activó el Accounting, por supuesto esto es muy sospechoso.

2 - Si queremos que el admin se crea esto, tenemos que modificar todos los logs relativos a las incursiones en el sistema de forma que todo coincida.

3 - Algunos sistemas pararían el proceso de accounting, con lo que tendríamos que volver a activarlo. Sin embargo, el comando accton quedaría registrado en el fichero.

- Podemos hacer una copia del fichero Acct en el momento en el que entramos a un fichero temporal, y antes de salir sobreescribir el fichero Acct con ese fichero temporal, de manera que todo lo que hemos hecho en ese intervalo no queda registrado. Lo que sí queda registrado es la copia del fichero.

- La mejor solución es buscar un programa que borre todos los datos nuestros en el fichero Acct sin alterar el resto. Como este fichero no es editable, hay que tener un programa especial para poder hacer esto. Sin embargo, la ejecución del programa quedaría registrada.

Algunas notas finales sobre ACCT

- En algunos sistemas ACCT puede llamarse PACCT

- Podemos sacar la información de ACCT en pantalla con el comando LASTCOMM (ACCTCOM en sistemas SYSTEM V)

- En algunos sistemas puedes encontrar un fichero llamado LOGINLOG que registra todos los logins que se hacen al sistema. Este fichero puede encontrarse en estos directorios:

/usr/adm/

/usr/adm/acct/

 

2 - SYSLOG

El Syslog es algo más complejo. Se trata de una aplicación que viene en muchos sistemas UNIX y que funciona gracias a syslogd (Syslog Daemon). El admin puede decidir qué es lo que le interesa vigilar en su sistema. Syslog hace que ciertos programas, aplicaciones, daemons, procesos... generen ciertos mensajes si se dan unas determinadas condiciones. Estos programas, procesos, etc, pueden generar mensajes relativos a:

- el kernel (núcleo del sistema)

- procesos ejecutados por usuarios ordinarios

- procesos de autentificación (login/password)

- procesos relativos al sistema de mail

Entre otros...

A la vez, los mensajes que generen estos procesos pueden ser, según el tipo de información que transmitan, de:

- Notice: No ha sucedido ningún error pero el admin tiene que prestar cierta atención a este evento.

- Err: Errores ordinarios.

- Crit: Errores críticos.

- Alert: Esto ya es un problema más serio, debe solucionarse con urgencia.

- Emerg: Emergencias graves.

Hay, por supuesto, más tipos, pero estos son los más importantes en cuanto a seguridad.

Los mensajes generados van a parar a ciertos ficheros, que no son predeterminados y que cada admin puede decidir a dónde direccionarlos según el tipo de mensaje (los hay que los direccionan todos a un solo fichero). Generalmente los mensajes de errores son destinados a un fichero llamado ERRLOG.

Los ficheros a donde van los mensajes están en Syslog.conf, situado generalmente en el directorio /etc/. Este fichero contiene toda la información de Syslog: qué procesos, daemons, aplicaciones... generan mensajes, si el mensaje es de X tipo a qué fichero se envía...

Y así es básicamente cómo funciona el Syslog. Así que lo que se debe hacer es saber en todo momento qué ficheros en esa máquina guardan mensajes Syslog, modificarlos (son editables), volver a poner la fecha con el comando touch, y listo.

Puede ser que algunos mensajes (generalmente, los de emergencia/alerta) vayan directamente a la consola del admin, es decir, que aparecen directamente en la pantalla del admin del sistema. Esto lo sabemos si en Syslog.conf se hace referencia a /dev/console. En este caso podemos hacer muchas artimañas pero como con el fichero ACCT es casi imposible evitar que lleguen esos mensajes.

Es mejor no romperse el coco e intentar no generar mensajes muy críticos.

3 - TCP-WRAPPER

El TCP-WRAPPER es una herramienta parecida al Syslog, pero vinculada a servicios exclusivos del internet daemon (ftp, telnet, mail...). Además de registrar toda actividad referente a la autentificación de cualquiera de estos servicios es capaz de filtrarlos, restringiéndolos de manera que sólo ciertos usuarios puedan conectarse, por ejemplo a través de un firewall.

Para borrar nuestras huellas del TCP-WRAPPER tenemos que seguir el mismo proceso que con el Syslog (buscar el fichero de configuración, modificar los ficheros vinculados...).

Más acerca del Internet Daemon

Inetd (Internet Daemon) tiene su fichero de configuración generalmente en el directorio /etc/, y el fichero en cuestión se llama inetd.conf.

Dentro de este fichero podemos observar unas líneas de este tipo:

1 2 3 4 5 6 7

ftp stream tcp nowait root /usr/etc/ftpd ftpd

Como podemos ver, cada linea tiene siete campos:

1 - El primer campo es el nombre del daemon de cada servicio asociado al Internet Daemon, y estos servicios se suelen encontrar en /etc/services

2 - El segundo campo es el tipo de conexión que utiliza cada servicio. Para protocolos TCP, el tipo es stream, y para protocolos UDP, el tipo es dgram (Datagram).

3 - El tercer campo es el tipo de protocolo del servicio, TCP o UDP.

4 - El cuarto campo indica cómo actuará este servicio al recibir una conexión. Si en este campo aparece "wait", la conexión será reiterativa, y si es "no wait", la conexión será concurrente.

5 - El quinto campo indica el nivel con el que se ejecuta el daemon, en este caso nivel de superusuario.

6 - El sexto campo indica la ruta completa del programa que se ejecuta cada vez que se recibe una conexión.

7 - El último campo es el nombre de dicho programa.

Algunos campos se pueden omitir.

El fichero /etc/services tiene una síntaxis más simple:

1 2 3 4

smtp 25/tcp mail

Sólo aparecen cuatro campos:

1 - El primero es el servicio, en este caso SMTP

2 - El segundo campo es el puerto

3 - El tercer campo es el tipo de protocolo que utiliza

4 - El cuarto es el nombre más asociado a este servicio

Sabiendo esto podemos crear un backdoor muy potente. Creamos un servicio que coincida en los dos archivos (inetd.conf y services) de manera que podamos entrar directamente como root siempre que nos dé la gana.

Editamos inetd.conf y añadimos:

badboy stream tcp nowait /bin/sh sh -i

Editamos services y añadimos:

badboy 22/tcp badboy

Ahora sólo tenemos que reiniciar el Internet Daemon para que vuelva a leer el archivo de configuraciones. Una manera de hacerlo es "matándolo". La manera de hacer esto varía en cada sistema, pero generalmente es "kill -9 <ruta>", aunque también puede ser "kill -HUP <ruta>", y la ruta es donde está situado el fichero PID que en este caso sería inetd.pid

Este backdoor funcionará hasta que el admin edite estos archivos. Pero sabed que estos archivos no son los que más suelen mirar los admins.

4 - UTMP, WTMP Y LASTLOG

Por último, estos tres ficheros. Los tres guardan registros referentes a los usuarios que entran y salen del sistema, con la IP, el login, la fecha y la hora... El UTMP permite que cualquier usuario sepa que estamos dentro del sistema con el comando who. Eso quiere decir que sólo registra nuestra información mientras estamos dentro del sistema.

Es muy peligroso dejarse la IP en un sistema en el que hayamos hackeado ya que si hemos hecho algo ilegal pueden encontrarnos y nos puede caer un buen puro.

Simplemente tenemos que localizar estos ficheros y editarlos con un zapper o un programa similar (ya que no se pueden ver con un editor de texto). Borrarlos puede generar mensajes críticos en el syslog y dejarlos a 0 bytes puede ser muy sospechoso. Por último, los directorios donde se suelen encontrar (aunque yo recomiendo hacer un find para encontrarlos) son:

UTMP:

/var/adm/

/etc/

WTMP:

/var/adm/

etc/

LASTLOG:

var/adm/

Por último...

Como el tema de los logs es algo muy importante, aseguraros de que haceis las cosas bien y coherentemente. Me refiero a que el orden en que modificais los logs es también muy importante. Por ejemplo:

- Modifico el ACCT

- Edito UTMP, WTMP y LASTLOG

- Echo un vistazo a SYSLOG y a TCP-WRAPPER

- Salgo tan tranquilo

Todo lo que se ha hecho en este caso ha resultado inútil porque ha quedado todo registrado otra vez en ACCT. Si el Accounting está activado, lo último que debemos hacer siempre es algo para borrar nuestras huellas de ACCT (aunque ya hemos discutido que es muy difícil hacerlo). Un orden coherente sería:

- Echo un vistazo a UTMP, WTMP y LASTLOG

- Voy a por SYSLOG y TCP-WRAPPER

- Hago algo con ACCT

- Y salgo

Y lo más importante: Todos los ficheros que modifiqueis tienen que volver a tener la misma fecha que tenían antes de editarlos (comando touch), y en esto he insistido mucho porque considero que es importante.

Otra cosa: si no habeis encontrado cierto fichero de log, no digais: "Bueno, no debe estar activo". Intentad encontrarlo por todos los medios, por ejemplo con el comando find. A veces están muy escondidos.

Y aún más importante: una vez hayais localizado todos los logs de este sistema, haced un shellscript que haga todo el trabajo solo, de manera que cuando entreis y tengais que salir solo teneis que darle al programa y ya estarán todos los logs modificados.

Seguir hackeando en otros sistemas

Una vez estamos como root en un sistema sería interesante poner lo que se denomina sniffer.

A modo de resumen, un sniffer lo que hace es capturar los paquetes que se transmiten a través de la subred en la que está el sistema que hackeamos, aunque dichos paquetes no vayan destinados a este sistema. Esto se consigue gracias a que cualquier máquina de una subred puede ponerse en modo promiscuo para poder capturar todos los paquetes que circulan (si no está en modo promiscuo el sistema solo acepta los paquetes que van destinados a él). Así, un sniffer hace llegar los paquetes que al hacker le interesa, que son generalmente los referentes a autentificación, generando un log con los logins y passwords que consigue "esnifar".

Bueno, un sniffer es algo ilegal. Así que si nos ven el sniffer y nos pillan ya nos podemos preparar.

Hay que tener cuidado ya que si hay una gran actividad en la subred en la que estamos hackeando el log irá creciendo y creciendo hasta que el admin se de cuenta de que sucede algo extraño. Por lo tanto, hay que ir entrando periódicamente para salvar la información que nos interese y dejar a 0 bytes el log. Esto supone muchos peligros, y hay que ser muy rápidos en nuestras incursiones si no queremos que el admin se de cuenta. Aquí es cuando es importante la organización de nuestras herramientas, el tener un shellscript que nos modifique todos los logs en cuestión de segundos...

No voy a extenderme mucho en este tema porque el correcto manejo de sniffers es ya algo más avanzado que requiere muchas más explicaciones.

¿ Ya está ?

Podríamos decir que prácticamente ya os he enseñado todo lo básico que un hacker novicio tiene que aprender para empezar a hacer sus pinillos. Pero si alguien ha llegado hasta aquí y tiene ganas de aprender más, voy a dedicar la sexta unidad (la última) para explicar más técnicas y un poco de todo.

¡ Nos vemos !




AULA MACEDONIA
a
MACEDONIA Magazine