The #ChromeDevSummit site is live, happening Nov 12-13 in San Francisco, CA
Check it out for details and request an invite. We'll be diving deep into modern web tech & looking ahead to the platform's future.

Correção da invasão de palavras-chave japonesas

Este guia foi criado especificamente para um tipo de invasão que cria texto em japonês gerado automaticamente no seu site, a qual chamamos de invasão de palavras-chave japonesas. Este guia foi projetado para usuários dos Sistemas de gerenciamento de conteúdo mais conhecidos (CMS, na sigla em inglês), mas será útil mesmo se você não usar um CMS.

Observação: você não tem certeza se o site foi invadido? Comece com a leitura do guia sobre como verificar se o site foi invadido.

Índice

Como identificar esse tipo de invasão

A invasão de palavras-chave japonesas normalmente cria novas páginas com texto em japonês gerado automaticamente no site em nomes de diretórios gerados aleatoriamente (por exemplo, http://example.com/ltjmnjp/341.html). Essas páginas geram receita com links afiliados para lojas que vendem mercadorias de marcas falsas e são exibidas na Pesquisa Google. Veja um exemplo de uma dessas páginas:

Neste tipo de invasão, o hacker normalmente adiciona a si mesmo como proprietário no Search Console para aumentar os lucros, manipulando as configurações do site, como a segmentação geográfica e sitemaps. Se você recebeu uma notificação de que alguém desconhecido verificou seu site no Search Console, há uma grande possibilidade de que ele tenha sido invadido.

Comece pela verificação da Ferramenta de problemas de segurança no Search Console para ver se o Google descobriu alguma dessas páginas invadidas no site. Também é possível descobrir páginas como essa ao abrir a Pesquisa Google e pesquisar site:[your site root URL]. Isso mostrará as páginas do seu site que o Google indexou, incluindo as páginas invadidas. Confira algumas páginas dos resultados da pesquisa para ver se você consegue identificar URLs incomuns. Caso não encontre conteúdo invadido na Pesquisa Google, use os mesmos termos de pesquisa em um mecanismo de pesquisa diferente. Outros mecanismos de pesquisa podem mostrar conteúdos invadidos que o Google removeu do índice. Veja abaixo um exemplo disso.

Os resultados da pesquisa contêm várias páginas que não foram criadas pelo proprietário do site. Se você ler as descrições com atenção, verá exemplos do texto em japonês criados por essa invasão.

Ao visitar uma página invadida, talvez encontre uma mensagem informando que a página não existe (por exemplo, um erro 404). Não se deixe enganar! Os hackers tentarão fazer com que você acredite que as páginas invadidas saíram do ar ou foram corrigidas. Eles fazem isso com técnicas de cloaking de conteúdo. Verifique se há técnicas de cloaking inserindo os URLs do site na ferramenta Fetch as Google do Search Console. Com a ferramenta Fetch as Google, você pode ver o conteúdo escondido subjacente.

Correção da invasão

Faça uma cópia off-line dos arquivos antes de removê-los, caso precise restaurá-los mais tarde. Ou, então, faça backup do site inteiro antes de iniciar o processo de limpeza. É possível fazer isso salvando todos os arquivos que estão no seu servidor para um local fora dele ou procurando as melhores opções de backup para seu CMS específico. Se você usar um CMS, também será necessário fazer o backup do banco de dados.

Remover as novas contas criadas no Search Console

Se um novo proprietário que você não reconhece tiver sido adicionado à sua conta do Search Console, revogue o acesso dele o mais rápido possível. É possível consultar quais usuários estão verificados para o site na página de verificação do Search Console. Clique em "Detalhes da verificação" do site para visualizar todos os usuários verificados.

Para remover um proprietário do Search Console, consulte a seção "Remover proprietário" na Central de Ajuda sobre gerenciamento de usuários, proprietários e permissões. Você precisará remover o token de verificação associado que normalmente é um arquivo HTML na raiz do site ou um arquivo .htaccess gerado dinamicamente imitando um arquivo HTML.

Se você não conseguir encontrar um token de verificação HTML no site, verifique se há uma regra de regravação no seu arquivo .htaccess. A regra de regravação será semelhante a este exemplo:

  RewriteEngine On
  RewriteRule ^google(.*)\.html$ dir/file.php?google=$1 [L] 

Observação: normalmente, é possível conferir se o token de verificação gerado dinamicamente foi removido acessando um arquivo de token de verificação simulado, como wwww.example.com/google[random number and letters].html. Por exemplo, se o site for www.brandonsbaseballcards.com, navegue para www.brandonsbaseballcards.com/google1234.html. Se essa página retornar um HTTP 404, o token de verificação gerado dinamicamente provavelmente estará corrigido.

Para remover o token de verificação gerado dinamicamente do seu arquivo .htaccess, siga as etapas abaixo.

Verificar o arquivo .htaccess (2 etapas)

Além de usar um arquivo .htaccess para criar tokens de verificação gerados dinamicamente, os hackers costumam usar regras de .htaccess para redirecionar os usuários ou criar páginas de spam com conteúdo sem sentido. A menos que você tenha regras personalizadas de .htaccess, recomendamos trocar seu .htaccess por uma cópia completamente nova.

Etapa 1

Localize o arquivo .htaccess no seu site. Se você não tiver certeza de onde encontrá-lo e estiver usando um CMS, como WordPress, Joomla ou Drupal, pesquise "local do arquivo .htaccess" em um mecanismo de pesquisa juntamente com o nome do CMS. Dependendo do site, você encontrará vários arquivos .htaccess. Faça uma lista com todos os locais dos arquivos .htaccess.

Etapa 2

Substitua todos os arquivos .htaccess por uma versão limpa ou padrão. Normalmente, é possível encontrar uma versão padrão do arquivo .htaccess pesquisando por "arquivo .htaccess padrão" e o nome do CMS. Para sites com vários arquivos .htaccess, encontre a versão limpa de cada um deles e faça a substituição.

Observação: muitas vezes, o .htaccess é um "arquivo oculto". Ative a exibição de arquivos ocultos ao procurá-lo.

Remover todos os arquivos e scripts maliciosos (4 etapas)

Identificar arquivos maliciosos pode ser complicado e demorar várias horas. Leve o tempo que precisar para verificar os arquivos. Este é um bom momento para fazer backup dos arquivos do site, caso ainda não o tenha feito. Pesquise no Google "backup de site" e o nome do CMS para encontrar instruções sobre como fazer isso.

Etapa 1

Se você usar um CMS, reinstale todos os arquivos principais (padrão) que vêm na distribuição padrão do CMS. Isso ajuda a garantir que esses arquivos não tenham conteúdo invadido. Pesquise no Google "reinstalar" e o nome do CMS para encontrar instruções sobre o processo de reinstalação. Se você tiver plug-ins, módulos, extensões ou temas, reinstale-os também.

Reinstalar os arquivos principais pode fazer com que você perca as personalizações feitas, se os arquivos tiverem sido editados diretamente. Faça backup do seu banco de dados e de todos os arquivos antes da reinstalação.

Etapa 2

Os hackers normalmente modificarão seu sitemap ou adicionarão novos sitemaps para fazer com que os URLs deles sejam indexados mais rapidamente. Se você já tiver um arquivo de sitemap, verifique se há links suspeitos nele e remova-os do sitemap. Se houver arquivos de sitemap que você não se lembra de ter adicionado ao seu site, verifique-os e remova-os, caso eles tenham somente URLs de spam.

Etapa 3

Procure por outros arquivos maliciosos ou comprometidos. Todos os arquivos maliciosos podem já ter sido removidos nas duas etapas anteriores, mas é melhor seguir estas próximas etapas caso haja mais arquivos comprometidos no site.

Não se preocupe achando que vai precisar abrir e examinar todos os arquivos PHP. Comece criando uma lista de arquivos PHP suspeitos que você quer investigar. Veja algumas maneiras de determinar quais arquivos PHP são suspeitos:

  • Como você já atualizou os arquivos do CMS, verifique somente os arquivos que não fazem parte dos arquivos ou pastas padrão do CMS. Isso eliminará um grande número de arquivos PHP e deixará você com menos arquivos a serem examinados.
  • Classifique os arquivos do site pela data da última modificação. Procure arquivos que foram modificados nos meses anteriores ao momento em que você descobriu pela primeira vez que o site foi invadido.
  • Classifique os arquivos do site por tamanho. Procure os arquivos muito grandes.

Observação: os invasores geralmente injetam scripts nos arquivos index.php, wp-load.php, 404.php e view.php.

Etapa 4

Depois de fazer uma lista de arquivos PHP suspeitos, verifique se eles são maliciosos. Se você não estiver familiarizado com PHP, esse processo pode ser mais demorado. Por isso, recomendamos consultar a documentação sobre PHP. Se não tiver muito conhecimento sobre codificação, recomendamos que você procure ajuda. Enquanto isso, existem alguns padrões básicos que você pode procurar para identificar arquivos maliciosos.

Se você usa um CMS e não tem o hábito de editar esses arquivos diretamente, compare os arquivos no seu servidor com uma lista de arquivos padrão entregues com o CMS, plug-ins e temas. Procure arquivos que não deveriam estar presentes e arquivos com tamanhos maiores que o padrão.

Analise os arquivos suspeitos já identificados para procurar blocos de código ofuscados. Esses blocos podem parecer uma combinação de letras e números aparentemente sem sentido. Em geral, o código ofuscado é precedido por uma combinação de funções PHP, como base64_decode, rot13, eval, strrev, gzinflate, embora às vezes até mesmo essas funções estejam ofuscadas. Veja abaixo um exemplo desse bloco de código. Muitas vezes, todo esse código está em uma linha longa de texto, o que faz com que ele pareça menor do que realmente é:

  $O_O0O_O0_0=urldecode("%6E1%7A%62%2F%6D%615%5C%76%740%6928%2D%70
  %78%75%71%79%2A6%6C%72%6B%64%679%5F%65%68%63%73%77%6F4%2B%6637%6A");
  $OO0_0OO0__=$O_O0O_O0_0{26}.$O_O0O_O0_0{6}.$O_O0O_O0_0{10}.$O_O0O_O0_0{30}

Verificar se o site está limpo

Depois de remover os arquivos invadidos, verifique se o trabalho valeu a pena. Você se lembra das páginas sem sentido identificadas anteriormente? Use a ferramenta Fetch as Google novamente para ver se elas ainda existem. Se a resposta do Fetch as Google for "Não encontrado", é provável que o site esteja em boas condições.

Também é possível seguir as etapas no Solucionador de problemas para sites invadidos a fim de verificar se ainda há conteúdo invadido no site.

Como evitar ser invadido novamente?

A correção de vulnerabilidades é uma etapa final essencial para a correção do site. Um estudo recente descobriu que 12% dos sites invadidos são invadidos novamente dentro de 30 dias. É importante saber exatamente como o site foi invadido. Leia o guia Formas mais comuns de invasão de websites por criadores de spam para começar sua investigação. No entanto, se você não conseguir descobrir como seu site foi invadido, veja abaixo uma lista de verificação de medidas que você pode tomar para reduzir as vulnerabilidades do site.

  • Faça uma varredura regularmente no seu computador: use um programa antivírus confiável para verificar vulnerabilidades ou a presença de vírus.
  • Troque suas senhas regularmente: trocar regularmente as senhas de todas as contas do seu website, como a senha do provedor de hospedagem, do FTP e do CMS, pode impedir o acesso não autorizado ao site. É importante criar uma senha forte e exclusiva para cada conta.
  • Use a autenticação de dois fatores (2FA): recomendamos a ativação da 2FA em todos os serviços que exigem login. A 2FA dificulta o login de hackers, mesmo que eles roubem sua senha.
  • Atualize regularmente o CMS, plug-ins, extensões e módulos: se tudo estiver certo, você já deve ter feito esta etapa. Muitos sites são invadidos por causa de um software desatualizado sendo executado no site. Alguns CMSs são compatíveis com a atualização automática.
  • Considere se inscrever em um serviço de segurança para monitorar o site: há muitos serviços excelentes que podem ajudar você no monitoramento do site por uma pequena taxa. Recomendamos que você faça registro em um deles para manter o site seguro.

Outros recursos

Se você ainda estiver com problemas para corrigir o site, há mais alguns recursos que podem ajudá-lo.

Estas ferramentas fazem a varredura do site e podem encontrar conteúdos problemáticos. O Google não desenvolve nem oferece suporte para elas, a não ser a VirusTotal.

Virus Total, Aw-snap.info, Sucuri Site Check, Quttera: são algumas ferramentas que podem fazer a varredura do site em busca de conteúdos problemáticos. Esses scanners não garantem a identificação de todos os tipos de conteúdo problemático.

Veja outros recursos do Google que podem ajudar você: