Pular para o conteúdo

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 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 <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 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!

    45 comentários em “Assistindo a uma invasão de rede de camarote…”

    1. Eriberto, muito massa este teste ! Realmente muito interessante…
      Isto só mostra que temos que realmente ter todos os cuidados, com nossas senhas principalmente, mesmo no linux, para não sermos surpreendidos…
      Parabéns !

    2. Caramba! Não foram nem duas horas e a maquina já foi atacada? 😮
      Como já disseram acima, terra de ninguém!
      Acompanhei as postagens desde ontem, quando postou o link sobre ela no twitter…
      Senti-me como se estivesse em um livro, envolvido na história… foi algo parecido com quando li pela primeira vez “Confissões de Hackers adolescentes, de Dan Verton”.
      Parabéns pela analise e pela publicação deste belo artigo!!! 😉

    3. Opa!, também acompanhei o teste desde ontem, curti, sempre chamou minha atenção a forense computacional, li sua palestra e fiquei mais interessado na materia, de agora em diante vou acompanhar sua página de forense. Uma dúvida, usou squeeze tanto na máquina base quanto na máquina virtual?, e queria saber o que você acha do uso da Distribuição BackTrack para forense, abraços Eriberto.

    4. Olá Reinado!

      Usei Squeeze nos dois. Quanto ao Backtrack, é uma excelente distribuição. Mas eu prefiro um pendrive com Debian customizado. Coloco as coisas do meu jeito.

      []s!

    5. Eriberto, parabéns por compartilhar esse case, bem legal mesmo, nada melhor do quer fazer
      um material com um case real, de já fico esperando o material de acordo com as metodologias de melhores práticas.

      Abs

      Jader

    6. Eriberto, somente uma dúvida.

      Como você está fazendo a contenção de dados? Ou você está deixando tudo passar sem maiores preocupações? Falo em contenção bem no sentido que aparece nos papers “Know your enemy”, que tenho certeza que você conhece 🙂

    7. Oi Pedro! Bom ver você por aqui.

      Não fiz qualquer tipo de contenção. A ideia é um case de forense. Então, no fim, eu mesmo só saberei de tudo o que ocorreu depois de uma forense. Entendeu? É uma máquina vazia, sem nada.

      Mas, no sentido da contenção, eu poderia colocar um tcpdump na máquina real logando tudo. Mas aí fica fácil…

      []s!

    8. Boa tarde Eriberto,
      Recebi o post de um colega, quando li o título, não me contive… Só pode ser armação…
      Que nada… Era real…
      Muito boa a sua matéria, botando ditos à limpo, mostrando “step-by-step” os passos capturados… Tudo que aprendemos na teoria, agora foi visto em prática… PARABÉNS…
      Nos cases de análise forense, quase sempre são montados pelos instrutores/professores, neste, até para o criador da máquina virtual será uma surpresa…
      Espero que consiga efetuar uma compressão nos dados, para compartilhar esta máquina virtual.
      Como comentado pelo Pedro Arthur, “Know your enemy”… Também, como diz o dito popular: “Mantenha seus amigos perto e seus inimigos mais perto ainda!”…

      []´s

    9. Paulo,

      É simples. Sei que ele entrou por ssh. Logo depois, ele trocou a senha dos usuários test e root via comando (passwd). Então, tem que aparecer uma troca de senha bem sucedida nos logs (que foram apagados). Agora, você deve olhar um log de troca de senha qualquer para ver o formato. No caso do Debian, isso pode ser visto em /var/log/auth.log. Um exemplo:

      Aug  3 09:13:47 antares passwd[31440]: pam_unix(passwd:chauthtok): password changed for eriberto

      Então, elegi a palavra chauthok (que significa changing authentication ok ou algo bem similar) por ser bem incomum. Ou seja, é mais fácil usar isso e chegar um resultado final do que usar passwd, por exempo, e ter que ficar garimpando no meio dos muitos resultados obtidos.

      É isso.

      []s

    10. Stefan..

      Ah, essa é boa. Quando você acessa uma página e ela está embaralhada, é porque está em alguma codificação diferente da que você está usando. Isso, no caso, pode ser evitado colocando-se um meta no topo do código da página, indicando a codificação de caracteres utilizada. Mas, neste caso, foi deixado sem o meta de propósito. É como um truque para esconder o que há lá.

      Se você estiver usando Firefox, entre na página e pressione Ctrl U. Você vai ver o código-fonte da página. Vá lendo com cuidado. Lá no finalzinho você vai encontrar:

      <A href="http://www.miibeian.gov.cn/&quot;

      Isso indica que há forte probabilidade de haver um chinês envolvido na história (por causa do cn). Então, podemos arriscar a voltar para o site e clicar em Exibir > Codificação > Mais > Leste asiático > Chinês simplificado (GBK). Maravilhe-se!!!!

      Mas e se não houvesse indícios no código? Bem, você teria que ir tentando outras codificações até conseguir.

      Grande abraço!

    11. Olá professor Eriberto, como vai?

      Seguinte, estou procurando uma especialização (Pós/Latu senso) na área de segurança em sistemas de informação, forense computacional ou relacionados. Você poderia me indicar alguma instituição?

      E a propósito, muito bacana a sua abordagem.

      At.
      Andrei

    12. Olá Andrei,

      Se for em Brasília, começou esta semana a pós em perícia na Católica (UCB, 916 Norte). A segunda aula foi ontem. Amanhã será a terceira. Acho que você ainda consegue entrar, se fizer a inscrição hoje. Não te afirmo com certeza porque não sou o coordenador. Em segurança, tem a pós em Software Livre, também na Católica (916 N). Desta eu sou o coordenador e próxima turma no início de 2011.

      []s

    13. Parabéns professor, muito bom o seu site, aulas, dicas, etc…. Também sou professor e vou tentar desenvolver um trabalho como o seu aqui em Goiás.

    14. Eriberto boa tarde.
      Sou aluno de ciência da computação, estou desenvolvendo uma monografia sobre honeypots de alta interação, gostei muito do seu artigo, queria informações de como configurar samhain.
      Obrigado

    15. Eriberto bom dia, você fez o dump de memoria porque utilizava o xen, mais e se eu utilizar o VMWARE Work. como faço pra fazer o dump ? Outra pergunta tem alguma forma de fazer isso no windows?

      Abraços

    16. Prezado Eriberto,

      Estou entrando nesse ramo de computação forense, por hobby, no entanto, quero saber de sua parte se há um grande mercado para profissionais especializados nessa área, pois no Google e conversando com amigos, que trabalham em empresas, disseram-me que não há preocupação excessiva com isso; alguns deles trabalham em empresas como IBM.

      Essa dúvida é um pouco estranha mas computação forense deveria ser um ramo muito aplicado em qualquer setor.
      Tenho interesse nisso e tenho interesse em fornecer esse tipo de serviço para empresas.
      No setor governamental, isso poderia ser aplicado amplamente…

      Uma outra dúvida que tenho é sobre a nossa legislação e sobre o que é e o que não é permitido.
      Acho q isso geraria uma loooonnngaaaaaaa discussão…

      Por enquanto isso é só

      Agradeço a atenção e por compartilhar esse trabalho

    17. Fumachi,

      Na minha opinião, todo trabalho relacionado a redes e segurança é interessante e faltam profissionais no mercado. Você não pode, por exemplo, recolocar um servidor comprometido no ar, sem antes averiguar quais fragilidades permitiram um incidente. Agora, se as pessoas não se preocupam com isso, são outros 500…

      Quanto à legislação, sei o que interessa para mim e não sou a melhor pessoa para debater isso.

      Grande abraço e boa sorte!!!

      Eriberto

    18. Boa Tarde Eriberto parabens pelo projeto estou seguindo suas dicas, e meu server isca foi invadido rs. O invasor até agora se conectou apenas a um server de irc. Vc por favor poderia me auxiliar em relacao a sniffar essa porta? estou tentando o tcpdump -i eth0 -nStA port 6667 . Mas ate o momento nao tive nada capturado. Descobri a porta usando um netstat -an. Obg e Parabens

    19. Olá Marcos! Legal. Parabéns pela isca e obrigado pelas palavras.

      O seu tcpdump está certo. Tem certeza que o tráfego ocorre pela eth0? Há mais de uma placa de rede?

      []s

    20. Nao apenas uma Eriberto, verifiquei pelo netstat -an que o invsasor ainda esta logado, e rapidamente acessei a rede e vi que o trafego esta acontecendo. Com essa sintaxe que citei anteriormente via tcpdump eu consigo ler o que eles podem estar teclado? Existe alguma mais precisa ou melhor. Obrigado pela atenção.

    Deixe um comentário

    O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

    13 + 19 =