Assistindo a uma invasão de rede de camarote

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=<POLICY [ReadOnly] C-------T->, path=</etc/shadow>, 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=<B48D594D9879AB0B364DEC764A1322BD08A6F07BB1729B31>, chksum_new=<A394EE8F4C333D45B50D74DCFC78D70AD8F18DE76082D7C3>

.

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 whoisinteressante:
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 <ip_de_destino> 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 syslogde 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.

by

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s