Pacotes npm maliciosos encontrados em vários serviços de nuvem da Red Hat

 (github.com/RedHatInsights)
1 pontos por GN⁺ 4 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • O problema está aberto e, até o momento do texto, não há responsável, milestone, branch vinculada ou PR
  • Foi registrado como um incidente de segurança indicando que versões maliciosas foram encontradas em vários lançamentos npm no escopo @redhat-cloud-services/
  • Como referência, são apresentados a análise da StepSecurity e os resultados de busca do OSS Security Feed
  • A lista de impacto atualizada inclui 32 pacotes, como @redhat-cloud-services/chrome, frontend-components, rbac-client, types e vulnerabilities-client
  • As versões comprometidas mostradas na tabela são, em sua maioria, 3 por pacote, enquanto @redhat-cloud-services/vulnerabilities-client inclui apenas as versões 2.1.9 e 2.1.11
  • Considerando a tabela completa, é possível contar 95 versões comprometidas, e o título de um PR externo mencionado separadamente também aponta para 95 versions
  • A família @redhat-cloud-services/frontend-components-* e vários pacotes *-client aparecem juntos, indicando que o problema não se limita a um único pacote, mas afeta lançamentos em todo o mesmo escopo
  • Nos comentários, à pergunta “What are these?”, houve a resposta “all that module is pwned”, mostrando o entendimento de que toda a lista foi comprometida
  • DanielRuf informou que adicionou este caso ao supply-chain-incidents
  • Na atividade do GitHub, aparecem um resumo de conteúdo que referencia esta issue e um PR relacionado à detecção, mas o texto ainda não apresenta diagnóstico da Red Hat, medidas de mitigação, remoção ou versões corrigidas

Leituras relacionadas

1 comentários

 
GN⁺ 4 시간 전
Opiniões no Hacker News

  • Espero que não haja problema em retomar a discussão sobre a configuração de cooldown. O caso do axios, tanstack, @redhat-cloud-services e vários ataques recentes à cadeia de suprimentos do npm poderiam ter sido evitados se houvesse cooldown
    Se você usa Artifactory/Nexus, provavelmente isso já existe, e mesmo que não exista, é fácil configurar. Como a maioria dos comprometimentos no npm ou no PyPI foi removida em poucas horas, basta ignorar pacotes com menos de N dias desde o lançamento. Até 1 dia já ajuda, 3 dias é razoável e 7 dias é um pouco exagerado, mas funciona
    As versões mais recentes do pnpm já trazem cooldown de 1 dia por padrão: https://pnpm.io/supply-chain-security
    Se você quiser resolver isso com um clique, pode usar https://depsguard.com. É uma CLI que adiciona cooldown e configurações recomendadas para npm, pnpm, yarn, bun, uv e dependabot, e eu sou o mantenedor
    Também existe https://cooldowns.dev, mais focado em cooldown, e há scripts para ajudar com configurações locais. Tudo é open source/gratuito
    Se você já sabe editar diretamente ~/.npmrc e arquivos do tipo, provavelmente não precisa disso, mas se conhece pessoas ao seu redor que só precisam de uma correção com um clique, isso pode ajudar a evitar o próximo ataque
    Só que, quando for preciso corrigir um novo CVE crítico, será necessário contornar o cooldown, e cada ferramenta tem sua própria forma de fazer isso. Não tenho números exatos para os últimos meses, mas mesmo nesta era de descoberta de vulnerabilidades ao estilo Mythos, o risco de ataques à cadeia de suprimentos de software, como a distribuição de versões maliciosas, ainda parece maior do que o de novos CVEs zero-day

    • Como desenvolvedor de sistemas embarcados, estou acostumado a fixar toolchains e dependências por anos, então a cultura de desenvolvimento web é chocante em vários aspectos
    • Um amigo reuniu um repositório no GitHub com formas sensatas e um pouco mais seguras de configurar isso: https://github.com/jordanconway/package-manager-hardening
    • Será que existe uma forma razoável de aplicar cooldown também ao pull de imagens Docker/Podman?
    • Mesmo sendo o tipo de pessoa que consegue abrir o arquivo ~/.npmrc e adicionar uma linha, ainda assim parece que o grupo que realmente precisa de uma correção com um clique é bem pequeno
    • Além do cooldown, seria bom que mais gerenciadores de pacotes tratassem correções de segurança separadamente dos releases comuns (correções de bugs/melhorias de desempenho/novos recursos)
      É perfeitamente possível dizer que “uma correção de segurança deve conter apenas correções de segurança e não incluir outros recursos”. Isso facilitaria a auditoria tanto para pesquisadores de segurança quanto para as ferramentas
      Releases comuns poderiam passar por cooldown, enquanto correções de segurança poderiam ficar sem cooldown ou com um período muito menor
      Vale olhar para sistemas como o Debian, que têm servidores extremamente estáveis e permitem configurar unattended upgrades para aplicar apenas correções de segurança. Novos releases de pacotes assim também ficam mais fáceis de auditar para pesquisadores de segurança

  • Em todo tópico desses aparecem muitos comentários agindo como se esse tipo de ataque existisse só no npm, ou zombando como se nada tivesse sido feito, mas acho isso injusto
    Também há muitos comentários mencionando bons recursos introduzidos para proteger os consumidores de pacotes, como delay line e pnpm
    A parte menos comentada são as ferramentas do lado dos mantenedores de pacotes. MFA para publicação: https://docs.npmjs.com/requiring-2fa-for-package-publishing-..., e os trusted publishers, disponíveis há cerca de um ano: https://docs.npmjs.com/trusted-publishers
    Mais recentemente, surgiu também o staged publishing, que combina as vantagens dos dois recursos: https://docs.npmjs.com/staged-publishing
    Agora dá para publicar a partir do CI sem credenciais estáticas e exigir que um mantenedor aprove com MFA antes de a publicação realmente ficar visível no registro. Se quiser, também é possível exigir múltiplas aprovações ou atraso de tempo no lado do CI com a proteção de GitHub Actions Environments
    A comunidade deveria ser incentivada a adotar esses mecanismos de proteção de publicação; caso contrário, esse problema vai continuar

    • Segundo [1], “todos os pacotes afetados foram publicados a partir do repositório RedHatInsights/javascript-clients via GitHub Actions OIDC, o que indica que o próprio pipeline upstream de CI/CD foi comprometido”
      Então os pacotes maliciosos também teriam recebido a estrelinha verde e passado ao usuário a sensação de segurança de que foram “compilados e assinados com comprovação de origem”
      [1] https://lwn.net/Articles/1075742/
    • Como continua acontecendo, acaba sendo engraçado. Ataques ao npm já são frequentes o bastante para marcar no calendário, e alguém até fez uma paródia em versão npm do clássico artigo do The Onion “não há como evitar isso”
      É ótimo que haja trabalho em andamento para impedir isso, mas continua acontecendo mesmo assim. É engraçado no sentido de “lá vamos nós de novo”
    • Só vai parecer que fizeram alguma coisa quando isso se tornar obrigatório para todo mundo
    • Parece haver um grupo que não se impressiona muito com mudanças mecânicas e enxerga isso como um problema cultural
      Visto de fora, o desenvolvimento web tem uma energia de velho oeste caótico. Há mutabilidade, tipagem dinâmica, padrões e frameworks mudando o tempo todo, deploy contínuo, CDN, campanhas A/B em tempo real, muitas dependências e dados sensíveis de usuários espalhados por várias infraestruturas
      Não estou dizendo que essa visão esteja correta, nem acho certa a atitude de “eu avisei”, mas entendo de onde ela vem
    • Na minha opinião, as duas são soluções de batom em porco. No fim, tudo isso é só uma variação de “vamos tornar os releases mais difíceis de publicar”, e isso só ensina as pessoas a procurar formas de contornar
      Em especial, nenhuma das duas teria impedido a entrada do backdoor do xz-utils na publicação do pacote. O xz-utils continua sendo a referência de comprometimento upstream sofisticado
      O bug aqui não é que precisamos autenticar melhor um upstream em que já confiamos, mas que não dá para confiar no upstream como única fonte de segurança. Upstream é um grupo de hackers que tende a ter pouco interesse e pouca habilidade em engenharia de release robusta
      Mas existem pessoas que fazem isso bem. A solução no mundo Linux, e a forma como fomos salvos no caso do xz-utils, é que existe uma segunda camada humana que revisa, audita, empacota e customiza o upstream feito por hackers para os usuários
      Essas pessoas têm outros olhos, outras exigências de consumo e outros padrões de qualidade, e detectam bugs e intenções maliciosas que o upstream não está preparado para perceber
      NPM, cargo, PyPI etc. continuam achando que dá para contornar a necessidade desse trabalho humano, mas não dá. No ecossistema NPM isso aparece com ainda mais frequência, especialmente porque há muitos desenvolvedores web acostumados a releases muito rápidos, exigências frouxas de compatibilidade e reutilização extrema, o que faz isso surgir mais em pacotes node do que em Python ou Rust

  • Na nossa empresa usamos yarn 4, e há uma opção para bloquear a instalação de pacotes npm nos primeiros dias após o lançamento. Parece que a maioria desses ataques é detectada dentro desse período (1 a 3 dias)
    https://gist.github.com/mcollina/b294a6c39ee700d24073c0e5a4e...

  • Tenho algumas sugestões. Um cooldown de dependências de 1 a 2 dias parece ser muito eficaz sem prejudicar a capacidade de aplicar patches de CVE
    Todo lugar onde código é executado, como npm install e npm test, deve rodar em um ambiente sem privilégios. No GitHub Actions, é relativamente simples separar os jobs que fazem build/teste dos artefatos dos jobs que fazem deploy/assinatura etc. Se estiver usando IA, basta adicionar skills/guias que imponham esse padrão
    Se você usa GitHub Actions, instalar a versão mais recente do zizmor melhora bastante a postura de segurança
    A segunda medida faz com que isso deixe de ser “propagável como um worm”, reduzindo grande parte do problema atual. A primeira dá às empresas tempo para reagir ao ataque. Também vale avaliar alguns vendors dessa área

    • E se o zizmor for comprometido?
      Foi engraçado como piada, logo depois de dizer que pacotes novos deveriam ser atrasados
    • Em vez desse cooldown, não bastaria executar os builds em um contexto isolado?
      Rodamos um proxy Maven localmente, e todos os builds são feitos dentro de contêineres. Python, npm e Go usam apenas repositórios públicos, então esses builds também podem ser feitos em contêineres sem necessidade de um proxy de repositório
    • Se for em todo lugar onde código é executado, parece que orquestradores agentes como codex e claude-code já fazem isso por padrão

  • É no mesmo dia em que Red Hat e IBM anunciaram o Project Lightwell para ajudar a detectar e corrigir vulnerabilidades na cadeia de suprimentos
    https://www.redhat.com/en/lightwell

  • Há alguns dias vi este rant interessante: https://github.com/uNetworking/uWebSockets.js/blob/master/mi...
    Faz sentido dizer que a maneira correta é fazer fork de todas as dependências que você usa e instalar a partir do seu próprio repositório, revisando e mesclando o upstream quando necessário. Só que isso parece extremamente trabalhoso

    • Não é algo impossível de automatizar. No ecossistema Go, isso pode ser chamado de vendoring: https://go.dev/ref/mod#vendoring
      É bom para reduzir ou eliminar a dependência de provedores de hospedagem de dependências de terceiros, trazer as dependências para dentro da sua própria ferramenta de revisão de código e garantir builds reproduzíveis no longo prazo
    • O problema é a dependência das dependências, e isso continua por vários níveis abaixo
    • Criei o Packj para auditar dependências facilmente pela CLI
      Packj(https://github.com/ossillate-inc/packj) detecta dependências maliciosas de PyPI/NPM/Ruby/PHP etc. por análise comportamental. Ele faz varredura de indicadores de comprometimento, como execução de shell, uso de chaves SSH, comunicação de rede e uso de decode+eval, com análise estática + dinâmica de código. Também verifica vários atributos de metadados para encontrar agentes maliciosos, como typosquatting
    • Você até pode mudar as probabilidades, mas, a menos que faça forks diligentemente e aplique monkeypatch em todas as vulnerabilidades futuras, pode acabar distribuindo para sempre um fork comprometido
    • Não deveríamos não só manter os pacotes atualizados, mas também restringir os números de versão?

  • Há cerca de uma semana removi o Node do meu notebook e me senti bem com isso
    Mesmo se eu der azar e sofrer um exploit, estou tentando fazer todo o trabalho em contêineres de desenvolvimento ou outros sandboxes para reduzir o raio de impacto. O invasor até pode conseguir pegar tokens do Claude, mas não vai conseguir escapar facilmente do contêiner e vasculhar meu diretório home
    Cooldown e allowlist de scripts de instalação são camadas extras especialmente boas para defesa em profundidade, principalmente em CI. Mas, no fundo, acho que o que precisa mudar é o modelo de permissões do sistema operacional. O padrão de confiar software de terceiros com permissões completas de usuário não funciona mais

    • Fico curioso se você usa algo como Bubblewrap/Firejail/Flatpak, ou como seria essa configuração. Estou pensando numa ideia parecida há um tempo, mas ainda não consegui colocá-la em prática

  • Acho que vale colocar o link do anúncio original
    https://www.stepsecurity.io/blog/multiple-redhat-cloud-servi...

    • Sim. E, além disso, até a grafia de Red Hat no título estava errada

  • Agora peguei o hábito de usar a flag --before=2026-05-30 ao instalar pacotes. Ela força a escolha de uma versão lançada antes da data especificada, e normalmente escolho algo como 5 dias antes

  • O NPM é quebrado desde o design, e a síndrome de NIH disseminada na comunidade impede até medidas simples

    • Não entendi muito bem a segunda frase. O npm não sofre do problema oposto de “não foi feito aqui”?
      Como absorvem muitos pacotes externos em vez de desenvolver internamente, projetos npm tendem a ter árvores de dependências grandes e complexas. Já existe há muito tempo a reclamação de que pacotes como https://www.npmjs.com/package/is-windows criam vulnerabilidades potenciais e dores de cabeça de manutenção, mesmo quando seria fácil demais escrever esse mesmo código diretamente
    • Um erro comum do lado do NIH é achar que recriar o pacote X vai levar muito tempo
      Mas, obviamente, não é preciso recriar tudo; basta implementar o que você precisa
      Além disso, quando você codifica só uma funcionalidade, não precisa criar abstrações nem interfaces extras de função. Então sai mais barato e provavelmente integra melhor
      Outro erro é achar que isso vai criar bugs e vulnerabilidades. Se você for um programador ruim, talvez aconteça, mas pelo menos dá para evitar a categoria de vulnerabilidades que surge nas fronteiras de integração entre duas bibliotecas que não foram projetadas para se encaixar exatamente. E isso acontece bastante