Alerta: Pacotes de Laravel em Packagist trazem backdoor e acesso remoto

Nas últimas semanas, pesquisadores de segurança descobriram uma campanha que utiliza a própria infraestrutura do ecossistema PHP para colar malware em projetos Laravel: vários pacotes publicados em Packagist foram feitos por utilitários legítimos e, na verdade, ativavam um acesso remoto persistente às máquinas afetadas. A equipe que informou o achado publicou uma análise detalhada que você pode consultar em seu blog ( Socket), e as páginas dos pacotes ainda estão acessíveis no registo público ( perfil do autor em Packagist e os pacotes individuais como nhattuanbl/lara-helper, nhattuanbl/simple-queue e nhattuanbl/lara-swagger).

A tática não era trivial: alguns dos pacotes não continham código malicioso diretamente, mas introduziam uma dependência que sim o fazia. Em particular, um dos pacotes atua como ponte e provoca que outra livraria se instale como dependência de Composer – o gestor de dependências padrão em PHP – com tudo o que isso implica ( Documentação do Composer). Essa segunda livraria inclui um arquivo PHP ofuscado que, uma vez carregado pela aplicação, estabelece comunicação com um servidor de comando e controle (C2) e abre uma porta traseira.

Os analistas descrevem que o código malicioso é projetado para dificultar a análise: o autor recorreu a técnicas de ofuscação do fluxo de controle, nomes de funções e variáveis aleatórias, além de codificar rotas e domínios. Quando o payload é executado, recolhe informações do sistema e mantém uma conexão com o C2 através do sockets TCP usando funções próprias do PHP (por exemplo, stream_socket_ client()), à espera de comandos que podem incluir execução de comandos, transferência de ficheiros, capturas de ecrã e execução de PowerShell em sistemas Windows.

O risco vai além de um simples script que é executado: Por como o código é ativado, ao iniciar a aplicação Laravel através de um provedor de serviços ou por autoloading, o malware corre dentro do mesmo processo que a aplicação web. Isso significa que herda as permissões e as variáveis de ambiente da aplicação, e você pode acessar credenciais armazenadas em .env, chaves de bases de dados, APIs e outros segredos que o projeto tenha disponíveis.

A amostra examinada tentou religar continuamente se a resposta do servidor C2, o que a torna persistente e capaz de reestabelecer comunicação quanto ao atacante reactive sua infraestrutura. Embora no momento do relatório o servidor de comando estivesse fora de linha, a presença do código em sistemas de produção representa uma ameaça real e duradoura se não estiver a funcionar.

Se o seu projeto usa pacotes de terceiros, e em particular se você depende de pacotes de autores pouco conhecidos, deve assumir uma postura defensiva. Em primeiro lugar, é preciso identificar rapidamente se algum dos pacotes assinalados está presente na árvore de dependências revisando composer.json e composer.lock e digitalizando a pasta vendo em busca de arquivos suspeitos como helpers ofuscados. Se aparecer código comprometido, o prudente é eliminar a dependência afetada, mas isso é apenas o começo.

Assume que houve compromisso: qualquer sistema que tenha carregado o código malicioso deve ser considerado potencialmente controlado. É necessário rodar todas as credenciais que poderiam ter estado acessíveis desde a aplicação (bases de dados, chaves de serviço, tokens de terceiros), auditar as saídas de rede em busca de conexões para domínios ou IPs incomuns e revisar logs para detectar atividade remota. Também é conveniente verificar a integridade e as permissões de ficheiros sensíveis e, se houver dúvidas, restaurar de cópias de segurança fiáveis e limpar o ambiente antes de o colocar em produção novamente.

Este incidente encaixa no padrão mais amplo de ataques à cadeia de fornecimento de software: atores maliciosos publicam pacotes com aparência legítima para que desenvolvedores os instalem sem suspeitar. Organizações e desenvolvedores podem reduzir o risco adotando práticas como revisar cuidadosamente a proveniência das dependências, fixar versões em composer.lock, auditar pacotes novos antes de sua inclusão e usar ferramentas de digitalização automatizada que detectem comportamentos suspeitos. Projectos especialistas e guias de segurança sobre a cadeia de fornecimento oferecem recomendações práticas que convém seguir; por exemplo, a comunidade OWASP mantém recursos de segurança na cadeia de fornecimento de software ( OWASP Supply Chain).

Para administradores e desenvolvedores PHP, também é útil conhecer as configurações de PHP que limitam vetores de ataque, como a directivadisable_functionsem php.ini, embora o malware detectado tenta sortear essas proteções, probeando múltiplos métodos para executar comandos. A página oficial do PHP documenta estas e outras funções relevantes ( disable_functions na documentação do PHP).

A lição é clara: o conforto de instalar uma utilidade do registro não pode substituir uma mínima diligência. Rever a reputação do autor, verificar o conteúdo do pacote antes de o instalar em ambientes produtivos e manter políticas de rotatividade de segredos são medidas que já não são opcionais. Se você acha que usou algum dos pacotes envolvidos, age rapidamente, documenta as ações e, se necessário, busca ajuda profissional para a resposta a incidentes.

Se você quer aprofundar o relatório técnico, o despiece da campanha e recomendações concretas estão disponíveis na análise dos pesquisadores ( Socket), e as entradas dos pacotes podem ser revistas publicamente em Packagist ( perfil do autor e as páginas de cada pacote). Para entender melhor as implicações da cadeia de abastecimento e das práticas de defesa, consulta também recursos comunitários e guias como os de OWASP e documentação oficial do Composer ( Composer).