Cibersegurança

Hacker usa PHP2Shell e invade em 19 horas servidor com isca de US$ 2 mil em bitcoin

Adrian Kessler
Adicione-nos no Google

Um servidor com uma cópia desatualizada do PHP, mantido on-line com a chave de uma carteira de bitcoin como isca, não durou nem um dia. Um pesquisador que usa o pseudônimo KillaBoi invadiu o sistema por meio do PHP2Shell, o par de falhas críticas na linguagem que está por trás da maior parte da web, e extraiu a chave. Naquele mesmo fim de semana, uma honeypot operada pelo responsável pela segurança da Perplexity registrou um invasor fazendo o mesmo em um servidor real — um episódio que derruba a confortável teoria de que essas brechas eram complicadas demais para alguém explorar.

Isso importa para quem mantém um site e para quem tem dados armazenados em um deles. O PHP está na base do WordPress, Drupal, Joomla e da maioria dos serviços de hospedagem compartilhada, e essas falhas podem permitir que alguém sem conta execute comandos no servidor. Desde que as correções foram disponibilizadas, o principal argumento para esperar era que as tentativas públicas de ataque continuavam fracassando. Os dois resultados derrubam esse argumento.

O desafio, chamado Steal My Bitcoin, foi publicado em um site próprio e anunciado em uma postagem em um fórum. Seu criador, que publicou sob o nome cloudlandsdev, escreveu: «Fiz isso porque estou curioso para saber se alguém por aí descobriu como realmente usar essa RCE do PHP. Passamos os últimos dias em pânico. Divirtam-se!» A recompensa começou em cerca de US$ 502 e cresceu com doações até chegar a 0.02511679 BTC, equivalentes a US$ 2.021,22 quando foi reivindicada, cerca de 19 horas após o lançamento, segundo o Tom’s Hardware. O servidor não aguentou o tráfego de quem tentava invadi-lo, e o espaço de armazenamento limitado impediu que todos os registros fossem mantidos.

Em seguida, KillaBoi publicou uma prova de conceito no GitHub. Mark Maunder, fundador da empresa de segurança para WordPress Wordfence, chamou a publicação de «a melhor explicação que você vai encontrar sobre como é difícil explorar o #php2shell», destacando o nível de precisão exigido pelo ataque. Difícil, ao que parece, não significava demorado.

O resultado mais preocupante veio de fora do desafio. Adel Karimi, líder de detecção e resposta da Perplexity, disse que suas honeypots registraram uma execução remota de código confirmada em um servidor Apache com PHP 8.4.26. «Agora temos uma RCE confirmada, com divulgação de memória aproveitável — não apenas uma falha seguida por um processo suspeito», escreveu ele, segundo o BleepingComputer. Marcus Hutchins, pesquisador de ameaças da Expel que vinha acompanhando relatos de ataques bem-sucedidos, chamou o caso de «de longe a confirmação de maior qualidade de exploração do php2shell em ambiente real que vi até agora». Até então, Cloudflare, watchTowr, Patchstack e outras empresas de segurança só haviam registrado tentativas malsucedidas, e a equipe de inteligência de ameaças da Amazon tinha observado o início de varreduras quatro dias antes da distribuição das correções.

Nenhum dos dois resultados significa que todo servidor desatualizado será invadido amanhã. A chave recuperada por KillaBoi não correspondia ao endereço da carteira anunciado pelo site; o organizador chamou isso de erro de configuração e disse que os fundos seriam transferidos, segundo o Cointelegraph, e o site de segurança Cyberpress observa que as evidências públicas mostram a recuperação de uma chave, não o roubo da recompensa. O exploit publicado também foi ajustado para uma compilação específica do PHP e falha em outras compilações da mesma versão, portanto não é uma ferramenta de usar com um clique. O que acabou foi a defesa de que ninguém havia conseguido fazer o ataque funcionar.

A exposição é global. Agências governamentais dos Países Baixos, da Austrália, do Japão e da Finlândia tiraram sites importantes do ar enquanto as correções eram preparadas, informou o Cointelegraph. Uma contagem da Shodan feita pela empresa de segurança Mallory encontrou cerca de 884 mil hosts expostos à internet que anunciavam uma versão do PHP sem receber mais correções oficiais — 59% dos cerca de 1,5 milhão que revelam essa informação, segundo o Notebookcheck. São contagens baseadas em banners, não vítimas confirmadas, porque distribuições Linux muitas vezes corrigem pacotes antigos sem alterar o número da versão.

Para quem administra sites, a solução não mudou. As versões corrigidas são PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, publicadas em 21 de outubro para as vulnerabilidades CVE-2026-109618 e CVE-2026-109619, ambas com nota 9,2 em 10. Em serviços de hospedagem compartilhada, a atualização cabe à empresa de hospedagem, não é feita por uma atualização do WordPress ou de um plugin; por isso, a pergunta útil para o seu provedor é qual compilação do PHP seu site usa e quando ela foi corrigida. A agência de cibersegurança dos EUA, CISA, orientou as organizações que não podem atualizar — ou que ainda usam PHP 8.1 ou versões anteriores — a tirar esses sistemas do ar até que isso seja possível.

O próximo problema já está em aberto. Na sexta-feira, a equipe do PHP publicou uma solução temporária para uma terceira falha de execução remota de código, CVE-2026-115560, que ainda não tem correção e afeta apenas sistemas «com uma combinação incomum de configuração e código de aplicação». Até que uma correção seja lançada, os desenvolvedores do PHP recomendam desativar a configuração session.upload_progress, a mesma medida indicada antes das correções do PHP2Shell. O suporte de segurança ao PHP 8.2 termina em 31 de dezembro de 2026, e os servidores que nunca deixaram o PHP 8.1 já passaram do prazo de suporte.

Tags: , , , , ,

Adicione-nos no Google

Discussão

Há 0 comentários.