Un chercheur en sécurité de Snyk a publié des paquets NPM malveillants visant Cursor.com

 (sourcecodered.com)
1 points par GN⁺ 2025-01-14 | 1 commentaires | Partager sur WhatsApp
  • Plusieurs paquets publiés sur npm contenaient des scripts d’installation semblant viser Cursor.com et, lors de l’installation, transmettaient des informations système vers un service web externe
  • Le diffuseur était l’utilisateur npm sn4k-s3c, qui utilisait des noms évoquant des paquets internes de Cursor comme cursor-retreival, cursor-always-local et cursor-shadow-workspace
  • La sortie de env exfiltrée par ces paquets peut contenir des variables d’environnement sensibles telles que des clés AWS, des tokens npm et des identifiants GitHub, ce qui pourrait élargir l’ampleur de l’impact
  • Le scanner d’analyse de paquets d’OpenSSF a identifié les paquets comme malveillants, et OSV a créé trois avis MAL-2025-27, MAL-2025-28 et MAL-2025-29
  • Dans les métadonnées npm, une adresse e-mail snyk.io de Snyk Security Labs apparaissait comme éditeur ; le chercheur de Snyk a ensuite retiré les paquets et Snyk a réagi via un billet de blog

Des paquets npm semblant viser Cursor

  • Plusieurs paquets publiés sur npm ont été repérés lors du processus de détection de paquets malveillants de SourceCodeRed
  • Les noms des paquets évoquaient des paquets internes liés à Cursor
    • cursor-retreival
    • cursor-always-local
    • cursor-shadow-workspace
  • Le diffuseur était indiqué comme l’utilisateur npm sn4k-s3c
  • Il est indiqué que la liste des paquets est consultable sur https://www.npmjs.com/~sn4k-s3c

Comportement lors de l’installation

  • L’installation des paquets collectait des données système puis les envoyait vers un service web contrôlé par l’attaquant
  • D’après la capture d’écran, les paquets récupéraient la sortie de la commande env
  • La sortie de env peut contenir, en plus des paramètres système, des variables d’environnement sensibles
    • clés AWS
    • tokens npm
    • identifiants GitHub
    • autres variables d’environnement sensibles
  • En conséquence, la simple installation pouvait entraîner une fuite d’informations de l’environnement local vers l’extérieur

Possibilité de dependency confusion et résultats de détection

  • Ce type de paquet apparaît souvent dans des attaques de dependency confusion visant une entreprise précise
  • Il n’a pas été possible de confirmer si Cursor.com dispose d’un programme de bug bounty ni le contexte exact
  • SourceCodeRed soupçonne que Cursor puisse utiliser des paquets npm privés comme cursor-always-local, cursor-retrieval et cursor-shadow-workspace
  • L’attaquant pouvait espérer qu’un employé de Cursor installe par erreur le paquet public et transmette ainsi des données
  • Le scanner d’analyse de paquets d’OpenSSF a identifié ces paquets comme malveillants, et OSV a créé trois avis de malware

Métadonnées du diffuseur

  • Dans les métadonnées des paquets npm, l’éditeur utilisait une adresse e-mail snyk.io de l’équipe Snyk Security Labs
  • Il est indiqué que cette métadonnée d’e-mail de l’éditeur ne peut pas être falsifiée
  • Le champ author mentionnait explicitement un employé de Snyk
  • Le champ author peut être falsifié, mais comme l’éditeur utilisait une adresse e-mail Snyk vérifiée, l’hypothèse avancée est que les paquets provenaient bien de Snyk

Réaction des utilisateurs et mises à jour ultérieures

  • SourceCodeRed indique avoir averti npm, mais qu’à ce moment-là les paquets n’étaient pas encore signalés comme malveillants
  • De nombreux outils de sécurité de la supply chain logicielle ne peuvent bloquer un paquet que s’ils savent déjà qu’il est malveillant
  • Il est recommandé de ne pas installer de paquets npm à l’aveugle
  • Les paquets en question ne contenaient que deux fichiers, package.json et index.js ou main.js, ce qui peut être considéré comme un signal suspect
  • Selon une mise à jour du 15 janvier 2025, le chercheur de Snyk a retiré les paquets liés à Cursor le lendemain de la publication du billet de blog
  • Le 14 janvier 2025, The Register a publié un article sur le sujet : https://www.theregister.com/2025/01/14/snyk_npm_deployment_removed/
  • Le même jour, Snyk a publié une réponse sur son blog, affirmant en substance n’avoir rien fait de répréhensible : https://snyk.io/blog/snyk-security-labs-testing-update-cursor-com-ai-code-editor/

À lire aussi

1 commentaires

 
GN⁺ 2025-01-14
Avis sur Hacker News

  • [Correction : d’après la réponse du développeur de Cursor ci-dessous, il semble que Cursor ne l’ait pas approuvé] On dirait qu’il existe chez Cursor un registre NPM privé contenant ces packages, et qu’en raison du fonctionnement de NPM, il est facile pour un attaquant de tromper le système pour qu’il récupère le même package depuis le registre public
    Un employé de Snyk a probablement trouvé, ou soupçonné, qu’une partie du build de Cursor était mal configurée de cette manière, puis a publié un package comme preuve de concept. Vu que la description du package était « for Cursor », j’ai cru qu’il avait été engagé pour cela
    Si c’est le cas, il n’y a pas grand-chose à en tirer ; si l’essentiel était de montrer une mauvaise configuration contournant le registre privé, le chercheur en sécurité n’aurait pas pu utiliser un registre NPM privé pour sa preuve de concept
    En particulier, beaucoup de proxys choisissent le registre public plutôt que le privé si la version la plus récente du package y est plus élevée : https://snyk.io/blog/detect-prevent-dependency-confusion-att...

    • Je suis développeur chez Cursor. C’est une hypothèse raisonnable, mais la réalité est un peu différente. Les packages Snyk ne sont que les noms d’extensions que nous incluons en bundle ; nous ne les packagons pas et ne les publions dans aucun registre
      Nous les traitons de la même manière que VS Code : https://github.com/microsoft/vscode/tree/main/extensions
      Nous n’avons pas engagé Snyk et, après avoir découvert cette affaire, nous les avons contactés et avons reçu des excuses. Nous n’avons pas eu confirmation exacte de ce qu’ils essayaient de faire, mais l’explication selon laquelle quelqu’un soupçonnait une vulnérabilité de confusion de dépendances paraît plausible. Cela dit, faire en sorte que des variables d’environnement soient effectivement envoyées depuis le NPM public me paraît assez irresponsable
    • Une preuve de concept aurait pu être réalisée sans exfiltrer les informations sur l’hôte d’installation ni toutes les variables d’environnement. Là, ils ont franchi une ligne
    • Donner à quelqu’un un accès complet à tout mon environnement, c’est-à-dire à toute la sortie de la commande env, serait un gros problème pour la plupart des gens
    • Je m’occupe du DevRel & SecRel chez Snyk. Je viens de publier un billet pour clarifier les rumeurs, avec pas mal d’informations détaillées sur la situation : https://snyk.io/blog/snyk-security-labs-testing-update-curso...
    • NPM n’aurait-il pas dû corriger ça ? Je me souviens qu’un chercheur de PortSwigger avait fait une présentation là-dessus il y a un moment, et qu’à l’époque presque tous les FAANG, comme Apple, Microsoft et Meta, étaient vulnérables

  • Fait intéressant, un cofondateur de Snyk a lancé un concurrent de Cursor
    https://www.tessl.io/ https://techcrunch.com/2024/11/14/tessl-raises-125m-at-at-50...
    J’espère qu’il n’y a pas eu de manœuvre malhonnête

    • Comme toutes mes interactions avec eux ont été très négatives, je pense qu’il est assez probable qu’il y ait eu une manœuvre malhonnête

  • Il semble qu’il faille désormais sérieusement faire tout développement dans une machine virtuelle. Une VM par projet. Il y a trop de façons subtiles de se tromper sans s’en rendre compte et de ruiner sa sécurité. La seule consolation, c’est d’être un inconnu sans secrets ni biens à voler.
    On fait aveuglément confiance à beaucoup trop de code : IDE, plugins, utilitaires de développement, bibliothèques de langage, paquets du système d’exploitation, etc.

    • La popularité de Vagrant semble s’être refroidie à cause des conteneurs Docker, mais comme manière de créer des environnements de développement, Vagrant reste celle que je préfère.
      Dans un endroit où j’ai travaillé il y a quelques années, les navigateurs web et les outils de développement étaient interdits sur les ordinateurs portables. Si l’on avait besoin d’un navigateur, il fallait passer par Citrix ; si l’on devait coder, il fallait utiliser une VDI ou exécuter les outils dans une VM.
      À l’époque, cette approche me paraissait presque complètement folle, mais je la comprends de plus en plus.
    • Le vrai problème, ce sont les performances vidéo des VM. Elles restent franchement médiocres. Faire tourner Cinnamon dans une VM et obtenir une accélération GL qui fonctionne correctement est quasiment impossible.
      NVIDIA verrouille les fonctions de GPU virtualisé derrière ses cartes d’entreprise, ce qui oblige à dépendre d’une traduction de commandes inefficace.
      On peut supporter presque toute autre surcharge liée aux VM, mais une GUI saccadée et peu réactive a un impact ergonomique plus mauvais qu’on ne l’imagine, et tire bizarrement les autres performances vers le bas.
      Si ce problème était résolu, ne serait-ce que pour virtualiser Linux sur Linux, l’option consistant à tout virtualiser deviendrait beaucoup plus réaliste.
    • C’est terrible de voir la confiance se dégrader à ce point, et les mises à jour mensuelles de plusieurs Go du système d’exploitation ne rassurent pas non plus. L’idée d’avoir une VM d’isolation stable par projet me plaît. Existe-t-il des outils open source standard pour cela ?
      Plus précisément, je suis en train de déplacer mon environnement de développement Go et Zig d’un ancien Mac vers Asahi Linux sur M1, et je galère déjà à trouver des remplaçants à TrueCrypt et Little Snitch. Ces outils de VM prennent-ils en charge les VM chiffrées et les règles de pare-feu ? Vagrant a été mentionné ici, et semble pouvoir résoudre une partie de l’isolation réseau, mais que recommander d’autre ?
    • Je vois très bien le sentiment, et j’y ai moi aussi réfléchi plusieurs fois. Aujourd’hui, je n’ai pas envie de le faire, et la principale raison n’est pas l’effort que cela demanderait.
      Une VM peut me protéger, mais elle ne protège pas les utilisateurs du logiciel que je crée. Comment pourrais-je envoyer à des clients un produit que je ne peux manipuler qu’en combinaison de protection, et m’attendre à ce qu’ils l’utilisent en sécurité sans protection ?
      Ce n’est pas l’environnement que je veux.
      La solution actuelle consiste à choisir ses dépendances avec une extrême exigence. Plus précisément, je pense qu’il ne faut pas faire confiance à des projets ou à des entreprises, mais uniquement à des personnes. Ce n’est pas facile, mais pour l’instant je ne vois pas de meilleure alternative.
    • Je développe plusieurs projets sous Linux. Comme je crains surtout que les outils, scripts de build et tests lisent des données sensibles ou détruisent accidentellement des données, je limite l’accès aux fichiers pendant le travail sur un projet avec les namespaces Linux et bubblewrap.
      Je note les montages bind du système de fichiers dans un simple fichier dot par projet, et quand j’ouvre un nouveau terminal pendant le travail, il est automatiquement isolé selon ce fichier dot. La charge cognitive est très faible et l’intégration est presque transparente. J’imagine que beaucoup de développeurs ont des scripts similaires. J’ai déjà cherché ce genre de projet sans en trouver ; je ne sais pas si c’est trop simple pour mériter d’être un projet, ou si je ne sais simplement pas comment les autres appellent ça. J’aimerais avoir des références utiles.
      Je ne limite pas l’accès réseau. J’ai expérimenté l’enregistrement de tout le trafic et la configuration automatique d’un proxy man-in-the-middle, mais ce n’était pas assez pratique pour un usage quotidien. Bien sûr, la surface d’attaque du noyau reste présente. Cela dit, ma principale inquiétude est que des fichiers soient lus ou détruits.

  • La partie de l’article avec laquelle je ne suis pas d’accord est celle qui dit : « mieux vaut ne pas installer aveuglément des paquets NPM, et il existe des signaux permettant de voir si un paquet est suspect. Ces paquets ne contiennent que deux fichiers, package.json et index.js ou main.js, ce qui constitue l’un des indicateurs pour juger s’ils sont légitimes ».
    Cela peut fonctionner dans une certaine mesure pour les paquets de premier niveau, mais passer en revue toutes les dépendances transitives est presque impossible.
    Si vous importez un paquet avec 400 dépendances, comment pourriez-vous examiner correctement ne serait-ce que 10 % de cette surface ? https://gist.github.com/anvaka/8e8fa57c7ee1350e3491#top-1000...

    • Dans ce cas, le conseil de sécurité à appliquer est différent : ne pas importer de paquet avec 400 dépendances.
    • Sur ce point, la grande orientation de SELinux était la bonne. Si les fichiers sont préclassés selon la sensibilité des données et que l’accès est refusé en conséquence, cela résout largement ce problème, par exemple empêcher une installation NPM d’accéder à id_rsa.
    • Comment un composant de carrousel React peut-il bien avoir plus de 400 dépendances…
    • Dans notre entreprise, nous utilisons un excellent outil de sécurité appelé Snyk. À essayer absolument /s

  • Snyk est aussi une entreprise qui ne fait pas de rotation propre de ses clés publiques, mais les change simplement sans préavis : https://github.com/snyk/cli/pull/5649
    Quand un projet migre vers un hébergement de dépôt autre que GitHub, il est marqué comme « abandoned », et même si de nouvelles releases sortent sur npm/PyPI, il reste considéré comme abandonné.
    Je ne pense pas que leurs compétences soient à la hauteur de leur réputation.
    Et un commercial de Snyk m’a insulté par e-mail. Apparemment, ne pas être intéressé par l’achat du produit signifie que je suis un développeur incompétent, condamné à n’utiliser que des logiciels pleins de vulnérabilités.

    • Ils pénalisent aussi les bibliothèques dont le développement est terminé et qui n’ont besoin que d’une maintenance minimale.
      Ça ressemble à un logiciel complètement à l’envers, que les entreprises achètent parce que les assureurs leur demandent de cocher des cases dans une checklist de sécurité.
    • Ce label « abandoned » est particulièrement regrettable. Moi aussi, j’essaie récemment de quitter GitHub, et j’ai l’impression que GitHub a trop de contrôle.
      Codeberg a l’air intéressant, et si l’on peut assumer la maintenance, une option autohébergée comme Forejo semble également bonne.
    • Marquer comme « abandoned » un projet simplement parce qu’il a migré vers un dépôt autre que GitHub, et le laisser ainsi même quand de nouvelles releases sortent sur npm/PyPI : voilà bien le signe d’une bonne équipe /s
      Je n’avais pas beaucoup entendu parler de Snyk, à part qu’ils avaient un ego assez marqué, mais c’est un point de vue assez intéressant.
    • Tu pourrais fournir le contenu de cet e-mail sous une forme correctement caviardée, non ?

  • Sans davantage de contexte, cela ne donne pas non plus une bonne image de Snyk. Cela signifie soit qu’un employé a testé le service de son entreprise en environnement réel via NPM, soit qu’il manquait des contrôles et procédures pour éviter d’utiliser des ressources publiques lors d’un audit légitime de Cursor.

    • Pourquoi est-ce un problème ? NPM se comporte bizarrement lorsqu’il existe un paquet public portant le même nom qu’un paquet dans un dépôt privé, et dans certains cas il récupère le paquet public. Je crois que c’est ce qu’on appelle une sorte de détournement/préemption de nom de paquet. Il est possible qu’ils aient simplement montré, lors de l’évaluation, que c’était possible. À mon avis, il n’y a pas eu de préjudice et pas de problème.

  • Cela ressemble à un audit white hat mené par Snyk. oastify.com étant le serveur par défaut de Burp Collaborator, c’est probablement ce qui a été détecté.
    Ils auraient dû utiliser un registre npm privé pour le test, et ce n’est pas difficile de le surcharger en local. Ils auraient aussi dû utiliser leur propre serveur Collaborator.

    • Ce n’est pas du white hat, puisqu’ils ont activement exfiltré des données. S’il s’agissait seulement de prouver que cela fonctionnait, un console.log, faire échouer npm install, ou une méthode qui n’extrait pas la charge utile aurait largement suffi.

  • On dirait que NPM crée des emplois pour l’industrie de la sécurité. C’est un bazar impossible à corriger, et j’espère que des concurrents comme JSR mettront suffisamment de pression sur l’organisation.

    • Ce n’est pas un problème propre à NPM, mais un problème général de confiance dans les bibliothèques tierces. Même si c’est beaucoup plus rare, des exploits apparaissent aussi sur des plateformes comme NuGet. Il y en aura aussi sur JSR. L’immutabilité apporte davantage de sécurité, mais elle n’empêche pas un paquet malveillant d’être téléchargé avant d’être découvert.
      Au contraire, il est très probable que des réglementations comme DORA et NSIS exigent de plus en plus l’audit des paquets tiers. Cela forcera les secteurs critiques à changer leurs pratiques de développement. Et je pense aussi qu’à l’ère des LLM, l’usage de paquets externes diminuera nettement. Pourquoi importer un paquet externe pour faire quelque chose comme générer une spécification OpenAPI ? Un LLM peut écrire le script CLI nécessaire avec une ou deux heures de configuration. De même, même si l’on n’utilise pas directement un LLM pour générer automatiquement les parties ennuyeuses du code, on peut lui faire créer des outils CLI qui s’en chargent. Ainsi, on n’a pas à dépendre de facteurs externes ; ces outils CLI seront presque certainement du code cowboy mal fichu, mais on peut affiner l’outil pour obtenir la sortie voulue.
      Quand on regarde des langages comme Go, qui mettent dans les paquets standard ce dont on a besoin, on entrevoit un monde où l’on peut faire énormément de choses très facilement avec la seule bibliothèque standard.

  • C’est un peu hors sujet, mais quelqu’un a-t-il déjà reçu un SBOM correct pour les propres outils et services de Snyk ? Je demande parce qu’ils essaient de vendre à notre entreprise une solution pour produire des SBOM.

    • Snyk a été fondée par d’anciens membres de l’Unit 8200 de l’armée israélienne.
      Je ne pense pas que je l’installerais même s’ils me payaient. L’Unit 8200 continue de produire des fondateurs et de les financer ; ça donne l’impression d’un mécanisme où, comme la NSA, ils ont déjà un pied dans la porte.
    • J’ai obtenu de meilleurs résultats avec Syft.
    • D’après mon expérience, il y avait beaucoup de faux positifs.

  • Snyk Research Labs contribue régulièrement à la communauté par des tests et des recherches sur des paquets logiciels courants. Cette recherche sur Cursor n’avait pas d’intention malveillante, et les paquets incluaient les coordonnées de Snyk Research Labs et du chercheur. Nous examinions très spécifiquement la confusion de dépendances dans certaines extensions VS Code, et ces paquets n’étaient pas destinés à être installés directement par des développeurs.
    Snyk suit une politique de divulgation responsable. Personne n’a récupéré ces paquets, mais si quelqu’un l’avait fait, nous aurions immédiatement pris des mesures de suivi.

    • Semer une attaque dans l’espace public en espérant qu’elle touche la cible est exactement l’opposé d’un comportement responsable. La seule partie « positive », c’est qu’elle a été interceptée sur le fait avant que quelqu’un d’autre ne soit touché par une balle perdue.
      Comme réponse, cela ressemble à promettre d’envoyer une lettre d’excuses aux funérailles de la personne touchée. Même avec de « bonnes intentions », si vous compromettez des identifiants, la personne est déjà compromise et doit réagir exactement comme si elle avait été attaquée par un acteur malveillant.
      C’est si proche d’un acte malveillant qu’il est difficile de sentir la différence.
      Ajoutons que tout le monde devrait aussi se rappeler qu’une partie prenante de Snyk est en train de lancer un produit concurrent de Cursor. Cela rend beaucoup plus difficile de présumer la bonne foi.
    • Très bien. Mais alors pourquoi avoir renvoyé les variables d’environnement de l’utilisateur chez vous ? Pour vérifier la vulnérabilité, il suffisait parfaitement d’envoyer uniquement des valeurs factices plutôt que les vraies valeurs de l’environnement.
    • Au mieux, c’est du grey hat. Les intentions étaient peut-être bonnes, mais cette équipe a créé et distribué, sans autorisation, un logiciel qui accède à des données et les exfiltre, ce qui est très illégal. Ils feraient mieux de consulter leur service juridique avant de publier ce genre de message sur un forum public.
    • Cela paraît plausible, mais pourquoi avoir renvoyé les variables d’environnement via POST ? Même en supposant une totale bonne foi, je ne veux pas qu’un paquet arbitraire possède la sortie de mon env.
    • Il est possible que ce soit réellement le CTO de Snyk, et je recommande le commentaire parce que les gens devraient voir la réponse officielle, mais cela paraît vraiment irresponsable. Il était possible de faire une preuve de concept sans voler réellement les identifiants de développeurs innocents.
      En plus, compte tenu du conflit d’intérêts avec un produit concurrent de Cursor, ils auraient dû être encore plus prudents. La prise de décision comme la réaction sont désastreuses.