Mostrando postagens com marcador pericia. Mostrar todas as postagens
Mostrando postagens com marcador pericia. Mostrar todas as postagens

sábado, julho 31, 2010

Perícia Forense... um honeypot para estudos!

Faz algum tempo que tenho interesse nesta área, e acompanhando alguns "pensamentos" pelo Buzz, eis que o Eriberto postou este honeypot (pote de mel, ou isca) para estudos.


João Eriberto Mota Filho: Assistindo a uma invasão de rede de camarote… - Planeta Debian Brasil
Bem, estou montando alguns casos para aulas de forense computacional. Já fiz dois introdutórios, disponíveis em http://eriberto.pro.br/forense. Mas eu precisava de algo voltado para uma invasão em rede. Então, montei a isca.

Dia 30 jul. 10

16:00 h

Comecei a montar uma máquina com Debian Squeeze para servir de base para uma máquina virtual vulnerável (usando Xen 4). Depois, criei a máquina virtual. A máquina base (real) possui uma senha de root forte e só está com o serviço ssh rodando. A máquina virtual possui ssh com senha fácil para root e um usuário test com senha fácil também. Tem um servidor de páginas Apache, PHP5, tudo com configuração default e, o mais importante, um monitor samhain enviando mails, para a minha conta falsa no GMail, a cada ocorrência anormal.

17:00 h

A máquina virtual está pronta e operando na Internet. Está disfarçada em uma máquina de uma rede atacadista. É importante ressaltar que não houve qualquer tipo de divulgação a respeito das máquinas (real e virtual) e que não houve registro em DNS. Teoricamente, ninguém deveria chegar em tais máquinas, a não ser por scaneamento. Ou seja: quem chegar é bandido! A máquina virtual tem IP terminado por 131 e a real 132.

18:47 h

O samhain envia um e-mail dizendo, dentre outras coisas, que o arquivo /etc/shadow foi alterado às 18:42 h (21:42 UTC). Veja:
CRIT   :  [2010-07-30T18:47:18-0300] msg=, path=, ctime_old=<[2010-07-30T19:36:20]>, ctime_new=<[2010-07-30T21:42:17]>, mtime_old=<[2010-07-30T19:36:20]>, mtime_new=<[2010-07-30T21:42:17]>, chksum_old=, chksum_new=
.
Nessa hora eu estava a caminho do shopping.

22:30 h

Cheguei do shopping e vi a mensagem do samhain. Batata! Não consigo mais logar no servidor como root. A senha foi trocada. Só tenho acesso à maquina real.
Na verdade, eu poderia tirar a virtual do ar e montá-la em um diretório para ver o seu conteúdo ou trocar a senha de root novamente. Mas, não é o caso. Preciso de um caso forense e vou deixar a máquina quieta por mais uns 2 ou 3 dias. Essa é a parte mais legal. Como perdi o acesso à máquina, só conhecerei um pedacinho da história. Então, terei que realmente fazer uma forense para descobrir tudo o que ocorreu. Um ponto chave será a memória. Até a senha de root (e outras) deve estar lá dentro.
A partir da máquina real, rodando IPtraf, constatei as seguintes situações:
  • As máquinas 200.220.199.8 (Brasil) e 202.140.34.82 (Índia) conectadas por ssh.
  • A máquina atacada está se conectando à porta 6667 da máquina 208.83.20.130. Ou seja: instalaram um cliente de IRC na máquina e conectaram.
  • O site original do Apache continua intacto.
  • Há um IP terminado por 182, na máquina atacada, conectando na porta 80 de 75.125.252.78. Ou seja: alguém levantou um novo IP e o está utilizando. Ao tentar entrar no site da 75.125.252.78, via browser local, recebi: Bad Request (Invalid Hostname).
  • .
Bem, coloquei um tcpdump, na máquina real, gravando tudo o que for ou vier da porta 6667 externa. O meu objetivo é logar alguma conversa de chat para descobrir o canal e o nick dos atacantes. Com isso, talvez eu consiga a senha de root. Vamos esperar. Também coloquei outro tcpdump rodando para logar tudo o que trafegar de/para 75.125.252.78.

Dia 31 jul. 10

00:53 h

A situação se mantém inalterada. Os dois atacantes continuam conectados. Mas as coisas estão meio paradas. Acho que foram dormir e deixaram as conexões estabelecidas para não as perderem. Faz sentido. Vou dormir também. Amanhã continuo. Boa noite para quem está acompanhado.

01:02 h

Opa! Em tempo! Alguém criou o IP final 180 e conectou na 80 de 221.232.247.43. Esse IP gera uma tela estranha no browser. O 200.220.199.8 se foi. Só resta o 202.140.34.82. Resolvi gravar todo o tráfego destinado a qualquer porta 80. Agora sim, vou dormir.

07:30 h

Alvorada!!! Fui ver a situação. Era a seguinte:
  • Às 06:25 h o logrotate da máquina tentou atuar e não conseguiu, enviando o seguinte mail (desviado para o GMail):
    /etc/cron.daily/logrotate:
     error: error accessing /var/log/apache2: No such file or directory
     error: apache2:1 glob failed for /var/log/apache2/*.log
     error: found error in /var/log/apache2/*.log , skipping
     error: error accessing /var/log/samhain: No such file or directory
     error: samhain:1 glob failed for /var/log/samhain/*.log
     error: found error in /var/log/samhain/*.log , skipping
  • Ou seja: o diretório de logs foi apagado. Nisso já ficou óbvio que o Samhain foi retirado do ar… Mas o importante aconteceu: ele deu o primeiro alerta.
  • O site original do Apache continua intacto.
  • A senha de root permanece alterada e desconhecida para mim.
  • Não houve tráfego na porta 80.
  • No chat, porta 6667, foi capturado tráfego relevante e os atacantes falam em espanhol. Já sei qual é o canal. Neste momento, há 28 nicks logados no canal, dos quais, 19 são operadores.
  • Foi criado um usuário oracle na máquina (vi isso pelo tráfego no chat).
  • A máquina continua logada como cliente em 208.83.20.130:6667.
  • Foi criada a porta 25 sobre o IP final 131. Então, instalaram um servidor de e-mail, provavelmente para fazer spam. Passei a logar também o tráfego de portas 25 na máquina real.
  • A máquina 118.161.245.67 (Taiwan) está conectada na porta 25.
  • A máquina 206.125.46.134 (USA) deu um Syn na 22 do IP final 131, recebeu um Syn-Ack e mandou um Rst. Está scaneando portas. Provavelmente Nmap. Observe que whois interessante:
AirlineReservations.Com, Inc. AIRLINERES-CALPOP-COM (NET-206-125-40-0-1) 206.125.40.0 - 206.125.47.255
LA Data Center CP-809973-001 (NET-206-125-46-128-1) 206.125.46.128 - 206.125.46.159
  • Foi criada uma porta 3128 na máquina, sobre o IP final 180. Provavelmente, temos um proxy para esconder navegação na Internet.
  • A máquina 118.168.138.210 (Taiwan) está conectada nessa porta.
  • Hum… A máquina 113.213.248.181 (Japão) enviou um Syn para a porta 445 e recebeu um Rst. Porta fechada. O cara estava procurando portas abertas.
  • Alguém fez uma conexão no socket 70.39.70.186 a partir do IP final 182. Um site de relógios?
  • As máquinas 85.105.188.189 (Turquia), 94.28.207.39 (Russia) e 212.87.127.16 (Bélgica) tentaram um Syn na 23 do IP final 131 e receberam um Rst. Porta fechada.

08:50 h

  • Só agora terminei a análise publicada no horário anterior.
  • Há um novo canal no IRC. Este tem 42 nicks e 13 operadores. Mas parece ser um canal normal, não de hackers. Estão falando coisas banais e abertamente.
  • Bem, estou satisfeito. Fizeram tudo o que eu queria. Até apagaram os logs. Hora de tirar o zumbi do ar. Vou tomar banho e vou retirar a máquina do ar. Antes vou fazer todos os procedimentos de coleta de dados de memória e máquina. Vou fazer o que está descrito na palestra de forense, disponível em http://eriberto.pro.br/palestras.

10:05 h

  • Cheguei na cena do crime. Imediatamente, fiz o dump de memória. Como usei Xen, foi fácil:
# xm dump-core vm0-superatacado memoria.dd
  • Colhi os dados essenciais na máquina ainda viva. Usei netcat para copiar os arquivos via rede. Agora posso fazer isso porque já colhi a memória. Um exemplo:
Máquina de destino: # netcat -l -p 53000 > free
Máquina de origem:  # free -m | netcat  53000
  • A seguir, tirei a máquina virtual do ar usando o comando xm destroy, para evitar que ela gravasse algo no disco, superpondo dados.
  • O último passo foi gerar uma imagem do disco, usando o dcfldd (veja este post).

Matando a sua curiosidade…

Apenas para matar a sua curiosidade, numa rápida investigação de memória, olha o que encontrei:
# strings memoria.dd |egrep "Accepted"|grep root|sort -n
Jul 30 18:01:06 superatacado sshd[1160]: Accepted password for root from 190.120.229.185 port 34031 ssh2
Jul 30 18:01:06 superatacado sshd[1160]: Accepted password for root from 190.120.229.185 port 34031 ssh2
Jul 30 18:05:42 superatacado sshd[1356]: Accepted password for root from 190.120.229.185 port 59465 ssh2
Jul 30 18:07:53 superatacado sshd[1579]: Accepted password for root from 189.235.242.88 port 49316 ssh2
Jul 30 18:08:55 superatacado sshd[1759]: Accepted password for root from 190.120.229.185 port 48439 ssh2
Jul 30 19:51:35 superatacado sshd[16537]: Accepted password for root from 189.235.242.88 port 49576 ssh2
  • 190.120.229.185 – Panamá!
  • 189.235.242.88 – México.
Outra:
# strings memoria.dd |egrep chauthtok|sort -n
Jul 30 18:24:25 superatacado passwd[5629]: pam_unix(passwd:chauthtok): password changed for test
Jul 30 18:42:17 superatacado passwd[8377]: pam_unix(passwd:chauthtok): password changed for root
Lembre-se: eles apagaram os logs e, depois, constatei que derubaram também os serviços syslogd e klogd. É por isso que só consegui colher esses dados na memória. Com certeza, haverá muita coisa sobre isso na superfície do disco também.

O fim

Bem, agora é trabalhar em cima das evidências. Vou fazer uma rápida forense para descobrir algumas coisas. Uma delas são as senhas utilizadas para root, sites etc. É bem possível que eu encontre isso na memória. No entanto, já decidi aperfeiçoar o processo. Isso quer dizer que, em breve, farei tudo novamente para ter um material melhor. Quero que seja um caso mais incrementado. Por exemplo: o dump de memória, mesmo comprimido, ficou muito grande. Tenho que trabalhar com uma memória menor para as pessoas poderem fazer download.
Mas valeu muito a experiência.
[]s!