*Este artigo foi escrito originalmente em setembro de 2016. Leia com cuidado! 

Se você quer entender como analisar completamente a segurança de um site, e se proteger de malwares, veja o nosso guia e cuide de suas informações sensíveis na Internet. 

Neste artigo, veremos uma versão modificada do backdoor WSO FilesMan, que é um webshell PHP projetado para controlar todo o sistema. WSO significa “Web Shell by Orb”, e tem a capacidade de se mascarar como uma página de erro contendo um formulário de login oculto.

https://www.youtube.com/shorts/X6j_RSLDHlg

Identificando Malware Web

Aqui está apenas um trecho do código que foi nomeado prbnts.php e colocado dentro da pasta /wp-includes/js/jquery/ui/, que geralmente contém apenas arquivos JavaScript (.js):

<?php

eval(gzinflate(base64_decode(“5b37W9tG0zD8c+7r6v8gVLeyG2NsQ9IUsBNCICEHSDkkaSCv

(…)

?>

Como podemos ver, o arquivo é codificado em base64 e compactado com a função gzinflate do PHP. Quando o decodificamos e descompactamos, obtemos algo em um formato mais legível:

$color = “#df5”;

$default_action = ‘FilesMan’;

$default_use_ajax = true;

$default_charset = ‘Windows-1251’;

if(!empty($_SERVER[‘HTTP_USER_AGENT’])) {

  $userAgents = array(“nouseragenthere”);

  if(preg_match(‘/’ . implode(‘|’, $userAgents) . ‘/i’, $_SERVER[‘HTTP_USER_AGENT’])) {

    header(‘HTTP/1.0 404 Not Found’);

exit;

  }

}

Este código nos dá algumas pistas de que o arquivo parece malicioso e não deveria estar lá. 

Mesmo se você não tiver experiência com programação, você pode apenas pesquisar as primeiras quatro linhas em um buscador e já mostrará algumas dicas de que este arquivo é um backdoor e as primeiras descobertas datam do final de 2010.

Mais especificamente, o arquivo malicioso é um PHP Web Shell, ou apenas PHP Shell, que é um shell envolvido em um script PHP e que usa funções PHP integradas para executar comandos no sistema. 

Com ele, podemos fazer qualquer coisa no servidor onde ele está localizado, como fazer upload e download de arquivos, instalar, executar ou excluir programas e às vezes até criar ou excluir usuários (dependendo das permissões do usuário do servidor web). É semelhante a ter uma conexão SSH (Secure SHell) com o servidor.

Você consegue imaginar o dano que isso pode causar? Se você tem seu shell da web em um servidor, você literalmente “é dono” (owns) desse servidor. Entendeu? Agora você já sabe por qual motivo as pessoas dizem que alguém foi “ownado” quando foram hackeados. 

Aqui estão algumas das funções usadas para executar comandos do sistema com PHP, de acordo com a documentação oficial:

• system() – Execute an external program and display the output
• exec() – Execute an external program
• shell_exec() – Execute command via shell and return the complete output as a string
• passthru() – Execute an external program and display raw output

Por que alguém iria querer colocar um web shell e controlar seu servidor? 

Em primeiro lugar, uma web shell é um backdoor, ele dá acesso direto ao seu servidor sem ter que explorar uma vulnerabilidade repetidamente, então dá aos invasores uma maneira persistente de acessar o servidor (a menos que você descubra sobre isso e remova o arquivo). 

Outro motivo seria usar seu servidor como um computador zumbi, isto é fazendo parte de uma botnet, e forçá-lo a executar ataques junto com outras máquinas infectadas.

Alguns invasores também usam máquinas infectadas para se esconder da polícia, redirecionando (pivoting) sua conexão por meio desses servidores e tornando mais difícil para as autoridades investigarem e detectarem a origem dos ataques.

Por que seu site foi hackeado? Como ele foi infectado? 

Bem, assim como os vírus, o malware web também tem muitas variações diferentes. Os desenvolvedores de malware podem mudar algumas coisas para evitar a detecção de ferramentas baseadas em padrões e assinaturas (pattern matching). 

Neste caso em particular, a vítima estava usando a versão 4.4.2 do WordPress, que já tinha 7 meses de lançamento na data do ataque e poderia muito bem ser uma das causas da infecção. Porém vamos analisar mais profundamente antes de tirar conclusões precipitadas.

Procurando encontrar a fonte de invasões em sites WordPress, geralmente olhamos primeiro as pastas dos temas e plugins, uma vez que essas são as formas mais comuns de explorar uma vulnerabilidade e colocar um shell da web ou algum outro tipo de malware nessas aplicações.

A equipe de desenvolvimento do WordPress tem feito um ótimo trabalho ao proteger os arquivos do núcleo do WordPress (que inclui pastas wp-admin e wp-includes e arquivos raiz), mas os temas e plugins são em sua maioria códigos de terceiros desenvolvidos por outras pessoas ou organizações que muitas vezes você não conhece e não sabe se pode confiar. 

É por isso que é importante avaliá-los com cuidado antes de começar a usá-los em seu site! As ferramentas de segurança de aplicações que fazem Análise de Composição de Software (SCA, em inglês) podem ajudar nessa tarefa.

Como podemos ver, a pasta de temas possui apenas alguns temas padrões do WordPress que vêm com a instalação do software. A primeira coisa que recomendamos aqui é remover tudo do site que você não está usando, incluindo esses temas.

Por que fazer isso? Porque caso alguém encontre uma vulnerabilidade em um plugin ou tema que você tem em seu site, mas não o esteja usando no momento, essa pessoa ainda poderá explorar a vulnerabilidade e comprometer seu site.

A remoção de temas e plugins não utilizados reduz a superfície de ataque que um usuário malicioso pode explorar em seu site. Fica a dica!

Agora, a pasta de plugins tem algo que nos chamou a atenção: o plugin jetpack. Este plugin é feito pela equipe do WordPress.com e é amplamente utilizado em muitos sites WordPress. É bem mantido e atualizado com frequência por sua equipe de desenvolvimento. O problema é que o Jetpack tem várias vulnerabilidades públicas, como podemos ver no  site WPScan.com:

Você consegue adivinhar qual versão do plugin Jetpack estava no site? Parabéns se você adivinhou a versão 2.5.2! Foi lançado em setembro de 2013. Três anos antes de quando esta análise foi feita originalmente!

Embora seja difícil detectar a falha específica que um invasor conseguiu explorar no site sem verificar por todos os logs (se você tiver acesso a eles), estou confiante de que esta versão desatualizada do plug-in foi provavelmente uma das causas dessa invasão.

Como saber se seu site foi infectado? 

Bem, se quiser verificar se o seu site pode ter um desses arquivos maliciosos, você pode fazer o seguinte:

• Faça login em seu servidor usando SSH (Secure Shell)
• Vá para a pasta do WordPress
• Execute este comando: “grep -r eval (gzinflate (base64_decode *”
• Se algum dos resultados tiver uma string codificada longa após esse código, é melhor investigá-lo mais a fundo.

Se você já está infectado, mas não tem acesso ao seu servidor via SSH ou não sabe como fazer isso e só tem acesso FTP a ele, você pode fazer o seguinte:

• Baixe a mesma versão do WordPress que você usa em seu site via worpress.org
• Remova as pastas wp-admin e wp-includes do seu site (usando SSH ou SFTP/S)
• Extraia o arquivo zip e carregue apenas as novas pastas wp-admin e wp-includes para o seu site (Aviso: não substitua as pastas apenas, pois podem conter novos arquivos e eles não serão removidos! Remova os antigos antes de enviar as novas pastas)
• Se isso não corrigiu seu site ainda, pelo menos agora você restringiu o problema à pasta wp-content e pode começar a procurar por arquivos suspeitos lá. Verifique sua pasta de plugins e temas (themes). Remova tudo o que você não está usando no momento em seu site. Certifique-se de que seus plugins estejam atualizados e não tenham nenhuma vulnerabilidade conhecida publicamente.
• A maioria dos clientes FTP possui mecanismos de pesquisa que você pode usar para pesquisar strings como “base64_decode”. Comece com isso!

Esperamos que esse conteúdo tenha ajudado você! Se tiver outras dicas e dúvidas, sinta-se à vontade para comentar.

E não esqueça de continuar acompanhando o blog da HostGator para mais conteúdos sobre tecnologia, negócios e marketing!