O ataque cross-ecosystem que sacudiu Packagist: quando PHP e Node permitem portas traseiras em CI

Um recente ataque coordenado à cadeia de fornecimento comprometeu oito pacotes publicados em Packagist, introduzindo código malicioso projetado para baixar e executar um binário Linux hospedado em um lançamento do GitHub. O que torna esta campanha particularmente preocupante é a técnica de “colocação de cross-ecosystem”: os atacantes não modificaram o ficheiro composer.json (o ponto que normalmente revisam equipamentos que analisam dependências PHP), mas o package.json que acompanha projetos que empacotam ferramentas de build JavaScript juntamente com código PHP, permitindo que scripts de instalação de Node sejam executados inadvertidamente em instalações ou processos de build.

O instalador malicioso adiciona um programa pós-install que tenta obter um executável a partir de um URL do GitHub Releases (indicada publicamente como apontando para um repo que já não existe), gravá- lo em /tmp/.sshd, outorgar-lhe permissões de execução com chmod e chmod lançar em segundo plano. Além disso, de acordo com a análise, o instalador tenta esconder a sua atividade deshabilitando a verificação TLS e suprimindo erros. Isto cria uma janela de execução remota durante a instalação ou tarefas da CI que pode resultar em roubo de segredos, pivoteo dentro de ambientes de build ou instalação de portas traseiras em infraestruturas produtivas.

Socket relatou que as versões maliciosas já foram retiradas de Packagist, mas sua pesquisa encontrou referências do mesmo payload em 777 arquivos no GitHub, incluindo pelo menos duas inserções dentro de fluxos de trabalho do GitHub Actions. Isso sugere um alcance potencialmente muito maior: alguns casos podem ser forks comprometidos, artefatos duplicados ou referências em caches, mas a presença do payload tanto em artefatos quanto em workflows mostra que os atacantes empregaram vários vetores de execução.

As consequências técnicas são claras: os projetos que empacotam dependências multi-ecossistema e que executam scripts durante a instalação ou na CI são objetivos de alto valor. Muitas ferramentas e processos assumem-se seguros porque inspecionam apenas metadados do ecossistema principal (por exemplo, composer.json em projetos PHP) e não os metadados de pacotes incluídos de outros ecossistemas (package.json, package-lock.json, yarn.lock), deixando uma superfície de ataque explorável.

Se o seu projeto pudesse ser afetado (ou simplesmente como boa higiene), actua imediatamente: primeiro, evita executar instalações ou builds em ambientes com credenciais sensíveis até ter verificado os artefatos. Inspecciona qualquer commit recente em repositórios upstream e revisa os históricos de publicação. Se você encontrou uma versão maliciosa, revoga qualquer token ou chave que pudesse ter estado no ambiente durante a instalação, porque a execução remota pode ter exfiltrado segredos. Publica uma versão limpa e notifica seus usuários de forma transparente sobre a necessidade de atualizar.

No plano operacional, implementa controles que reduzam o risco de execução de programas não autorizados: configura CI para não executar workflows de forks automaticamente, usa runners com permissões mínimas e isoladas, emprega a opção de ignorar scripts em instalações automatizadas (por exemplo, npm ci --ignore-scripts ou a configuração npm config set ignore-scripts true quando aplicável), e evita descargas arbitrárias em tempo de build a partir de URLs externos sem validação. Também permite a verificação estrita de TLS em todos os processos automatizados e registra as chamadas salientes durante builds para detectar choques suspeitos.

Do ponto de vista da gestão da cadeia de fornecimento de software, adota práticas de segurança mais avançadas: gera e consome SBOMs, usa assinaturas de artefatos e verificação de procedência (por exemplo, tecnologias como Sigstore), e aplica digitalização SCA que inclua análise de package.json e workflows da CI, não apenas os manifestos do ecossistema principal. Ferramentas de segurança e plataformas como as do GitHub Actions exigem políticas rigorosas para execução de terceiros; verifique a documentação do GitHub Actions sobre proteção de workflows para reduzir a execução de código não confiável: GitHub Actions.

Para detecção e resposta, incorpora scanners que busquem scripts pós-install suspeitos, padrões de descarga de binários em /tmp, ou chamadas a domínios e repositórios incomuns. Serviços e fornecedores externos especializados na SCA podem ajudar a identificar versões maliciosas e bloqueios nas fontes de pacotes; além disso, manter políticas de aprovação para releases e exigir revisões humanas antes de publicar ou integrar mudanças em dependências críticas reduz a probabilidade de compromissos inadvertidos.

Este incidente é um lembrete de que a segurança da cadeia de abastecimento exige visibilidade transversal: não basta auditar um único ecossistema quando os projetos misturam linguagens e ferramentas. Mantenha um inventário actualizado de dependências, aplique controlos de instalação e CI defensivos, exige procedência assinada de artefatos e atua rapidamente em caso de detecção para mitigar a janela de exposição. Para entender melhor o panorama e práticas recomendadas sobre ataques à cadeia de fornecimento, consulta análise e guias práticas como os de Snyk sobre este tipo de ameaças: Snyk — Software Supply Chain Attacks, e revisa regularmente fontes oficiais e repositórios de segurança para indicadores de compromisso.