Verificando se eu removi completamente um hack do WordPress?

98

Meu blog WordPress divertido no enlace (executando o WordPress 3.1.1) foi invadido - estava exibindo um <iframe> em cada página assim:

<iframe src="http://evilsite.com/go/1"></iframe><!DOCTYPEhtmlPUBLIC"-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> 
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> 

Eu fiz o seguinte

  1. Atualizado para 3.1.3 por meio do sistema de atualização integrado do WordPress
  2. Instalado o Exploit Scanner (muitos avisos críticos em arquivos incomuns) e AntiVirus (isso ficou todo verde e limpo, então eu desinstalei e removi depois de rodar)
  3. Alterou a senha do MySQL.
  4. Alterou todas as senhas de usuário do WordPress.
  5. Conectado via FTP e baixado todo o sistema de arquivos (não grande, esse é um host compartilhado somente com o WordPress para Linux)
  6. Diffed o sistema de arquivos contra um ZIP oficial do WordPress 3.1.3 e removido ou sobrescrevendo qualquer coisa que não correspondesse.

Tenho certeza de que

  • todos os arquivos no disco são arquivos oficiais do WordPress 3.1.3
  • não há arquivos "extras" em disco que não seja meu /theme , o plug-in Exploit Scanner (que acabei de baixar), a pasta /uploads e um pequeno grupo de outros arquivos esperados. Meu outro plug-in, o wp-recaptcha, corresponde à versão oficial baixada oficialmente.
  • Também verifiquei o arquivo .htaccess e nada parece estar errado

Eu não toquei no banco de dados , mas estou lutando para pensar como algo no banco de dados pode ser malicioso sem código PHP especial para que ele funcione?

Meu blog WordPress parece bem e livre de hackers agora (eu acho), mas há mais alguma coisa que eu deva verificar?

    
por Jeff Atwood 10.06.2011 / 17:31
fonte

12 respostas

76

Você identificou o vetor de exploração? Se não, você pode estar deixando-se vulnerável a futuras explorações.

Outras coisas a considerar:

  1. Alterar as senhas de usuário admin do WordPress - concluído
  2. Alterar senha do usuário da conta de hospedagem
  3. Alterar senhas de FTP
  4. Alterar a senha do usuário do banco de dados do MySQL - concluído
  5. Altere o prefixo da tabela db
  6. Atualize suas wp-config nonces / salt
  7. Verifique suas permissões de diretório / arquivo
  8. Bloqueia o acesso à navegação no diretório, via .htaccess
  9. Analise tudo na Endurecimento do WordPress Entrada do Codex
  10. Analise tudo na FAQ Meu site foi invadido Entrada do Codex
por Chip Bennett 10.06.2011 / 17:58
fonte
26

Olhando para a mensagem "navegação segura" do Google Chrome, você está recebendo o ".cc iFrame hack" que parece estar circulando muito ultimamente. Eu acho que o 3.1.3 irá consertar isso, mas verifique seu arquivo index.php na raiz se o seu site, que é onde ele ficava me pressionando até eu ter TUDO atualizado e as senhas mudadas.

Há algumas coisas muito complicadas que as pessoas podem fazer com injeções de comentários e postagens. Você pode executar as seguintes consultas em seu banco de dados para ajudar a encontrar algumas delas. Eu publiquei no blog o resto do meu "rastreamento". aqui .

SELECT * FROM wp_posts WHERE post_content LIKE '%<iframe%'
UNION
SELECT * FROM wp_posts WHERE post_content LIKE '%<noscript%'
UNION
SELECT * FROM wp_posts WHERE post_content LIKE '%display:%'
UNION
SELECT * FROM wp_posts WHERE post_content LIKE '%<?%'
UNION
SELECT * FROM wp_posts WHERE post_content LIKE '%<?php%'
SELECT * FROM wp_comments WHERE comment_content LIKE '%<iframe%'
UNION
SELECT * FROM wp_comments WHERE comment_content LIKE '%<noscript%'
UNION
SELECT * FROM wp_comments WHERE comment_content LIKE '%display:%'
UNION
SELECT * FROM wp_comments WHERE comment_content LIKE '%<?%'
UNION
SELECT * FROM wp_comments WHERE comment_content LIKE '%<?php%'

Espero que isso ajude!

    
por Dillie-O 10.06.2011 / 18:00
fonte
20

O banco de dados também pode conter código malicioso: contas de usuário ocultas ou valores que são impressos sem escape em algum lugar. Além disso, verifique seu diretório de uploads para arquivos que não pertencem a ele.

Ah, e tente entender como o invasor encontrou seu caminho no seu site. Em contas compartilhadas, geralmente é o servidor inteiro. Verifique os outros sites no servidor para blogs hackeados ou outras páginas também. Leia o seu log de FTP. Se você não sabe como aconteceu, não pode evitar a próxima pausa.

    
por fuxia 10.06.2011 / 17:47
fonte
13

Desculpe ouvir que você foi hackeado - parece que você fez um bom trabalho de recuperação!

Seu sistema de arquivos parece dourado, eu não diria que há mais alguma coisa que você possa fazer aqui.

Eu pensaria que o Exploit Scanner lançaria um aviso se encontrasse algum script, iframes, PHP (embora seja perigoso se avaliado) ou outro código incomum em seu banco de dados.

Não tenho certeza se ele verifica tabelas que não sejam postagens & comentários, pode valer a pena verificar /wp-admin/options.php para uma rápida olhada e ver se você encontrar algo estranho.

Eu também verificaria sua tabela de usuários em um cliente MySQL (os usuários podem estar no banco de dados, mas não visíveis no admin).

    
por TheDeadMedic 10.06.2011 / 17:49
fonte
8

Verifique as ferramentas do Google para webmasters para duas coisas:

  • verifique se seu site não foi sinalizado como comprometido e solicite a reconsideração se ele tiver
  • verifique seu site como Googlebot e verifique se não há spam sendo inserido, o que é visível apenas para o Googlebot. Exemplo disso, é o WP Pharma hackeado

Além disso, eu reimplementaria o tema ou verificaria com muito cuidado. Algumas linhas de PHP podem redefinir as principais funções do PHP para que eles extraiam código malicioso do banco de dados, especialmente as tabelas de armazenamento de chave / valor wp_options

    
por Jon Galloway 10.06.2011 / 18:10
fonte
6

Pesquise no banco de dados via phpmyadmin por "iframe" ou descarregue o banco de dados e pesquise o texto.

E verifique se há usuários invisíveis na tabela de usuários; Eu vi usuários nas tabelas que não apareceram no WP Admin > > Usuários.

Opções limpas «Plugins do WordPress mostrarão o que o lixo de plugins antigos e possivelmente vulneráveis é deixado no banco de dados .

Seu tema também está sem a tag <head> , por isso, verifique isso caso você tenha editado o tema para remover links inválidos.

E o habitual: e Como encontrar um backdoor em um WordPress hackeado e Hardar WordPress «WordPress Codex

    
por markratledge 10.06.2011 / 17:58
fonte
5

"há mais alguma coisa que eu deveria verificar?" Você precisa examinar seu processo e descobrir como foi hackeado (quase certamente porque não corrigiu a tempo ou corretamente) e consertar isso também, não apenas os sintomas.

    
por Tom Chiverton 10.06.2011 / 18:00
fonte
4

Isso aconteceu comigo uma vez, através de um vazamento no mediatemple. Eu tive que escrever um plugin para verificar o banco de dados para links injetados. Você pode pegá-lo aqui como um githubist .

É bastante amigável, tem várias etapas que fornecem feedback e verifica novamente seu banco de dados depois que você terminar.

Boa sorte!

    
por kaiser 10.06.2011 / 18:01
fonte
4

Eu tive um hack muito semelhante que tive que corrigir em um dos meus sites de clientes.

Havia scripts maliciosos no sistema de arquivos (coisas do php base64_decode). No entanto, o banco de dados 'posts' & as tabelas de 'comentários' foram comprometidas e o código iframe foi espalhado por esses dados também.

Eu gostaria de pelo menos fazer algumas pesquisas no banco de dados, apenas para estar seguro. :)

    
por Eric Allison 10.06.2011 / 18:11
fonte
3

Verifique seus plugins!, até agora este ano houve 60 versões de exploits de plugins .org, eu suspeito que o número real seja muito maior, já que ninguém está realmente fazendo isso em tempo integral.

Você listou que você tem apenas um plugin, bem, ele tinha uma falha de segurança (não tem certeza de quanto tempo ele estava fora, e pode não ser o vetor).

  

wp-recaptcha-plugin
  O exploit foi lançado: 2011-03-18
  Versão de exploração: 2.9.8

O autor afirmou que ele reescreveu a versão 3.0, mas não há menção ao patch de segurança.

enlace

Alterar log: enlace

    
por Wyck 11.06.2011 / 06:43
fonte
2

Eu uso um servidor de nuvem e tenho números aleatórios mal-intencionados de ssh no ftp. As senhas são extremamente difíceis de hackear. Todo o acesso root é completamente negado. Eu concordo que o WordPress não será seu culpado. Outra coisa a verificar é se as sessões ftp não fecham, vírus no seu computador pessoal (lembre-se que você pode carregar um arquivo para o seu site e quem carrega esse arquivo pode obter o mesmo vírus), também não manter suas senhas em sites públicos ou privados os sites sempre os corrigem no papel, nunca em um documento de texto ou bloco de notas.

Por fim, pergunte ao seu host se eles recentemente tiveram uma violação, pois eles devem ter uma configuração de firewall

    
por xLRDxREVENGEx 11.06.2011 / 07:50
fonte
2

Verifique a data dos seus arquivos. Nenhum arquivo deve ter uma alteração de dados mais recente que sua última edição / instalação!

Mas também isso pode ser falsificado. A única maneira de ter certeza seria comparar (por exemplo, comparar hash) todos os arquivos com os arquivos de instalação originais.

    
por powtac 11.06.2011 / 14:49
fonte