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

[THS]

>
>
>>   Esto es... Imaginaos que hemos entrado a un sistema, hemos dado
>>una vuelta y no queremos dejar rastro de que hemos estado por ahi'.
>>?Que' pasos tendri'amos que seguir para borrar TODAS las huellas
>>dejadas? ?Hay alguna herramienta/script que facilite esta labor?
>>    
>>
>
>
>      En efecto, hay muchas herramientas, de las que destacan dos:
>
>        purge.c => Un cla'sico, se encarga de borrar entradas WTMP/UTMP 
>(Para no aparecer en W/WHO ni tener constancia en comandos como FINGER)
>
>        vanish2.tgz => E'ste es el que actualmente uso, borra todas nuestras 
>referencias en: WTMP, UTMP, lastlog, messages, secure, xfelog,maillog, 
>warn, mail, httpd.access_log, y httpd.error_log.
>
>      Ambos puedes encontrarlos en www.packetstormsecurity.nl
>
>      Hay que destacar, que para usar estos tipos de utilidades, hay que
>  tener UID=0 (root).
>
>      Un truco: ?Nunca te olvides de .bash_history!
>
>  
>
>>>Gracias a todos y saludos!!!
>>>      
>>>
>
>
>De nada, un saludo.
>
>  
>
---------------< COPY & PASTE MESSAGE 
 >-----------------------------------------------------------

Unix, unix y sus huellas

Bueno, antes que nada muchas gracias a todos por las respuestas...
Son muy u'tiles, aunque seguro que todavi'a podemos an~adir unas cuantas
cosillas ma'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 monto'n de cosas automa'ticamente, ba'sicamente todo lo
relacionado con los ficheros utmp, utmpx, wtmp y wtmpx... Adema's hace
tareas de localizar syslogd y pararlo...
Aqui' os pongo una salida de la ejecucio'n del comando... (so'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 
<http://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
(aqui' borra el nombre en todos los archivos de texto que encuentra
recursivamente - MUY U'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 li'neas unas cuantas cosas interesantes...
Y al final van un par de cosillas adicionales que no se han nombrado
todavi'a (se que se hara' 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 acabari'as antes con el vi y borrando a
pelo lo que no te interese o eliminando el history directamente
Roman>bastantes zappers por ahi'; so'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 fa'cilmente detectable.
Segu'n lo que tengo entendido, hay programas por ahi' que detectan los
0's que le mete el zapper, pero habri'a manera de que detectara un
ana'lisis forense, de quie'n era esa entrada o so'lo valdra' 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 man~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... Adema's esto es fa'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 anotacio'n, el problema es que no siempre esta'n en la misma
ma'quina, sobretodo los firewall, menos mal que los administradores
suelen usar el mismo login/pass para todas las ma'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.
Adema's de esto, yo an~adiri'a revisar si el syslogd pudiera tener otro
nombre o incluso si hay otro programa que pueda estar haciendo la
funcio'n de syslog (vamos un ps -ef / ps -aux)
Una cosa.... Hay un programa llamado "klogd" Kernel Log Daemon o algo
asi'... Con esto se puede "loggar" la ip con la que te conectas o
exploits que puedes usar (p.ej. ptrace), en teori'a so'lo registra
cosas del sistema que supongo que volcara' al messages, pero entonces
dependiendo del valor de DEBUG que tenga, ?sera' 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 ma's alante... Suponiendo que se
envi'en a trave's de syslog... Entonces, ?conoceis alguna herramienta
para generar "basura" por syslog? ?El syslogd no chequea nada de los
paquetes que le llegan? ?tan fa'cil es engan~ar al syslogd? En teori'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 ti'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 avisara' de alguna forma
(dejando un log, emitiendo una alarma, etc...), eso suponiendo que
guarde los logs en la misma ma'quina, si lo hace como dice Carlos ma's
adelante desde un servidor central pu'blico, la cosa ta mucho ma's
jodi'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 recomendari'a tomar nota de lo que se hace, desde la
primera vez que accedes a su pa'gina web o intentas hacer una
transferencia de zona DNS, hasta el final... A ser posible guardar
tambie'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 Roma'n ma's alante, no creo que
sea bueno detener el demonio de syslog, ya que eso mismo dejari'a
logs... Creo que la mejor opcio'n sera' primero chequear la
configuracio'n del syslogd para ver do'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 deshabilitara'
la entrada de root desde telnet/ssh, que adema's deberi'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 estari'a permitida), es muy probable que tengas gran
cantidad de logs que al final ni siquiera mires... En la mayori'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 ma'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 ma's, donde suelen estar por defecto todos
los logs, pids y dema'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 esta' nada mal la idea si lo que quieres es un script,
aunque en el propio script se podri'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
tambie'n deja huella su instalacio'n (que deberemos borrar) y que
existen programas de deteccio'n de backdoor, troyanos y dema's (ya lo
he visto en algu'n que otro sitio), de esta forma, incluso instalando
el detector despue's del backdoor, podri'an darse cuenta y dejar
preparada una "trampa" (algo asi' como un honeypot) para la pro'xima
vez que entremos.
Roman>b) Te crees un pequen~o .sh que realice automa'ticamente todas
las
Roman>tareas de borrado de logs. Es importante que se adecu'e a la
shell en
Roman>cuestio'n. Esta tarea so'lo la tendra's que hacer una vez para una
shell
Roman>dada.
Mucho ma's ra'pido y asi' no se olvida de nada... :)
Roman> PD4: Yo tambie'n hari'a un "ps aux", "ps -ef" o similar, y veri'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 habra' otros ficheros a tocar,
normalmente en
Roman>el /var/log).
Bueno, pues adema's de todo esto.. unas cuantas cosillas ma's...
1.- Revisar el crontab, es posible que hayan tareas corriendo de
generacio'n de logs, o envi'o de ficheros a una ma'quina remota. Habri'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 algu'n programa en
forma de mo'dulo de kernel para deteccio'n de backdoors o de lo que sea
3.- En cuanto entremos hacer un telnet/ssh localhost entrar a la
ma'quina y salir, de esta manera, cuando entre el mismo usuario con el
que tu' has entrado, en vez de sacar tu ip, pondra' que se ha conectado
desde localhost, lo que generara' menos dudas al siguiente que entre,
?por cierto, alguien sabe eliminar esto directamente sin necesidad de
volver a entrar?? ?Lastlog quiza's?
Roman> Por cierto, seri'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 au'n asi', puede ser muy bueno, usar
condones (ma'quinas intermedias), entrar desde un nu'mero de tele'fono
que no se pueda reconocer (cabina, movil prepago, cibercafe' que no
pidan DNI y sin camaras de vigilancia) y hacer los diferentes pasos
del ataque (enumeracio'n de red, ana'lisis de aplicaciones, prueba de
vulnerabilidades/exploits, shell) desde ma'quinas distintas
(diferentes IPs), y todo lo que se os ocurra...
Si hacemos todo esto, la verdad que lo tienen difi'cil para saber
quie'nes han sido los que han hecho algo en la ma'quina, e incluso ni
siquiera sabra'n que han llegado a entrar en sus ma'quinas...
Como contramedida a todo esto yo lo que hari'a es meter una tarea en
el cron que cada 15-30 min a lo sumo, recogiera varios logs
"cri'ticos" del sistema y los enviara a otra ma'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 podra' evitar esos logs. Adema's es muy
importante que la ma'quina a la que se envi'a la informacio'n este' muy
protegida, so'lo un usuario o dos, adema's del root y que no admita la
administracio'n remota a ser posible (o por lo menos so'lo admita
determinadas IPs internas de ma'quinas en las que no recoja logs)...
Si a esto le an~adimos el control de ejecutables con firmas MD5
situadas en pa'ginas en internet, y le instalamos un detector de
backdoors e incluso un LKM que haga de keylogger y envi'e la
informacio'n a algu'n sitio, es muuuy difi'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 an~ade un par de cosillas, se anima con el borrado de
huellas para windows, lo coje todo y hace un whitepaper... :p

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