Um site que vende fica no ar 24 horas por dia, inclusive nas horas em que ninguém está olhando. Foi numa dessas horas silenciosas, na segunda-feira 14 de setembro, que pelo menos 1.500 sites feitos em WordPress baixaram uma atualização com cara de rotina. Não era rotina. Era um ataque, e o caso vale para qualquer dono de site, porque é no WordPress que roda boa parte dos sites de pequena empresa no Brasil.
O plugin comprometido foi o Admin Menu Editor Pro, na versão paga. O servidor oficial que entrega as atualizações desse plugin foi invadido, e as versões 2.35 e 2.36 saíram de lá já com um código escondido. Um arquivo chamado includes/wp-user-consent.php instalava um web shell e criava um usuário administrador que ninguém tinha pedido. Segundo o desenvolvedor Janis Elsts, citado pelo BleepingComputer, a versão maliciosa foi instalada em “pelo menos 1.500 sites, muitas vezes vários por cliente”, atingindo cerca de 230 clientes no primeiro golpe. A última versão confiável era a 2.34, e o desenvolvedor chegou a publicar uma 2.36 corrigida ainda no mesmo dia, mas quem clicou em atualizar dentro daquela janela já tinha deixado o convidado entrar.
A versão gratuita, distribuída pelo repositório oficial do WordPress, não foi afetada. O problema mora num detalhe que a maioria dos donos de site nunca parou para pensar: de onde vem cada atualização que entra sozinha no painel. Abaixo, o que dá para fazer nesta semana, em quatro passos, para não ser o próximo da lista.
Passo 1: liste os plugins pagos que se atualizam sozinhos
Plugin gratuito do repositório oficial passa por uma revisão da equipe do WordPress antes de chegar até você. Plugin pago costuma buscar a atualização direto no servidor de quem vende. Quando esse servidor cai nas mãos erradas, a atualização automática deixa de ser comodidade e vira porta de entrada. Foi exatamente o que aconteceu aqui: quem confiava no botão de atualizar recebeu o ataque de bandeja. Abra a lista de plugins do seu site e marque quais são pagos e puxam versão de fora do repositório oficial. São esses que carregam o risco do servidor do fornecedor, e são esses que merecem um segundo olhar antes de cada atualização.
Passo 2: mantenha um backup diário de antes da atualização
A recomendação do próprio desenvolvedor para quem foi atingido é direta: restaurar o site a partir de um backup anterior a 14 de setembro. Repare no que isso significa no dia a dia. Quem tinha backup diário resolve o estrago em poucos minutos, voltando o site para a véspera do ataque. Quem não tinha vai limpar arquivo por arquivo, conta por conta no banco de dados, ou refazer o site do zero. O mesmo problema custa vinte minutos para um e uma semana para o outro. A diferença entre os dois não é sorte. É o backup que estava rodando ontem à noite.
Passo 3: procure a conta de administrador que você não criou
O ataque deixa rastro, e dá para checar sem ser técnico. Entre no painel e veja a lista de usuários. Qualquer administrador que você não reconhece é motivo para parar tudo. Alguns sinais concretos que apareceram nesse caso:
- Um usuário administrador que você não criou nem autorizou.
- Um arquivo includes/wp-user-consent.php dentro da pasta do plugin.
- Uma pasta /wp-content/object-cache/ que surgiu sem você instalar nenhum sistema de cache.
- Lentidão nova ou redirecionamentos estranhos que começaram depois de 14 de setembro.
Se qualquer um deles aparecer, tire o site do ar antes de investigar. Um site invadido que continua no ar vira máquina de espalhar o problema para quem visita, e é assim que o Google acaba descobrindo antes de você.
Passo 4: faça a conta do dia fora do ar antes que ele chegue
Site comprometido não perde só o dia do susto. O Google pode marcar o endereço como perigoso, e o navegador passa a mostrar aquela tela vermelha de aviso para cada visitante, mesmo depois de o site já estar limpo. Some o que costuma vir junto: as vendas paradas enquanto o site está fora, o custo de quem vai fazer a limpeza, e os dias até o Google voltar a confiar no endereço. A conta cabe em uma linha. Pegue quanto o seu site fatura por dia e multiplique pelos dias que ele levaria para voltar limpo. Esse é o valor que um backup automático, que custa pouco por mês, protege todo dia sem você perceber.
Cuidar disso é rotina, não emergência: backup automático rodando, atualização de plugin feita com critério e uma olhada no painel de tempos em tempos. É o trabalho que a Lynx Web faz na otimização e manutenção de sites, para o site seguir seguro e no ar enquanto você cuida de vender. No fim, a conta do backup é sempre menor que a conta do site parado.
