Worm autorreplicante integrado em 42 pacotes NPM do TanStack

Devido à comprometimento do processo de formação de releases baseado no GitHub Actions no projeto TanStack, os atacantes conseguiram publicar 84 versões maliciosas no repositório NPM, que abrangem 42 pacotes NPM do conjunto TanStack. Alguns dos pacotes comprometidos tinham mais de 10 milhões de downloads por semana.

O acesso à publicação de releases foi obtido devido à configuração incorreta do pull_request_target 'Pwn Request' no GitHub Actions (o apontamento da máscara nas configurações levou à execução do pull_request_target para pull requests em forks externos), contaminação do cache do GitHub Actions através do fork e a possibilidade de extração do token OIDC da memória do processo runner em execução (Runner.Worker) através da leitura do conteúdo /proc//mem.

Os pacotes NPM com alterações maliciosas foram publicados no dia 11 de maio, entre 22:20 e 22:26 (MSK), detectados após 20 minutos e bloqueados cerca de uma hora e meia depois. Para cada um dos pacotes NPM afetados, foram lançadas duas versões maliciosas, que integravam um código para ativar o worm mini-shai-hulud, que buscava tokens e credenciais no ambiente atual. Caso um token de conexão ao diretório NPM fosse descoberto, o worm publicava automaticamente novas releases maliciosas para os pacotes em desenvolvimento no ambiente atual, afetando a árvore de dependências. Desta maneira, mais de 400 pacotes NPM foram comprometidos, utilizando pacotes TanStack entre suas dependências.

O worm estava localizado no arquivo router_init.js e se ativava quando o pacote comprometido era instalado manualmente pelo desenvolvedor ou automaticamente em um ambiente de integração contínua através dos comandos 'npm install', 'pnpm install' ou 'yarn install'. Após a ativação, o worm buscava tokens no sistema para NPM (~/.npmrc), AWS, GCP, Azure, HashiCorp e Kubernetes K8s, além de chaves privadas SSH. Os dados encontrados eram enviados aos criminosos através do mensageiro P2P descentralizado getsession.org.

O worm estava programado para realizar ações destrutivas caso o token NPM interceptado fosse revogado — um script era configurado para execução periódica ~/.local/bin/gh-token-monitor.sh, que a cada 60 segundos verificava a atividade do token através de uma chamada ao api.github.com/user e, caso o token fosse revogado, executava o comando 'rm -rf ~/'.

Fonte: opennet.ru

Compre hospedagem confiável para sites com proteção contra DDoS, servidores VPS VDS 🔥 Compre hospedagem confiável para sites com proteção contra DDoS, servidores VPS VDS | ProHoster