Pesquisador de segurança da Snyk distribui pacote NPM malicioso mirando Cursor.com

 (sourcecodered.com)
1 pontos por GN⁺ 2025-01-14 | 1 comentários | Compartilhar no WhatsApp
  • Vários pacotes publicados no npm continham scripts de instalação que pareciam mirar o Cursor.com e, ao serem instalados, enviavam informações do sistema para um serviço web externo
  • O distribuidor era o usuário npm sn4k-s3c e usava nomes que lembravam pacotes internos do Cursor, como cursor-retreival, cursor-always-local e cursor-shadow-workspace
  • A saída de env coletada pelos pacotes pode incluir variáveis de ambiente sensíveis, como chaves da AWS, tokens do npm e credenciais do GitHub, ampliando o possível impacto
  • O scanner de análise de pacotes da OpenSSF identificou os pacotes como maliciosos, e o OSV criou três avisos: MAL-2025-27, MAL-2025-28 e MAL-2025-29
  • Nos metadados do npm, um e-mail snyk.io da Snyk Security Labs aparecia como publicador; depois, um pesquisador da Snyk removeu os pacotes e a Snyk respondeu em um post no blog

Pacotes npm que pareciam mirar o Cursor

  • Durante o processo de detecção de pacotes maliciosos da SourceCodeRed, vários pacotes publicados no npm foram identificados
  • Os nomes dos pacotes tinham um formato que remetia a pacotes internos relacionados ao Cursor
    • cursor-retreival
    • cursor-always-local
    • cursor-shadow-workspace
  • O distribuidor aparecia como o usuário npm sn4k-s3c
  • Foi informado que a lista de pacotes podia ser verificada em https://www.npmjs.com/~sn4k-s3c

Ações executadas durante a instalação

  • Ao instalar os pacotes, eles coletavam dados do sistema e os enviavam para um serviço web controlado pelo atacante
  • Pela captura de tela, o pacote coletava a saída do comando env
  • A saída de env pode incluir configurações do sistema e variáveis de ambiente sensíveis
    • Chaves da AWS
    • Tokens do npm
    • Credenciais do GitHub
    • Outras variáveis de ambiente sensíveis
  • Como resultado, apenas a instalação já poderia causar vazamento externo de informações do ambiente local

Possibilidade de confusão de dependência e resultados da detecção

  • Pacotes desse tipo aparecem com frequência em ataques de confusão de dependência (dependency confusion) direcionados a empresas específicas
  • Não foi confirmado se o Cursor.com tem um programa de bug bounty nem qual seria o contexto específico
  • A SourceCodeRed suspeita que o Cursor possa ter pacotes npm privados como cursor-always-local, cursor-retrieval e cursor-shadow-workspace
  • O atacante talvez esperasse que funcionários do Cursor instalassem por engano os pacotes públicos e transmitissem dados
  • O scanner de análise de pacotes da OpenSSF identificou esses pacotes como maliciosos, e o OSV criou três avisos de malware

Metadados do publicador

  • Nos metadados dos pacotes npm, o publicador usava um endereço de e-mail snyk.io da equipe Snyk Security Labs
  • Foi dito que esse metadado de e-mail do publicador não é uma parte que possa ser falsificada
  • O campo author mencionava especificamente um funcionário da Snyk
  • Embora o campo author possa ser falsificado, foi apresentada a inferência de que os pacotes realmente vieram da Snyk porque o publicador tinha um e-mail verificado da Snyk

Resposta dos usuários e atualizações posteriores

  • A SourceCodeRed informou o npm, mas disse que, naquele momento, os pacotes ainda não estavam marcados como maliciosos
  • Muitas ferramentas de segurança da cadeia de suprimentos de software só conseguem bloquear um pacote quando sabem que ele é malicioso
  • A recomendação é não instalar pacotes npm indiscriminadamente
  • Esses pacotes continham apenas dois arquivos, package.json e index.js ou main.js, o que pode ser visto como um dos sinais de suspeita
  • Segundo a atualização de 15 de janeiro de 2025, um pesquisador da Snyk removeu os pacotes relacionados ao Cursor no dia seguinte à publicação do blog
  • Em 14 de janeiro de 2025, o The Register publicou uma matéria relacionada: https://www.theregister.com/2025/01/14/snyk_npm_deployment_removed/
  • No mesmo dia, a Snyk publicou uma resposta no blog, afirmando no sentido de que não havia cometido erro: https://snyk.io/blog/snyk-security-labs-testing-update-cursor-com-ai-code-editor/

Leituras relacionadas

1 comentários

 
GN⁺ 2025-01-14
Opiniões do Hacker News

  • [Correção: pelo que vi na resposta abaixo de um desenvolvedor do Cursor, parece que isso não foi aprovado pelo Cursor] Parece que há um registro NPM privado dentro do Cursor onde esses pacotes existem e que, por causa da forma como o NPM funciona, é fácil para um invasor enganar o sistema para buscar o mesmo pacote no registro público
    Provavelmente alguém da Snyk descobriu ou suspeitou que parte do build do Cursor estava configurada incorretamente desse jeito e publicou o pacote como prova de conceito. Pela descrição do pacote, “for Cursor”, achei que tinham sido contratados para isso
    Se for esse o caso, não há muito a ver aqui; e, se o ponto principal era demonstrar uma configuração incorreta que pula o registro privado, um pesquisador de segurança não poderia usar um registro NPM privado na prova de conceito
    Em especial, muitos proxies escolhem o registro público em vez do privado se a versão mais recente do pacote for maior: https://snyk.io/blog/detect-prevent-dependency-confusion-att...

    • Sou desenvolvedor do Cursor. É uma suposição razoável, mas um pouco diferente do que aconteceu. Os pacotes da Snyk são apenas nomes de extensões que incluímos no bundle, e nós não os empacotamos nem os publicamos em nenhum registro
      Tratamos isso da mesma forma que o VS Code: https://github.com/microsoft/vscode/tree/main/extensions
      Não contratamos a Snyk e, depois de ver isso, entramos em contato com eles e recebemos um pedido de desculpas. Não tivemos confirmação exata do que estavam tentando fazer, mas a explicação de que alguém suspeitou de uma vulnerabilidade de confusão de dependências parece plausível. Ainda assim, acho bastante irresponsável ter feito, no NPM público, algo que de fato enviava variáveis de ambiente
    • A prova de conceito poderia ter sido feita sem enviar para fora informações do host em que foi instalada e todas as variáveis de ambiente. Isso parece ter passado dos limites
    • Dar a alguém acesso total ao meu ambiente inteiro, ou seja, à saída completa do comando env, seria um grande problema para a maioria das pessoas
    • Sou responsável por DevRel & SecRel na Snyk. Acabei de publicar um post para esclarecer os rumores, com informações bastante detalhadas sobre a situação: https://snyk.io/blog/snyk-security-labs-testing-update-curso...
    • Isso não deveria ter sido corrigido no NPM? Lembro que um pesquisador da PortSwigger apresentou algo sobre isso no passado, e que praticamente todas as FAANG, como Apple, Microsoft e Meta, estavam vulneráveis na época

  • Curiosamente, um cofundador da Snyk fundou uma concorrente do Cursor
    https://www.tessl.io/ https://techcrunch.com/2024/11/14/tessl-raises-125m-at-at-50...
    Espero que não tenha havido má-fé

    • Como todas as minhas interações com eles foram muito negativas, acho bem provável que tenha havido má-fé

  • Agora acho que todo desenvolvimento precisa ser feito a sério dentro de uma máquina virtual. Uma VM por projeto. Há maneiras sutis demais de eu cometer um erro sem perceber e acabar destruindo a segurança. O único consolo é que sou um desconhecido sem segredos ou patrimônio para roubarem
    Estamos confiando cegamente em código demais: IDEs, plugins, utilitários de desenvolvimento, bibliotecas de linguagem, pacotes do sistema operacional etc.

    • A popularidade do Vagrant parece ter esfriado por causa dos contêineres Docker, mas, como forma de criar ambientes de desenvolvimento, ainda é do Vagrant que mais gosto
      Em um lugar onde trabalhei alguns anos atrás, navegadores web e ferramentas de desenvolvimento eram proibidos no notebook. Se precisasse de navegador, tinha que usar via Citrix; se precisasse programar, tinha que usar VDI ou rodar as ferramentas dentro de uma VM
      Na época, aquilo parecia quase insano, mas cada vez mais eu entendo
    • O problema real é o desempenho de vídeo da VM. Ainda é simplesmente ruim. Rodar Cinnamon numa VM torna quase impossível fazer a aceleração GL funcionar direito
      Como a NVIDIA tranca os recursos de GPU virtualizada atrás de placas enterprise, você acaba dependendo de tradução de comandos ineficaz
      Quase todo o restante do overhead de VM dá para tolerar, mas uma GUI engasgando e sem resposta tem um impacto ergonômico pior do que parece e, de algum jeito, ainda puxa para baixo a percepção de outras partes do desempenho
      Se esse problema fosse resolvido nem que fosse só ao virtualizar Linux sobre Linux, a opção de virtualizar tudo se tornaria muito mais realista
    • É assustador ver a confiança ruir a esse ponto, e receber atualizações mensais de vários GB no sistema operacional também não traz tranquilidade. Gosto da ideia de ter uma VM isolada e estável por projeto. Existe alguma ferramenta open source padrão para isso?
      Mais especificamente, estou migrando meu ambiente de desenvolvimento em Go e Zig de um Mac antigo para o Asahi Linux no M1, e já estou me enrolando para encontrar substitutos para TrueCrypt e Little Snitch. Essas ferramentas de VM dão suporte a VMs criptografadas e regras de firewall? Vagrant foi citado aqui e parece resolver o isolamento de rede até certo ponto, mas o que mais dá para recomendar?
    • Entendo o sentimento, e eu também já pensei nisso várias vezes. Hoje não quero fazer isso, e o principal motivo não é o trabalho que dá
      VMs podem me proteger, mas não protegem os usuários do software que eu faço. Se eu preciso vestir um traje de proteção para tocar no produto que envio aos clientes, como posso esperar que eles o usem com segurança sem proteção?
      Esse não é o ambiente que eu quero
      A solução atual é ser extremamente criterioso na escolha das dependências. Mais especificamente, acho que não se deve confiar em projetos ou empresas, e sim apenas em pessoas. Não é fácil, mas no momento não vejo alternativa melhor
    • Desenvolvo vários projetos no Linux. Principalmente por me preocupar que ferramentas, scripts de build e testes possam ler dados sensíveis ou destruir dados por acidente, uso namespaces do Linux e bubblewrap para restringir o acesso a arquivos enquanto trabalho em um projeto
      Em um arquivo dot simples por projeto, listo os binds do sistema de arquivos; quando abro um novo terminal durante o trabalho, ele é isolado automaticamente com base nesse arquivo dot. A carga cognitiva é muito baixa e a integração é quase transparente. Imagino que muitos desenvolvedores tenham scripts parecidos. Já procurei projetos desse tipo antes e não encontrei; não sei se é porque é simples demais para virar projeto ou porque não sei como outras pessoas chamam isso. Seria bom ter algo para consultar
      Não restrinjo o acesso à rede. Fiz experimentos registrando todo o tráfego e configurando automaticamente um proxy man-in-the-middle, mas não ficou conveniente o bastante para uso normal. Claro que a superfície de ataque do kernel continua existindo. Mas minha principal preocupação é que arquivos sejam lidos ou destruídos

  • A parte do texto com que não concordo é: “É melhor não instalar pacotes NPM às cegas, e há sinais para ver se um pacote é suspeito. Esses pacotes têm apenas dois arquivos, package.json e index.js ou main.js, então isso é uma das flags para julgar se são legítimos”
    Isso até pode funcionar em certa medida para pacotes de topo, mas revisar todas as dependências transitivas é praticamente impossível
    Se você trouxer um pacote com 400 dependências, como vai verificar adequadamente sequer 10% dessa superfície? https://gist.github.com/anvaka/8e8fa57c7ee1350e3491#top-1000...

    • O conselho de segurança a aplicar nesse caso é outro: não traga um pacote com 400 dependências
    • Nesse ponto, a direção geral do SELinux estava certa. Se os arquivos forem previamente classificados por sensibilidade dos dados e o acesso for negado com base nisso, o problema — por exemplo, impedir que uma instalação NPM acesse id_rsa — fica bem resolvido
    • Como é que um componente de carrossel em React consegue ter mais de 400 dependências…
    • Na nossa empresa usamos uma excelente ferramenta de segurança chamada Snyk. Vale muito a pena conferir /s

  • A Snyk também é uma empresa que não rotaciona a chave pública: simplesmente a troca sem aviso: https://github.com/snyk/cli/pull/5649
    Quando um projeto muda para uma hospedagem de repositório que não é o GitHub, eles o marcam como “abandoned”, e mesmo que saiam novos releases no npm/PyPI, ele continua sendo tratado como projeto abandonado
    Acho que a competência deles não é tão grande quanto a reputação
    Além disso, um vendedor da Snyk me insultou por e-mail. Pelo visto, não ter interesse em comprar o produto deles significa ser um desenvolvedor incompetente que só consegue usar software cheio de vulnerabilidades

    • Eles também penalizam bibliotecas cujo desenvolvimento terminou e que só precisam de manutenção mínima
      Parece um software completamente invertido, que empresas compram porque seguradoras mandam preencher itens de checklist de segurança
    • Essa rotulagem como “abandoned” é especialmente lamentável. Eu também estou tentando sair do GitHub recentemente, e sinto que o GitHub tem controle demais
      O Codeberg parece interessante, e, se der para bancar a manutenção, opções self-hosted como o Forejo também parecem boas
    • Marcar como “abandoned” só porque mudou para um repositório que não é o GitHub, e manter assim mesmo com novos releases no npm/PyPI, é mesmo sinal de uma boa equipe /s
      Eu não tinha ouvido muita coisa sobre a Snyk além de que eles têm um orgulho forte, mas é uma perspectiva bem interessante
    • Você conseguiria fornecer o corpo desse e-mail com as devidas tarjas?

  • Sem mais contexto, isso também não parece bom para a Snyk. Significa que um funcionário testou o serviço da própria empresa em ambiente real usando o NPM, ou que faltaram controles e procedimentos para não usar recursos públicos ao realizar uma auditoria legítima da Cursor

    • Por que isso não pode? O NPM se comporta de forma estranha quando existe um pacote público com o mesmo nome de um pacote em um repositório privado e, em alguns casos, acaba buscando o pacote público. Pelo que sei, isso é chamado de algo como sequestro/reserva de nome de pacote. Pode ter sido apenas uma demonstração de que isso era possível durante a avaliação. Na minha opinião, não houve dano e não há problema

  • Parece uma auditoria white hat feita pela Snyk. O oastify.com parece ter sido detectado por ser o servidor padrão do Burp Collaborator
    No teste, deveriam ter usado um repositório npm privado, e não é difícil sobrescrever isso localmente. Também deveriam ter usado um servidor Collaborator próprio

    • Não é white hat, porque eles extraíram dados ativamente. Se fosse apenas para provar que funcionava, bastaria imprimir um console.log, fazer o npm install falhar ou usar uma abordagem que não extraísse o payload

  • Parece que o NPM está criando empregos para o setor de segurança. É uma bagunça impossível de consertar, e espero que concorrentes como o JSR pressionem a organização o suficiente

    • Não é um problema exclusivo do NPM, mas sim uma questão geral de confiança em bibliotecas de terceiros. Embora seja muito mais raro, também surgem exploits em plataformas como o NuGet. Eles também vão aparecer no JSR. A imutabilidade o torna mais seguro, mas não impede downloads antes que um pacote malicioso seja descoberto
      Na verdade, é bem provável que regulações como DORA e NSIS passem a exigir cada vez mais auditorias de pacotes de terceiros. Isso vai forçar mudanças na forma de desenvolvimento em setores críticos. Além disso, na era dos LLMs, acho que o uso de pacotes externos vai cair muito. Qual é o motivo para trazer um pacote externo só para fazer algo como gerar uma especificação OpenAPI? Um LLM consegue escrever o script CLI necessário com uma ou duas horas de configuração. Da mesma forma, mesmo que você não use um LLM para autogerar diretamente as partes tediosas do código, pode fazê-lo criar uma ferramenta CLI que faça esse trabalho. Assim você não depende de fatores externos e, embora seja quase garantido que essas ferramentas CLI sejam um código cowboy bagunçado, o resultado pode ser moldado ao formato desejado à medida que você ajusta a ferramenta
      Ao olhar para linguagens como Go, que colocam no pacote padrão aquilo de que você precisa, dá para ver um mundo em que é muito fácil fazer muita coisa usando apenas a biblioteca padrão

  • Fugindo um pouco do assunto, mas alguém já recebeu um SBOM decente das próprias ferramentas e serviços da Snyk? Pergunto porque eles tentaram vender para nossa empresa uma solução para criar SBOMs

    • A Snyk é uma empresa fundada por ex-integrantes da Unit 8200 do Exército israelense
      Acho que eu não instalaria nem que me pagassem. A Unit 8200 continua gerando fundadores e financiando empresas, e isso dá a sensação de uma estrutura em que eles já colocaram o pé na porta, como a NSA
    • Obtivemos resultados melhores com o Syft
    • Na minha experiência, havia muitos falsos positivos

  • A Snyk Research Labs contribui regularmente com a comunidade por meio de testes e pesquisas de pacotes de software comuns. Esta pesquisa sobre o Cursor não teve intenção maliciosa, e o pacote incluía informações de contato da Snyk Research Labs e do pesquisador. Estávamos analisando de forma muito específica a confusão de dependências em algumas extensões do VS Code, e esses pacotes não eram destinados a ser instalados diretamente por desenvolvedores
    A Snyk segue uma política de divulgação responsável. Ninguém puxou esse pacote, mas, se alguém tivesse feito isso, teríamos tomado medidas de acompanhamento imediatamente

    • Espalhar um ataque em um espaço público esperando que ele acerte o alvo é exatamente o oposto de uma conduta responsável. A única parte “boa” é que eles foram pegos no ato antes que outra pessoa fosse atingida por uma bala perdida
      A resposta soa como dizer que enviariam uma carta de desculpas ao funeral da pessoa atingida. Mesmo que houvesse “boas intenções”, ao comprometer credenciais a pessoa já está comprometida e precisa responder exatamente como responderia se tivesse sido alvo de um atacante malicioso
      Isso chega tão perto que é difícil sentir diferença em relação à má-fé
      Além disso, todos deveriam lembrar que uma parte interessada da Snyk está tentando lançar agora um produto concorrente do Cursor. Fica muito mais difícil presumir boa-fé
    • Ótimo. Mas então por que enviaram as variáveis de ambiente do usuário para casa? Para verificar a vulnerabilidade, teria sido suficiente enviar apenas valores fictícios, não valores reais do ambiente
    • Isso é gray hat, na melhor das hipóteses. A intenção pode ter sido boa, mas essa equipe criou e distribuiu, sem autorização, um software que acessa e exfiltra dados, o que é extremamente ilegal. Seria melhor consultar o jurídico antes de postar algo assim em um fórum público
    • Parece plausível, mas por que enviaram as variáveis de ambiente de volta via POST? Mesmo que tenha sido totalmente de boa-fé, eu não quero que um pacote arbitrário tenha a saída do meu env
    • Pode de fato ser o CTO da Snyk, e vou dar upvote porque as pessoas deveriam ver a resposta oficial, mas isso parece realmente irresponsável. Dava para fazer uma prova de conceito sem efetivamente roubar credenciais de desenvolvedores inocentes
      Além disso, considerando o conflito de interesses com um produto concorrente do Cursor, deveriam ter sido ainda mais cuidadosos. Tanto a tomada de decisão quanto a resposta foram péssimas