Verificando se eu removi completamente um hack do WordPress?

105

Meu divertido blog do WordPress em http://fakeplasticrock.com (executando o WordPress 3.1.1) foi hackeado - ele exibia um <iframe>em todas as páginas da seguinte forma:

<iframe src="http://evilsite.com/go/1"></iframe>
<!DOCTYPE html PUBLIC "-//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 através do sistema de atualização incorporado do WordPress
  2. Instalei o Exploit Scanner (muitos avisos críticos em arquivos incomuns) e o AntiVirus (isso mostrou tudo verde e limpo, então eu o desinstalei e o removi após a execução)
  3. Senha do MySQL alterada.
  4. Alteradas todas as senhas de usuário do WordPress.
  5. Conectado via FTP e baixado todo o sistema de arquivos (não grande, este é um host compartilhado Linux apenas para WordPress)
  6. Diferenciou o sistema de arquivos de um ZIP oficial do WordPress 3.1.3 e removeu ou substituiu qualquer coisa que não correspondesse.

Eu tenho certeza que

  • todos os arquivos em disco são arquivos oficiais do WordPress 3.1.3
  • não existem arquivos "extras" no disco além do meu /theme, o plug-in Exploit Scanner (que acabei de baixar), a /uploadspasta e alguns outros arquivos esperados. Meu outro plugin, wp-recaptcha, corresponde à versão oficial baixada atual.
  • Eu também verifiquei o .htaccessarquivo e nada parece errado lá

o arquivo wordpress 3.1.3 compara dentro além da comparação

Não toquei no banco de dados , mas estou lutando para pensar em como algo no banco de dados pode ser malicioso sem código PHP especial para fazê-lo funcionar?

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

security hacked Jeff Atwood
fonte
1
Você deve manter o blog atualizado. :)
fuxia

Respostas:

80

Você identificou o vetor de exploração? Caso contrário, você pode se deixar abrir para futuras explorações.

Outras coisas a considerar:

  1. Alterar senhas de usuário administrador do WordPress - pronto
  2. Alterar senha de usuário da conta de hospedagem
  3. Alterar senhas de FTP
  4. Alterar senha do usuário do MySQL db - concluído
  5. Alterar o prefixo da tabela db
  6. Atualize seu wp-config nonces / salt
  7. Verifique suas permissões de diretório / arquivo
  8. Bloqueie o acesso à navegação no diretório, via .htaccess
  9. Veja tudo na entrada do Hardening WordPress Codex
  10. Consulte tudo na entrada do FAQ do meu site foi invadido pelo Codex
Chip Bennett
fonte
1
desculpe, esqueci de mencionar - alterei as senhas do WordPress, é claro. Post atualizado e marcado na lista aqui! Não consigo pensar em como eles poderiam ter minha senha de hospedagem ou a senha de FTP, apenas entrando no WordPress; essas informações não estão em lugar algum no sistema de arquivos ou no banco de dados.
Jeff Atwood
9
Você tem o provável vetor de exploração ao contrário; provavelmente não é o WordPress -> conta de hospedagem , mas sim a conta de hospedagem (via servidor ou FTP) -> WordPress .
Chip Bennett
2
@ Jeff algumas explorações no nível do servidor sobre as quais você não tem controle (além de encontrar um host melhor). Mas só porque você não usou credenciais de host / FTP não significa que alguém não as roubou , obtendo acesso à sua conta de hospedagem.
Chip Bennett
7
Existe uma exploração muito comum em que os malwares infectam sua estação de trabalho (ou a de um contratado), vasculham suas senhas salvas no seu programa FTP favorito (ou habilitado para FTP) e as enviam para o invasor, que compromete seu site e o usa para espalhar o mesmo malware para outros webmasters. Essa é uma maneira comum pela qual sua senha de FTP é roubada. O que é particularmente insidioso é que ele se espalhou por sites normais como o seu, e não pelos sites em que é provável que você tome cuidado.
tylerl
3
FYI, se você tiver acesso à linha de comando, WP-CLI tem um verificar checksums de comando que irá verificar cada arquivo contra wordpress.org
William Turrell
26

Observando a mensagem "navegação segura" do Google Chrome, você está recebendo o ".cc iFrame hack" que parece estar circulando MUITO ultimamente. Acho que o 3.1.3 corrigirá isso, mas verifique o seu arquivo index.php na raiz, se o site for o local onde ele me bateu até que eu TUDO TUDO fosse atualizado e as senhas alteradas.

Existem algumas coisas MUITO complicadas que as pessoas podem fazer com injeções de post e comentários. Você pode executar as seguintes consultas no seu banco de dados para ajudar a encontrar algumas que eu escrevi no blog pelo 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 isto ajude!

Dillie-O
fonte
4
Gostaria de acrescentar SELECT * FROM wp_* WHERE comment_content LIKE '%<?%'e SELECT * FROM wp_* WHERE comment_content LIKE '%<?php%'só para ter certeza ...
SeanJA
4
Oh, uma nota final. Suponho que você tenha ferramentas do Google para webmasters vinculadas a este domínio. Depois de limpar as coisas, você pode enviar uma solicitação da sua conta de ferramentas para webmasters para que o Google verifique novamente o site e remova a mensagem de aviso. Eles processam solicitações de ferramentas para webmasters normalmente em um dia. Caso contrário, você entra na "lista travessa" por bons 90 dias.
Dillie-O
Encontramos vários resultados, mas é por causa dos iframes incorporados para o Vimeo.
tooshel
20

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

Ah, e tente entender como o invasor chegou ao seu site. Em contas compartilhadas, geralmente é o servidor inteiro. Verifique os outros sites no servidor para blogs invadidos ou outras páginas também. Leia o seu log de FTP. Se você não sabe como aconteceu, não pode impedir o próximo intervalo.

fuxia
fonte
o Exploit Scanner não encontrou nenhuma conta de usuário oculta?
Jeff Atwood
@ Jeff Atwood, eu não confiaria nisso. Sua tabela de usuários não é tão grande. Você pode lê-lo facilmente sem nenhum plugin.
fuxia
Eu chequei a wp_usersmesa e apenas 2 linhas, tanto esperava .. nada na /uploadpasta incomum (apenas gifs e pngs e JPEGs)
Jeff Atwood
@ Jeff Atwood Você procurou nos arquivos ou apenas nas extensões? Todos os arquivos estão listados na biblioteca de mídia?
Fuxia
4
Os arquivos de imagem são um método de entrega de carga útil bastante comum. Veja aqui , e a equipe de revisão de temas também encontrou temas usando uma exploração TIFF semelhante.) Então, sim: eu verificaria cada um deles, para garantir que ele faça parte da Biblioteca de Mídia. (Easy varredura de alto nível: verificar se há imagens que não têm em miniatura-tamanhos definidos.)
Chip Bennett
13

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

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

Eu acho que o Exploit Scanner lançaria um aviso se encontrasse scripts, iframes, PHP (embora apenas perigosos se avaliados) ou outro código incomum no seu banco de dados.

Não tenho certeza se ele verifica outras tabelas que não sejam postagens e comentários, pode valer a pena dar /wp-admin/options.phpuma olhada rápida e ver se você vê 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 administrador).

TheDeadMedic
fonte
definitivamente é uma boa idéia executar uma consulta MySQL na tabela users para garantir que nada de inesperado esteja lá, e eu fiz isso. Boa dica!
91111 Jeff Atwood
8

Verifique as ferramentas do Google para webmasters para duas coisas:

  • verifique se seu site não foi sinalizado como comprometido e solicite reconsideração, se houver
  • verifique seu site como Googlebot e verifique se não está sendo inserido nenhum spam visível apenas para o Googlebot - exemplo disso é o hack WP Pharma

Além disso, eu reimplementaria o tema ou o verificaria com muito cuidado. Algumas linhas do PHP podem redefinir as principais funções do PHP para extrair o código malicioso do banco de dados, especialmente as tabelas wp_options key / value store

Jon Galloway
fonte
Sim, eu definitivamente reenviei o site pelas Ferramentas do Google para webmasters e parece "limpo" agora.
Jeff Atwood
6

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

E verifique se há usuários invisíveis na tabela de usuários; Vi usuários nas tabelas que não apareciam no WP Admin >> Users.

Opções limpas «Os plug - ins do WordPress mostrarão que lixo de plug-ins antigos e possivelmente vulneráveis ​​resta no banco de dados.

O seu tema também está sem a <head>tag. Por isso, verifique se você editou o tema para remover links incorretos.

E o de sempre: e Como encontrar um backdoor em um WordPress hackeado e em um Hardening WordPress «WordPress Codex

markratledge
fonte
5

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

Tom Chiverton
fonte
5
Duvido que tenha a ver com a atualização do WordPress (embora seja possível , apenas não é provável ). O WordPress em si quase nunca é o vetor de exploração. Os vetores comuns são configuração de host insegura e credenciais de FTP roubadas.
Chip Bennett
4

Isso aconteceu comigo uma vez, através de um vazamento no meio de comunicação. Eu tive que escrever um plugin para verificar o banco de dados em busca de links injetados. Você pode pegá-lo aqui como uma essência do github .

É bastante fácil de usar, possui várias etapas que fornecem feedback e verificam novamente seu banco de dados após a conclusão.

Boa sorte!

kaiser
fonte
4

Eu tive um hack muito semelhante que precisei consertar em um dos sites dos meus clientes.

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

Eu pelo menos faria algumas pesquisas no banco de dados, apenas por segurança. :)

Eric Allison
fonte
3

Verifique seus plugins !, até agora este ano houve 60 lançamentos de exploração de plugins .org, eu suspeitaria que o número real fosse muito maior, já que ninguém está realmente fazendo isso em tempo integral.

Você listou que possui apenas um plug-in, mas ele possui uma brecha na segurança (não sabe por quanto tempo ele saiu e pode não ser o vetor).

wp-recaptcha-plugin
A exploração foi lançada: 18/03/2011
Versão da exploração: 2.9.8

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

http://www.wpsecure.net/2011/03/wp-recaptcha-plugin/

Registro de alterações: http://wordpress.org/extend/plugins/wp-recaptcha/changelog/

Wyck
fonte
2

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

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

xLRDxREVENGEx
fonte
2

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

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

Powtac
fonte