[HACK] Re: hacking Digest, Vol 9, Issue 6

[Óscar Marín]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- ----- Original Message ----- 
From: "THS" <zumbita at conket.com>
To: <hacking at argo.es>
Sent: Monday, November 17, 2003 12:50 PM
Subject: [HACK] Re: hacking Digest, Vol 9, Issue 6



> ---------------< COPY & PASTE MESSAGE
>  >-----------------------------------------------------------
>
> Unix, unix y sus huellas

[...]


> ------< END COPY PASTE >-------------------------------------------

Cuando hagas un copy & paste, asegurate de poner los créditos del
mensaje, es decir, quién lo ha escrito, y también de dónde
proviene...

Podeis acceder a una copia del mensaje original en:

http://www.elistas.net/lista/hackindex/archivo/indice/4613/msg/11256

Para acceder hay que estar suscrito a la lista de hackindex, para los
que no esteis suscritos, ahí va una copia "exacta" del mensaje
original...

Un saludo!!!

- --

Asunto: Re: [HackIndex] Borrar huellas en Unix
Fecha: Miercoles, 12 de Noviembre, 2003  00:58:10 (+0100)
Autor: Frisbie <listasdecorreo at wanadoo.es>



- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

NOTA: Como parece que no ha llegado el correo, ya que ni me lo han
devuelto ni ha salido en la lista, lo vuelvo a enviar...

- - ---

Bueno, antes que nada muchas gracias a todos por las respuestas...
Son muy útiles, aunque seguro que todavía podemos añadir unas cuantas
cosillas más... Bueno, voy a poner mi parte...

He estado mirando programas para eliminar logs y he dado con uno que
me ha gustado mucho:

Advanced log cleaner de nsn/0x333
http://www.0x333.org/code/0x333shadow.tar.gz

Te hace un montón de cosas automáticamente, básicamente todo lo
relacionado con los ficheros utmp, utmpx, wtmp y wtmpx... Además hace
tareas de localizar syslogd y pararlo...
Aquí os pongo una salida de la ejecución del comando... (sólo lo
interesante)

sh-2.05# wi -b -i nombre_a_borrar

[WARNING]: syslogd not killed!
[*] cleaning extra logs:
[*] Cleaning /var/run/utmp removed 0/17
[*] Cleaning /var/log/wtmp removed 0/6329
[*] Cleaning /var/log/lastlog removed 0/32
[*] impossible restart syslogd no path found.
[*] acct not detected.
[*] snoopy not detected.
[*] checking interfaces in promisc mode...
[*] founded 2 interfaces on this system.
[*] interface: lo status: is in quiet mode.
[*] interface: eth0 status: is in quiet mode.
clean completed, 0x333 Security Labs www.0x333.org nsn of outsiders.

sh-2.05# wi -a -i nombre_a_borrar

[WARNING]: syslogd not killed!
[*] Cleaning /var/log/mail removed 0/168
[*] Cleaning /var/log/warn removed 0/86
[*] Cleaning /var/log/messages removed 0/935
[*] Cleaning /var/log/messages.0 removed 0/7616
[*] Cleaning /var/log/warn-20030910 removed 0/13
[*] Cleaning /var/log/httpd/ssl_scache.dir removed 0/0
[*] Cleaning /var/log/httpd/access_log removed 0/214
[*] Cleaning /var/log/httpd/error_log removed 0/193
[*] Cleaning /var/log/snmpd.conf removed 0/39
[*] Cleaning /var/log/snmpd.log removed 0/17
[*] Cleaning /var/log/messages-20010331 removed 0/1410
(aquí borra el nombre en todos los archivos de texto que encuentra
recursivamente - MUY ÚTIL por si hemos olvidado algo)

[*] cleaning extra logs:

[*] Cleaning /var/run/utmp removed 0/17
[*] Cleaning /var/log/wtmp removed 2/6331
[*] Cleaning /var/log/lastlog removed 1/32
[*] trying find other logs syslogd/newsyslogd attack :)
[*] getting information /etc/syslog.conf
[*] founded /dev/tty10 in /etc/syslog.conf if isn't empty log will be
cleaned.
[*] founded /dev/xconsole in /etc/syslog.conf if isn't empty log will
be cleaned.
(etc...)

Bueno, ahora respondo entre líneas unas cuantas cosas interesantes...
Y al final van un par de cosillas adicionales que no se han nombrado
todavía (se que se hará un poco largo, pero incluso se puede juntar
con borrado de logs en Windows y sacar un "white paper" sobre borrado
de logs ;))

Roman> Para "purgar" los archivos de texto (como el history) puedes
tirar de
Roman>"grep -v" (grep -v tuip >newlog). Para los binarios (wtmp, etc)
hay

Mu buena idea... Lo malo de los *history es que te pillan todos los
comandos de shell, con lo cual acabarías antes con el vi y borrando a
pelo lo que no te interese o eliminando el history directamente

Roman>bastantes zappers por ahí; sólo ten cuidado que no sean tan
cutres de
Roman>poner a cero las entradas a "borrar" en vez de borrarlas
realmente
Roman>(zap.c). Es fácilmente detectable.

Según lo que tengo entendido, hay programas por ahí que detectan los
0's que le mete el zapper, pero habría manera de que detectara un
análisis forense, de quién era esa entrada o sólo valdrá para saber
en la hora que ha pasado "algo"??

Falcifer>Tambien es importante fijarte en los tiempos de los archivos
a los que
Falcifer>has accedido, imaginate que entras en un server a las 3 de
la mañana y...
Falcifer>...investigadores. Para solucionar estos inconvenientes
utiliza el comando
Falcifer>find (para encontrar los archivos en cuestion) y el comando
touch para
Falcifer>modificarlos.

Mu buena idea... Además esto es fácilmente "scriptable"

Falcifer>Ademas de los logs "clasicos" (utmp, wtmp, history ....)
acuerdate de
Falcifer>mirar los especificos de aplicaciones (los de apache, ftp
....) y otros
Falcifer>que hayas podido modificar o alertar (prelude,
firewalls...).

Buena anotación, el problema es que no siempre están en la misma
máquina, sobretodo los firewall, menos mal que los administradores
suelen usar el mismo login/pass para todas las máquinas (o casi
todas) de su red, e incluso a veces para el correo... jejjeje

Falcifer>Repasa los ficheros de configuracion del syslog y los de
otros sistemas
Falcifer>de log (al igual que la configuracion de aplicaciones:
apache ...) para
Falcifer>asegurarte que los logs no se han guardado en ningun otro
sitio distinto
Falcifer>del habitual o que se han enviado a un servidor de logs.

Además de esto, yo añadiría revisar si el syslogd pudiera tener otro
nombre o incluso si hay otro programa que pueda estar haciendo la
función de syslog (vamos un ps -ef / ps -aux)
Una cosa.... Hay un programa llamado "klogd" Kernel Log Daemon o algo
así... Con esto se puede "loggar" la ip con la que te conectas o
exploits que puedes usar (p.ej. ptrace), en teoría sólo registra
cosas del sistema que supongo que volcará al messages, pero entonces
dependiendo del valor de DEBUG que tenga, ¿será posible que detecte
que se ha ejecutado un xploit (BoF)?

Falcifer>si los log se envian a un servidor y estas practicamente
seguro que te
Falcifer>van a descubrir puedes plantearte el inundar de logs falsos
al servidor
Falcifer>de log (que trabalenguas) de forma que el admin se vea
abrumado por
Falcifer>tanto registro y le cueste o le sea imposible dilucidar
cuales son
Falcifer>autenticos

Esto es lo mismo que comenta Roman más alante... Suponiendo que se
envíen a través de syslog... Entonces, ¿conoceis alguna herramienta
para generar "basura" por syslog? ¿El syslogd no chequea nada de los
paquetes que le llegan? ¿tan fácil es engañar al syslogd? En teoría
con un simple sniffer capturando el paquete y reenviandolo modificado
aleatoriamente 1.000.000 de veces, le jodemos vivo??

Falcifer>Si modificas ficheros observa que no haya una aplicacion que
guarde las
Falcifer>firmas de estos, pq en el chequeo de integridad podrias ser
delatado,
Falcifer>entonces deberias atacar dicha aplicacion y generar nuevas
firmas para
Falcifer>los ficheros que acabas de modificar.

Esto es lo típico de los hash MD5 (tripwire y similares...) Supongo
que este tipo de programas, en caso de que generes una nueva firma
para las aplicaciones que has modificado avisará de alguna forma
(dejando un log, emitiendo una alarma, etc...), eso suponiendo que
guarde los logs en la misma máquina, si lo hace como dice Carlos más
adelante desde un servidor central público, la cosa ta mucho más
jodía...

Falcifer>es importante en recostruir toda la historia de tu ataque
enumerando
Falcifer>(lapiz y papel) todos los pasos que has seguido y pensar uno
a uno y
Falcifer>pensar en los registros que ha podido dejar cada accion

Muy buena... Yo recomendaría tomar nota de lo que se hace, desde la
primera vez que accedes a su página web o intentas hacer una
transferencia de zona DNS, hasta el final... A ser posible guardar
también logs de lo que se hace (casi cualquier programa de telnet/ssh
lo permite), aunque luego cuidadito con esos logs que son prueba
irrefutable de lo que has hecho...

Carlos> es syslog o su sucesor syslog-ng. Como primera medida se debe
parar
Carlos> este servicio para detener el logeador de eventos.

Yo estoy de acuerdo con lo que comenta Román más alante, no creo que
sea bueno detener el demonio de syslog, ya que eso mismo dejaría
logs... Creo que la mejor opción será primero chequear la
configuración del syslogd para ver dónde deja los logs y luego
eliminar en la medida de lo posible esos logs

Carlos> Si el root es bastante paranoico, tendra la precaucion de que
cada vez que
Carlos> se loguee el root, se envie un correo a una direccion fuera
de la maquina

No estoy de acuerdo... Si el root es bastante paranoico deshabilitará
la entrada de root desde telnet/ssh, que además debería de ser lo
normal. Si tienes que enviar por correo todos los comandos que se
ejecutan como root (pongamos con un su-, ya que la entrada de root
directa no estaría permitida), es muy probable que tengas gran
cantidad de logs que al final ni siquiera mires... En la mayoría de
sistemas que he visto los comandos se pasan con syslogd o con rcp
(remote copy)...

Carlos> estan en /etc/init.d y reciben los parametros start, stop,
restart, status.

Eso es buena idea... Es importante mirar los init.d y los rcx.d para
ver lo que se arranca en la máquina...

Carlos> Tambien toca editar a mano el /var/log/messages, el wtmp que
registra la
Carlos> entrada de usuarios, y revisar el log del correo para saber
si algun

El wtmp no se puede editar a mano que yo sepa, es un fichero binario,
¿¿no??

Carlos> En la mayoria de la maquinas todo se guarda en:
Carlos> /var/log/wtmp
Carlos> /var/log/messages
Carlos> logs de correo en /var
Carlos> .history, .bash_history en el home.

Unos cuantos directorios más, donde suelen estar por defecto todos
los logs, pids y demás cosas...
/var/log
/var/adm
/var/mail
/var/run
/var/account
/usr/adm
/etc

Carlos> En maquinas con roots realmente precavidos ningun log se
guarda localmente.

Totalmente de acuerdo...

Roman> PD2: El tema que ha apuntado "falcifer" de cambiar las fechas
de
Roman>ficheros es importante ("man touch") pero se puede optimizar un
Roman>poquito. Por ejemplo, el fichero "messages" es escrito cada muy
poco

Pero bueno, no está nada mal la idea si lo que quieres es un script,
aunque en el propio script se podrían excluir directamente algunos
ficheros...

Roman>a) Instales un backdoor de forma que no loguee tus acciones. Es
mejor
Roman>no dejar huellas a luego tener que borrarlas.

Totalmente de acuerdo... Pero un backdoor lo malo que tiene es que
también deja huella su instalación (que deberemos borrar) y que
existen programas de detección de backdoor, troyanos y demás (ya lo
he visto en algún que otro sitio), de esta forma, incluso instalando
el detector después del backdoor, podrían darse cuenta y dejar
preparada una "trampa" (algo así como un honeypot) para la próxima
vez que entremos.

Roman>b) Te crees un pequeño .sh que realice automáticamente todas
las
Roman>tareas de borrado de logs. Es importante que se adecúe a la
shell en
Roman>cuestión. Esta tarea sólo la tendrás que hacer una vez para una
shell
Roman>dada.

Mucho más rápido y así no se olvida de nada... :)

Roman> PD4: Yo también haría un "ps aux", "ps -ef" o similar, y vería
si hay
Roman>procesos "peligrosos" corriendo. Con peligroso me refiero a
alguno que
Roman>nos pudiera delatar. Por ejemplo, puede estar activado el
"proccess
Roman>accounting" (en este caso habrá otros ficheros a tocar,
normalmente en
Roman>el /var/log).

Bueno, pues además de todo esto.. unas cuantas cosillas más...

1.- Revisar el crontab, es posible que hayan tareas corriendo de
generación de logs, o envío de ficheros a una máquina remota. Habría
que deshabilitar esta tarea del cron y volver a activarla una vez
eliminadas las huellas
2.- Echar un vistazo a los LKM (Loadable Kernel Modules) por si
alguien ha entrado antes que nosotros o por si hay algún programa en
forma de módulo de kernel para detección de backdoors o de lo que sea
3.- En cuanto entremos hacer un telnet/ssh localhost entrar a la
máquina y salir, de esta manera, cuando entre el mismo usuario con el
que tú has entrado, en vez de sacar tu ip, pondrá que se ha conectado
desde localhost, lo que generará menos dudas al siguiente que entre,
¿por cierto, alguien sabe eliminar esto directamente sin necesidad de
volver a entrar?? ¿Lastlog quizás?

Roman> Por cierto, sería interesante tb discutir contramedidas para
proteger
Roman>nuestro sistema contra el borrado de huellas. Algunas ya han
salido a
Roman>la luz.

Bueno, pues creo que siguiendo todos estos pasos, eliminaremos gran
parte de las huellas, pero aún así, puede ser muy bueno, usar
condones (máquinas intermedias), entrar desde un número de teléfono
que no se pueda reconocer (cabina, movil prepago, cibercafé que no
pidan DNI y sin camaras de vigilancia) y hacer los diferentes pasos
del ataque (enumeración de red, análisis de aplicaciones, prueba de
vulnerabilidades/exploits, shell) desde máquinas distintas
(diferentes IPs), y todo lo que se os ocurra...

Si hacemos todo esto, la verdad que lo tienen difícil para saber
quiénes han sido los que han hecho algo en la máquina, e incluso ni
siquiera sabrán que han llegado a entrar en sus máquinas...

Como contramedida a todo esto yo lo que haría es meter una tarea en
el cron que cada 15-30 min a lo sumo, recogiera varios logs
"críticos" del sistema y los enviara a otra máquina, de esta manera,
un hacker que entre y en 30 min no se haya dado cuenta de que existe
esto y lo desactive, nunca podrá evitar esos logs. Además es muy
importante que la máquina a la que se envía la información esté muy
protegida, sólo un usuario o dos, además del root y que no admita la
administración remota a ser posible (o por lo menos sólo admita
determinadas IPs internas de máquinas en las que no recoja logs)...
Si a esto le añadimos el control de ejecutables con firmas MD5
situadas en páginas en internet, y le instalamos un detector de
backdoors e incluso un LKM que haga de keylogger y envíe la
información a algún sitio, es muuuy difícil que no queden logs, al
menos en parte de un ataque...

Bueno, espero no haberos aburrido con esto, y que nos sirva a todos
de algo, tanto para atacar como para defenderse... Ahora a ver si
alguien le añade un par de cosillas, se anima con el borrado de
huellas para windows, lo coje todo y hace un whitepaper... :p

Enga... saludetes a tod at s...

- - - --

Frisbie

- -----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3

iQA/AwUBP7F3kPkwYeBBlj+VEQLgDwCeMktJT5NJmGxpQ5vzX4XKUNfKrPgAn3ke
rSpoUtsKDGWyM5CaViO5D2Dy
=a4zR
- -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3

iQA/AwUBP7n7RoZoMl1F4Xm0EQJNkgCgiOwYT8U7RESNm2hW0fUo6/PxGIMAnj3B
+SnvwaEMXKiXJCbGvvo2DGGA
=VUdq
-----END PGP SIGNATURE-----