Como fazer um post-mortem de um hack de servidor


29

Eu tenho uma máquina Windows Server 2003 SP2 com IIS6, SQL Server 2005, MySQL 5 e PHP 4.3 instalados nela. Esta não é uma máquina de produção, mas é exposta ao mundo através de um nome de domínio. A área de trabalho remota está ativada na máquina e duas contas administrativas estão ativas nela.

Esta manhã, descobri que a máquina havia sido desconectada com um nome de usuário desconhecido ainda na caixa de texto de login. Após uma investigação mais aprofundada, descobri que dois usuários do Windows foram criados, o antivírus foi desinstalado e um punhado de arquivos .exe foram lançados na unidade C :.

O que eu gostaria de saber é, que medidas devo tomar para garantir que isso não ocorra novamente e em quais áreas devo me concentrar para determinar a via de entrada. Eu já verifiquei o netstat -a para ver quais portas estão abertas e nada parece estranho lá. Eu encontrei arquivos desconhecidos na pasta de dados do MySQL, que eu acho que poderia ter sido o ponto de entrada, mas não tenho certeza.

Eu realmente aprecio as etapas para realizar um bom post-mortem de um hack de servidor, para que eu possa evitar isso no futuro.

Revisão pós-investigação

Depois de alguma investigação, acho que descobri o que aconteceu. Primeiro, a máquina não esteve online durante o período de agosto de 2008 a outubro de 2009. Durante esse período, uma vulnerabilidade de segurança foi descoberta, a vulnerabilidade MS08-067 . "Esta é uma vulnerabilidade de execução remota de código. Um invasor que explorar com êxito essa vulnerabilidade poderá assumir o controle completo de um sistema afetado remotamente. Nos sistemas baseados no Microsoft Windows 2000, Windows XP e Windows Server 2003, um invasor poderia explorar esta vulnerabilidade sobre o RPC sem autenticação e pode executar código arbitrário ". Essa vulnerabilidade foi corrigida com a Atualização de segurança KB958644, lançada em outubro de 2008.

Como a máquina estava offline no momento e perdeu essa atualização, acredito que essa vulnerabilidade foi explorada logo após a máquina ter voltado a funcionar em outubro de 2009. Eu encontrei referências a um programa bycnboy.exe que foi descrito como um programa backdoor que, em seguida, cria muitos estragos no sistema infectado. Logo após a máquina estar on-line, as atualizações automáticas instalaram o patch, o que impedia o controle remoto do sistema. Como o backdoor agora estava fechado, acredito que o atacante criou contas físicas na máquina e pôde utilizá-la por mais uma semana até perceber o que estava acontecendo.

Depois de buscar agressivamente o código malicioso, .exes e .dlls, remover sites auto-hospedados e contas de usuário, a máquina agora está novamente em um estado de funcionamento. Num futuro próximo, monitorarei o sistema e analisarei os logs do servidor para determinar se uma repetição do incidente está acontecendo.

Obrigado pelas informações e etapas fornecidas.

Respostas:


28

Fazer post-mortem é uma arte negra em si mesma. É um pouco diferente a cada vez, porque realmente não há dois arrombamentos iguais. Com isso em mente, uma visão geral básica do meu processo recomendado está abaixo, com algumas notas específicas sobre sua situação:

  1. Desconecte fisicamente a máquina da rede. (Realmente. Faça isso agora.)
  2. Etapa opcional: Faça uma cópia da imagem binária do disco rígido para uso futuro.
  3. Faça uma cópia de todos os arquivos de log, dados valiosos etc. em um disco rígido removível
    • Opcionalmente, copie qualquer "ferramenta hacker" que você encontrar também
  4. Comece o post-mortem real. No seu caso:
    • Observe todas as contas de usuário novas ou ausentes. Veja se as pastas iniciais têm algum conteúdo "interessante".
    • Anote quaisquer programas / binários / arquivos de dados novos ou ausentes.
    • Verifique primeiro os logs do MySQL - procure por algo "incomum"
    • Verifique o restante dos logs do servidor. Veja se você pode encontrar os novos usuários que estão sendo criados, endereços dos quais fizeram login etc.
    • Procure evidências de danos ou roubo de dados
  5. Quando você encontrar a causa do problema, observe como impedir que isso aconteça novamente.
  6. Limpe o servidor: formate e reinstale tudo, restaure seus dados e tampe o orifício original com as anotações do nº 5.

Normalmente, você executa a etapa 2 se envolver a aplicação da lei. Você executa a Etapa 3 para poder revisar as informações após a reconstrução do servidor sem precisar ler a cópia da imagem feita na etapa 2.

O grau de detalhamento da etapa 4 depende de seus objetivos: apenas tapar o buraco é um tipo diferente de investigação que rastrear quem roubou alguns dados valiosos :)

O passo 6 é essencial para o IMHO. Você não "corrige" um host comprometido: limpe-o e comece de novo com um bom estado conhecido. Isso garante que você não perca nenhuma pepita de sujeira deixada na caixa como uma bomba-relógio.

Este não é, de modo algum, um esboço completo post-mortem. Estou marcando isso como wiki da comunidade, pois estou sempre procurando por melhorias no processo - não o uso frequentemente :-)


3
Não tenho experiência em fazer algo assim, mas o conselho do Security Monkey, se você pretende criar uma máquina para investigação, é puxar o cabo de alimentação, criar uma imagem do disco rígido e começar a investigar. (Macaco Segurança: it.toolbox.com/blogs/securitymonkey )
MattB

1
O Security Monkey está desligado - Você deseja congelar a máquina (puxe o cabo de força) quando for visualizá-la. o desligamento e / ou a inicialização podem desarmar o código de auto-destruição ou limpeza e puxar o poder impede que isso aconteça antes que você possa criar sua imagem.
precisa saber é o seguinte

2
Além disso - eu diria que você não deve confiar nos resultados dos comandos "embutidos" no sistema invadido, como o netstat (ou dir, etc.). Novamente, não tenho experiência direta com isso no nível corporativo, mas lembro de ter sido invadido em máquinas pessoais em que parte do hack foi substituir ferramentas internas para mascarar o que realmente estava acontecendo.
MattB

4
O +1 da etapa 6 é vital, você não sabe se o netstat está mostrando a verdade sem analisar o tráfego de rede real - e isso por si só pode ser bastante complicado e um teste de paciência ... então limpe-o. Não é mais a sua caixa. Analisar a imagem tudo o que quiser, mas limpar a maldita máquina;)
Oskar Duveborn

1
Eu diria que você provavelmente está sempre melhor executando a etapa 2, já que não tem muita certeza do que encontrará durante sua investigação. Ter imagens binárias também significa que você pode ter pessoas diferentes olhando coisas diferentes, usando uma cópia cada.
Vatine 26/09
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.