Siga ZDNET: Adicione-nos como fonte preferencial no Google.
Principais vantagens do ZDNET
- A Red Hat foi vítima de uma violação de segurança do NPM.
- A empresa removeu os pacotes afetados.
- Verifique se você está usando o namespace npm @redhat-cloud-services.
Namespace do repositório Npm – ambiente de tempo de execução JavaScript Node.js gerenciador de pacotes – é famoso por violações de segurança. Agora a Red Hat, que junto com a IBM acaba de anunciar o Projeto Lightwell, uma iniciativa baseada em inteligência artificial para encontrar e corrigir vulnerabilidades em software de código aberto, tem o próprio problema do npm.
Também: A segurança de código aberto é uma bagunça – IBM e Red Hat prometem US$ 5 bilhões e 20.000 engenheiros para consertá-la
Dezenas de pacotes JavaScript no namespace @redhat-cloud-services continham backdoors com segredos de malware para roubo de credenciais nos sistemas de desenvolvimento e integração contínua e implantação contínua (CI/CD) da Red Hat. A empresa de pesquisa de segurança Aikido informou que o namespace era “comprometido com um worm que rouba credenciais. Um total de 96 versões em 32 pacotes foram comprometidas, com um total de 116.991 downloads por semana.
De acordo com a Red Hat Security, alguém usou um conta GitHub hackeada para injetar código malicioso em pacotes mantidos na organização Red Hat GitHub. Os pacotes afetados são bibliotecas front-end compiladas e agrupadas em imagens de contêiner durante o processo de construção do produto Red Hat.
O que exatamente aconteceu?
O malware parece ter sido adicionado por meio de ganchos de pré-instalação do npm: sempre que um desenvolvedor ou sistema de compilação fazia a “instalação do npm” em um pacote afetado, o código malicioso era executado automaticamente. De acordo com a equipe de inteligência de ameaças da Microsoft, cada um pacote comprometido adicionou um script de pré-instalação que lançou um carregador index.js inchado e altamente ofuscado, que então desmontou e executou uma carga projetada para extrair segredos do npm, GitHub, AWS, SSH e outros ambientes.
Os pesquisadores rapidamente vincularam o ataque a uma campanha mais ampla baseada no malware Mini Shai-Hulud, um worm de propagação de npm usado em incidentes anteriores na cadeia de suprimentos. No caso da Red Hat, vários relatórios referiram-se à carga útil como uma nova variante chamada Miasma, que mantém o comportamento de autopropagação do Mini Shai-Hulud, ao mesmo tempo que adiciona mais ofuscação e um design de carregamento em vários estágios.
O worm faz mais do que apenas roubar credenciais. Ao ser executado em uma máquina com acesso a outros pacotes npm, ele identifica cada pacote que o usuário atual pode publicar e os republica com a mesma carga maliciosa de pré-instalação. Ou seja, cada vítima se torna um novo agressor. As empresas de segurança afirmam que esse comportamento “verme” foi o que permitiu que o namespace relacionado ao Red Hat fosse contaminado tão rapidamente. Algumas estimativas sugerem que mais de 30 pacotes foram abertos em questão de minutos.
Também: Red Hat Desktop vs. Fedora Hummingbird: Qual caminho Linux para desenvolvimento de IA é ideal para você?
Embora a Red Hat ainda não tenha divulgado um relatório post-mortem detalhado, análises independentes apontam para a infraestrutura comprometida do GitHub como o vetor de acesso inicial. A Semgrep e outras empresas de pesquisa de segurança relatam que Os pacotes de escopo da Red Hat foram transferidos usando tokens GitHub Actions OpenID Connect (OIDC) vinculado ao repositório RedHatInsights/javascript-clients.
Uma vez lá dentro, os invasores injetaram o gancho de pré-instalação em vários pacotes e versões, muitas vezes sem alterações correspondentes nos repositórios de fontes públicas. Este é um sinal clássico de compromisso na construção de oleodutos.
O código executado verifica e tenta filtrar o seguinte.
- Segredos do GitHub Actions e credenciais de acesso
- Chaves SSH do GitHub e credenciais de acesso pessoal
- Credenciais de nuvem AWS, GCP e Azure
- Configuração e tokens do Kubernetes
- Tokens HashiCorp Vault e outros dados de gerenciadores secretos
- Tokens npm e CircleCI e outros segredos de CI/CD armazenados em variáveis de ambiente ou arquivos de configuração
Também: Rust salvará o Linux da IA, diz Greg Kroah-Hartman
Os fornecedores de segurança alertam que qualquer pessoa que instalou as compilações afetadas em uma estação de trabalho de desenvolvedor, agente de compilação ou iniciador de CI deve presumir que todos os tokens e credenciais disponíveis desse ambiente podem agora estar nas mãos de um invasor.
Para os desenvolvedores, as orientações fornecidas por diversas empresas são claras:
- Transforme segredos imediatamente.
- Verifique o GitHub e a atividade na nuvem em busca de acesso suspeito.
- Restaure todos os ambientes potencialmente contaminados com base em boas referências conhecidas.
A Red Hat me disse: “Iniciamos imediatamente uma investigação e removemos os pacotes do registro npm. Os pacotes são estritamente restritos ao desenvolvimento interno e o código malicioso nunca foi publicado para consumo do cliente através do sistema console.redhat.com. Enquanto nossa investigação está em andamento, não identificamos nenhum impacto nos ambientes de clientes ou parceiros ou nos sistemas de produção da Red Hat.”
Em suma, poderia ter sido muito pior.
Também: Ubuntu 26.04 é um sistema operacional para a era dos agentes de IA, diz Mark Shuttleworth da Canonical.
no passado, Orientações mais gerais sobre ataques à cadeia de suprimentos NPMA Red Hat Product Security afirmou que seus produtos dependem fortemente de pinagem de versão rigorosa e espelhos internos, e que o software Red Hat suportado não inclui pacotes npm previamente comprometidos.
No entanto, após um incidente recente, os pesquisadores de segurança estão incentivando as organizações a não presumirem que estão seguras apenas porque usam as ofertas da Red Hat. Eles argumentam que qualquer construção ou fluxo de trabalho de desenvolvedor que atinja pacotes backdoor deve ser considerado potencialmente comprometido.
O que você deve fazer agora?
Embora a Red Hat garanta a todos que nenhum código incorreto foi descoberto, ainda sou cauteloso. Se você confia nas ferramentas do Red Hat Cloud Services ou já incluiu pacotes @redhat-cloud-services em suas compilações, recomendo verificar as árvores de dependência das versões afetadas, bloquear lançamentos ruins conhecidos e fazer downgrade ou substituí-los por versões confiáveis, se necessário.
Ao mesmo tempo, eu presumiria que qualquer ambiente onde esses pacotes foram instalados poderia ter tido segredos expostos e todas as credenciais relevantes, como PATs do GitHub, chaves SSH, chaves de API do provedor de nuvem e tokens CI, seriam rotacionadas.
Também: Quão digitalmente soberana é a sua organização? Esta ferramenta Red Hat pode te dizer em minutos
No longo prazo, o incidente do Red Hat npm mostra novamente que os repositórios npm não são tão confiáveis. Com até mesmo os principais fornecedores de Linux e de nuvem agora aparentemente vulneráveis ao malware npm wormable, a pressão está aumentando tanto sobre os gerentes de npm quanto sobre os principais fornecedores de software para fornecer garantias mais fortes sobre a origem e a segurança de seus pacotes.
Em outras palavras, embora a Red Hat possa ser a moleza deste episódio, ela também destaca a importância do Projeto Lightwell e esforços semelhantes, como Os esforços da Chainguard para encontrar uma maneira de melhorar a segurança do código aberto de todosé.
