Exploit encadeado de PHP2Shell obtém root em 25 servidores, incluindo servidores do Governo dos EUA

Artigo original ↗ Discussão no Hacker News ↗

Uma cadeia de exploração divulgada recentemente, direcionada a uma vulnerabilidade crítica de análise de requisições do PHP (“PHP2Shell”), foi usada para obter acesso root em pelo menos 25 servidores, incluindo sistemas atrás de um grande fornecedor de firewalls e um ambiente associado ao governo dos EUA. Comentadores debatem quão severa e disseminada a falha subjacente do PHP realmente é, observando que ela é executada antes do código da aplicação ou de verificações de autenticação e frequentemente precisa ser encadeada com elevações de privilégio no kernel Linux, ao mesmo tempo em que apontam que o impacto no mundo real foi limitado por detalhes de implantação, patches e configuração. O incidente levanta preocupações mais amplas sobre a fragilidade da infraestrutura central da internet, a postura de segurança de firewalls comerciais e sistemas do setor público, e o papel crescente de ferramentas de IA tanto para encontrar quanto para explorar esses bugs.

Severidade e explorabilidade do PHP2Shell

  • Problema central: RCE na análise de requisições do PHP, antes de qualquer código da aplicação ou autenticação, então código PHP “seguro” e verificações de autenticação típicas não ajudam.
  • Alguns argumentam que foi superestimado porque:
    • Apenas um pequeno número de sistemas reais (25 de ~15 mil verificados) acabou totalmente comprometido por essa cadeia.
    • Muitas implantações de PHP não eram realmente exploráveis na prática devido a detalhes de implantação ou patches.
  • Outros insistem que é um dos piores bugs dos últimos anos:
    • RCE pré-autenticação, em toda a plataforma, em um interpretador onipresente.
    • As únicas mitigações confiáveis antes do patch eram basicamente “não executar PHP” ou tirar os serviços do ar.
  • O desafio “stealmybitcoin” causou confusão:
    • Inicialmente mal configurado (sem um endpoint PHP real), depois corrigido e explorado em cerca de 2 horas.
    • Foi usado para argumentar tanto que era “mais difícil do que o anunciado” quanto que era “definitivamente real e perigoso.”

Cadeia de ataque e sistemas afetados

  • As intrusões relatadas usaram uma cadeia:
    • PHP2Shell para execução inicial de código como www-data.
    • Uma elevação local de privilégios no kernel Linux (XFRM ESP-in-TCP / provavelmente “Dirty Frag”) para obter root.
  • Apenas PHP sem patch em uma plataforma específica de firewall foi afetado neste incidente; o CVE público foi corrigido a montante.

Gerenciamento de firewall, stack do fornecedor e má configuração

  • Forte crítica ao fato de as interfaces administrativas do firewall estarem expostas diretamente à internet em vez de isoladas em redes de gerenciamento.
  • Consenso no tópico de que o fornecedor é a Palo Alto Networks (PAN-OS), com base em:
    • Versões de PHP mencionadas.
    • Configuração do SELinux.
    • Stack Appweb + PHP.
  • Debate sobre por que um “firewall de classe mundial” ainda executa PHP:
    • Contexto histórico: PHP era uma escolha natural nos anos 2000.
    • Uma vez que grandes interfaces gráficas existem, reescrever para uma stack mais segura/simples é caro, então o legado persiste.

IA, hype e desenvolvimento de exploit

  • Vários comentaristas relatam LLMs (Claude Code, DeepSeek, Qwen, outros) ajudando na construção e otimização de exploits (por exemplo, exaustão de memória mais eficiente).
  • Visões divididas:
    • Alguns veem o papel da IA e a narrativa da mídia como “marketing de segurança de IA” exagerado e caça-cliques.
    • Outros argumentam que os críticos estão minimizando uma mudança genuína e habilitada por IA na capacidade de exploração.

Superfície de ataque do kernel Linux e hardening

  • Preocupação de que o Linux venha com uma superfície de ataque muito ampla:
    • Recursos como XFRM, MPTCP, algif_aead, SMB, io_uring+DMABUF frequentemente ativados por padrão.
  • Alguns usuários respondem auditando módulos carregados e desativando subsistemas desnecessários.
  • Reconhecimento de que distros de uso geral ativam “tudo” por compatibilidade, enquanto configurações endurecidas (por exemplo, Gentoo com kernels personalizados, Android + SELinux) podem reduzir a exposição.

Preocupações mais amplas com segurança e confiança

  • Frustração de que sistemas adjacentes ao governo, com exigências regulatórias rígidas, ainda exponham equipamentos mal configurados e vulneráveis.
  • Alguns questionam se a nuvem pública / SaaS (por exemplo, O365) é significativamente mais segura, dadas as constantes novas cadeias de exploração.
  • Uma minoria especula sobre mover mais funcionalidades críticas para hardware/FPGA para obter determinismo, enquanto outros observam que isso tornaria mais difícil corrigir falhas de projeto.