Identificar a vulnerabilidade

Como pode haver várias invasões independentes ao mesmo tempo, mesmo se você for capaz de encontrar e corrigir uma vulnerabilidade, recomendamos que continue a procurar outras. Comece sua investigação lendo sobre as formas mais comuns de invasão de websites por criadores de spam.

Será necessário:

  • Acesso de administrador de shell/terminal aos servidores do seu site, Web, banco de dados, arquivos.
  • Conhecimento de comandos de shell/terminal.
  • Familiaridade com o código (como PHP ou JavaScript).
  • Capacidade para executar dois scanner antivírus.

Próximas ações:

Cobriremos várias formas comuns pelas quais um site pode ser comprometido. Com um pouco de sorte, uma dessas vulnerabilidades se aplicará a seu site ou lançará luz sobre outras possibilidades.

Esteja ciente de que os scanners de vulnerabilidade diferem dos scanners antivírus. Os scanners de vulnerabilidade podem ser muito mais invasivos e têm maior potencial de causar danos indesejados ao site. Siga todas as instruções, como fazer o backup de seu site, antes de executar o scanner.

As possíveis vulnerabilidades a serem investigadas incluem:

1. Computador do administrador infectado por vírus

No computador infectado por vírus de um administrador, o hacker pode ter instalado spyware para registrar a digitação do administrador local.

  • Verifique se há vírus nos sistemas do administrador. Recomendamos a execução de vários scanners antivírus ou scanners de vírus de boa reputação em cada computador usado por um administrador para fazer login no site. Uma vez que novas infecções de malware estão constantemente sendo elaboradas para driblar os scanners, esta ação não é um método infalível para a detecção de vírus. Como os scanners antivírus podem indicar casos falsos positivos, a execução de vários scanners pode fornecer mais pontos de dados para determinar se existe uma vulnerabilidade. Considere também examinar seu servidor e todos os dispositivos usados para atualizar ou postar no site, como método de precaução.
    • Se o scanner antivírus detectar spyware, vírus, cavalo de troia ou qualquer outro programa suspeito, investigue os registros de servidor do site para verificar a atividade do administrador que é o proprietário do computador infectado.
    • Os arquivos de registro podem ter sido alterados pelo hacker. Se não, correlacionar o nome de usuário do administrador com comandos suspeitos no arquivo de registro é uma evidência a mais de que um vírus no sistema do administrador fez com que o site se tornasse vulnerável.

2. Senhas fracas ou reutilizadas

Decifrar uma senha fraca pode ser relativamente fácil para hackers e pode fornecer acesso direto a seu servidor. Senhas fortes têm uma combinação de letras e números, pontuação, sem palavras ou gírias que podem ser encontradas no dicionário. As senhas devem ser utilizadas em um só aplicativo, e não reutilizadas em toda a Web. Quando as senhas são reutilizadas, basta apenas uma brecha de segurança em um aplicativo para que o hacker encontre o login para tentar reutilizar essa senha em outro lugar.

  • No registro do servidor, verifique se há atividade indesejável, como várias tentativas de login do administrador ou um administrador executando comandos inesperados. Anote quando a atividade suspeita ocorreu, pois compreender quando a invasão começou ajuda a determinar quais backups ainda podem estar limpos.

3. Software desatualizado

Verifique se o servidor tem instalada a última versão do sistema operacional, sistema de gerenciamento de conteúdo, plataforma de blogs, aplicativos, plug-ins etc.

  • Pesquise (talvez por meio de uma pesquisa na Web) todo o software instalado para determinar se sua versão contém um aviso de segurança. Se tiver, a possibilidade de que um software desatualizado tenha causado a vulnerabilidade em seu site é bastante grande.
  • Como prática recomendada, procure sempre manter o software de seus servidores atualizado, independentemente de o software desatualizado ter resultado em problemas de vulnerabilidade naquele determinado momento.

4. Práticas de codificação permissivas, como redirecionamentos abertos e injeções de SQL

  • Redirecionamentos abertos
  • Redirecionamentos abertos são codificados para que a estrutura de URL permita a adição de outro URL, de modo que os usuários possam chegar a um arquivo ou página útil do site. Por exemplo:

    http://example.com/page.php?url=http://example.com/good-file.pdf
    Os hackers podem abusar dos redirecionamentos abertos adicionando a página com spam ou malware ao redirecionamento aberto  do site, semelhante a isto:
    http://example.com/page.php?url=<malware-attack-site>

    • Se seu site usou redirecionamentos abertos em excesso, você provavelmente percebeu a mensagem nos exemplos de URLs do Search Console, que incluíam redirecionamentos abertos para um destino indesejável.
    • Para evitar redirecionamentos abertos no futuro, verifique se "permitir redirecionamentos abertos" está ativado por padrão em seu software, se seu código pode proibir redirecionamentos fora do domínio ou se é possível assinar o redirecionamento para que apenas aqueles com URLs com hash correto e com a assinatura criptográfica possam ser redirecionados.
  • Injeções de SQL
  • As injeções de SQL ocorrem quando um hacker é capaz de adicionar comandos maliciosos a campos de entrada do usuário executados por seu banco de dados. As injeções de SQL atualizam registros em seu banco de dados com conteúdo de spam ou malware indesejado ou enviam dados valiosos para o hacker. Se seu site usa um banco de dados, e especialmente se seu site foi infectado com o tipo de malware injeção de SQL, é possível que o site tenha sido comprometido por uma injeção de SQL.

    • Faça login no servidor do banco de dados e procure conteúdo suspeito no banco de dados, como campos de texto que antes eram normais, mas que agora mostram iframes ou scripts.
    • Para valores suspeitos, verifique se a entrada do usuário foi validada e devidamente codificada ou, ainda, digitada de modo que não possa ser executada como código se a entrada do usuário não for verificada antes do processamento do banco de dados. A injeção de SQL pode ser uma vulnerabilidade de causa raiz em seu site.

Próxima etapa

A próxima etapa do processo é Fazer a limpeza e a manutenção do site.