Mais um pedido de socorro por site invadido

De vez em quando isso acontece e quinta-feira última aconteceu de novo: perto do final do expediente, um amigo meu me liga pedindo que eu ajude um amigo dele que teve o site invadido. Daí eu pensei, pela milésima vez: preciso escrever e publicar uma cartilha sobre como agir nessas situações – por incrível que pareça, não há muita informação clara na Internet sobre isso.

Mas é um projeto um pouco mais trabalhoso do que parece e cujo resultado talvez fique longo demais para um post aqui no blog – prometo fazer isso outro dia. Hoje, vou só descrever o que aconteceu nesse caso em particular, para mostrar um caso de uma típica má reação. No decorrer desse relato, eu deliberadamente não mencionei os nomes dos envolvidos; a política padrão da Tempest é preservar a anonimidade dos envolvidos a menos que nos seja dada permissão explícita para identificá-los.

Após asseverar ao meu amigo que eu daria prioridade ao caso, expliquei que isso que ele queria se chama "resposta a incidente". É algo que já fizemos várias vezes, mas raramente é feito de forma estanque, sem um contrato "guarda-chuva" que englobe outras atividades de prevenção, simplesmente porque em geral o interessado não tem a agilidade necessária para lidar com o custo inesperado.

Em todo caso, pedi que ele passasse meus contatos para o amigo dele. Arregimentei o líder da minha equipe de segurança de aplicações, o João Lins, que ainda estava aqui em plena véspera de feriado. Pouco tempo depois recebi uma ligação de um senhor que se descrevia como o dono da empresa. Ele sumarizou que tinha sido "invadido por hackers" e que tinha urgência em colocar o site de volta no ar porque tinha feito uma divulgação no jornal e esperava muitos usuários no fim de semana.

Expliquei que o procedimento nesses casos é tirar o site no ar, ou no mínimo, bloquear o acesso externo, para cortar o acesso do invasor e ao mesmo tempo preservar a "cena do crime" para que possamos fazer um diagnóstico. Tentei explicar que era importantíssimo que eles não mexessem mais no sistema, pois qualquer alteração que eles fizessem poderia dificultar nossa análise forense. Já aí o negócio começou a desandar: ele falou que os técnicos dele estavam mexendo no sistema para recolocá-lo no ar. Tentei explicar de novo de outra forma, mas ele, audivelmente aflito, disse que já não estava entendendo nada e que iria me passar para o técnico dele.

No conference call, o técnico dele nos contou que havia sido invadido por SQL Injection e que o atacante, vindo da rússia, instalou um código com uma chamada para um malware. Não chegamos a acessar o sistema dele para confirmar se esse diagnóstico estava correto, mas, pela descrição, o caso dele parecia ser muito comum. Não é que um "hacker" os invadiu; ao invés, um "hacker" fez um programa que explora que sai pela Internet afora em busca de sites que tenham um certo tipo de vulnerabilidade muito comum, e, quando as acha, os invade. Ou seja, o hacker não estava atrás do site desse cara no varejo – ele estava atrás de sites vulneráveis em geral, no atacado (trocadilho infame!)

Como consequência de terem sido invadidos, duas coisas aconteceram: uma da qual estou certo porque verifiquei e a outra eu sei porque o técnico deles me contou. A primeira é que os site deles entrou na lista negra do Google, usada pelo navegador Firefox e derivados. Assim, quando você entra no site deles usando o Firefox, aparece uma tela vermelha indicando que aquele site provavelmente está sendo usado para propagar malware. Ou seja, os usuários que tentarem navegar até o site deles vão levar um baita susto ao ver a advertência. Nas versões antigas do Internet Explorer, que não tem recurso semelhante, o usuário que acessasse o site deles provavelmente seria infectado com o malware ao acessar a página deles, mas não cheguei a testar isso porque eles tiraram a página do ar.

A segunda coisa é que o banco de dados deles deve ter recebido centenas de inserções extras, criadas pelo worm, com os códigos especiais que causam sua propagação. Removê-los sem destruir os dados legítimos é uma trabalheira danada, muito pior que catar feijão; e, feito às pressas, induz a erros que podem te fazer com que se inadvertidamente remova algo que não deveria.

Tentei novamente explicar, dessa vez pro técnico deles, que eles deveriam isolar o site e parar de mexer nele para que nós da Tempest pudéssemos diagnosticar. Novamente recebi a ladainha de que precisavam recolocar o site no ar a todo custo. Expliquei que era isso que queríamos também, mas, primeiro, precisamos diagnosticar. Ainda que eles extirpassem do banco de dados todos os dados falsos que o worm inseriu, se eles colocassem o site no ar novamente com a mesma vulnerabilidade, provavelmente em questão de horas eles seriam invadidos de novo.

O técnico deles disse que entendeu, mas continuava insistindo em agir como se pudesse cuidar do problema sozinho – compreensível, estava sofrendo pressão do chefe, que nesses casos só quer saber de colocar a joça no ar. Tentei explicar tudo de novo mais duas vezes, com a voz mais suave e a melhor didática que consegui angariar no momento, mas vi que não ia adiantar. Disse-lhes então que quando estivessem prontos para aceitar nossa ajuda, estaríamos à disposição, dei meus contatos novamente e encerrei a ligação. Liguei pro meu amigo, que originalmente me contactou a respeito, e o coloquei a par da situação.

Hoje é domingo, acessei o site deles e continua fora do ar e continua na lista negra do Firefox.

Como eu disse, hoje não vai dar par eu fazer toda a lista de procedimentos em caso de site invadido. Mas pelo menos alguns dos primeiros itens eu posso dar: não entre em pânico, desconecte o sistema da Internet, chame ajuda especializada e, enquanto a ajuda não chega, não toque mais no sistema. A arte de contornar crises começa em não deixar o desespero agravá-la.

Comentários
Aceita-se formatação à la TWiki. HTML e scripts são filtrados. Máximo 15KiB.

 
Enviando... por favor aguarde...
Comentário enviado com suceso -- obrigado.
Ele aparecerá quando os moderadores o aprovarem.
Houve uma falha no envio do formulário!
Deixei uma nota para os admins verificarem o problema.
Perdoe-nos o transtorno. Por favor tente novamente mais tarde.
Aldo Albuquerque | 2010-07-20 10:45:20 | permalink | topo

Um dica importante que sempre dou aos que passaram por uma situação dessa é a de tomar extremo cuidado com o processo de restauração dos backups das páginas do site e do banco de dados que foram invadidos.

Para muitas pessoas o backup mais confiável a ser restaurado é aquele backup do(s) dia(s) imediatamente anteriores aos da invasão. Tal atitude na imensa maiora das vezes é equivocada, pois de modo geral, os administradores do site não tem um grau razoável de certeza de quando site foi realmente invadido. Eles geralmente assumem como "momento zero" da invasão quando o atacante inseriu algo no site e/ou pichou a página.

Na maioria dos casos, o ato da pichação do site é um das últimas ações do atacante, que muito provavelmente fez a invasão do site bem antes e passou um bom tempo "dando um voltinha" no servidor hospedeiro.

É justamente ai que mora o perigo, pois o atacante pode ter plantado facilmente um backdoor no servidor web (existem vários em ASP, ASPX, PHP, JSP, CFM, CGI...) e com o processo de backup normal do servidor, o possível trojan pode ter sido "backupeado" junto às páginas legítimas, e ao tentar restairá-lo, o incauto administrador (mesmo já tendo corrigido a(s) falha(s) exploradas na invasão) pode estar abrindo novamente as portas do servidor ao atacante.

Deste modo, sempre aconselho que o backup a ser restaurado seja oriundo dos respositórios confiáveis dos desenvolvedores/webmasters/DBAs (CVSs e afins) para que se tenha uma maior tranquilidade no processo, mesmo que isso signifique restaurar uma versão ligeiramente desatualizada do site.