Snyk-Sicherheitsforscher veröffentlicht bösartige NPM-Pakete, die offenbar auf Cursor.com abzielen

 (sourcecodered.com)
1 Punkte von GN⁺ 2025-01-14 | 1 Kommentare | Auf WhatsApp teilen
  • Mehrere auf npm veröffentlichte Pakete enthielten Installationsskripte, die offenbar auf Cursor.com abzielen, und übermittelten bei der Installation Systeminformationen an einen externen Webdienst
  • Der Herausgeber war der npm-Nutzer sn4k-s3c und verwendete Namen wie cursor-retreival, cursor-always-local und cursor-shadow-workspace, die an interne Cursor-Pakete erinnern
  • Die von den Paketen abgegriffene env-Ausgabe kann sensible Umgebungsvariablen wie AWS-Schlüssel, npm-Tokens und GitHub-Zugangsdaten enthalten, was das mögliche Schadensausmaß erhöht
  • Der OpenSSF package analysis scanner identifizierte die Pakete als bösartig, und OSV erstellte drei Advisories: MAL-2025-27, MAL-2025-28, MAL-2025-29
  • In den npm-Metadaten erschien eine snyk.io-E-Mail-Adresse von Snyk Security Labs als Herausgeber, später entfernte ein Snyk-Forscher die Pakete und Snyk reagierte mit einem Blogbeitrag

npm-Pakete, die offenbar auf Cursor abzielen

  • Bei der Erkennung bösartiger Pakete durch SourceCodeRed wurden mehrere auf npm veröffentlichte Pakete entdeckt
  • Die Paketnamen wirkten so, als sollten sie an interne Cursor-Pakete erinnern
    • cursor-retreival
    • cursor-always-local
    • cursor-shadow-workspace
  • Als Herausgeber wurde der npm-Nutzer sn4k-s3c angezeigt
  • Die Paketliste könne unter https://www.npmjs.com/~sn4k-s3c eingesehen werden

Verhalten bei der Installation

  • Bei der Installation sammeln die Pakete Systemdaten und senden sie an einen vom Angreifer kontrollierten Webdienst
  • Laut Screenshot greifen die Pakete die Ausgabe des Befehls env ab
  • Die env-Ausgabe kann neben Systemeinstellungen auch sensible Umgebungsvariablen enthalten
    • AWS-Schlüssel
    • npm-Tokens
    • GitHub-Zugangsdaten
    • weitere sensible Umgebungsvariablen
  • Dadurch können schon durch die Installation lokale Umgebungsinformationen nach außen abfließen

Möglichkeit einer Dependency-Confusion-Attacke und Erkennungsergebnisse

  • Solche Pakete treten häufig bei gezielten Dependency-Confusion-Angriffen auf bestimmte Unternehmen auf
  • Ob Cursor.com ein Bug-Bounty-Programm hat oder welcher konkrete Hintergrund vorliegt, wurde nicht bestätigt
  • SourceCodeRed vermutet, dass Cursor möglicherweise private npm-Pakete wie cursor-always-local, cursor-retrieval und cursor-shadow-workspace verwendet
  • Der Angreifer könnte darauf gesetzt haben, dass ein Cursor-Mitarbeiter versehentlich das öffentliche Paket installiert und dadurch Daten übermittelt
  • Der OpenSSF package analysis scanner identifizierte die betreffenden Pakete als bösartig, und OSV erstellte drei Malware-Advisories

Metadaten des Herausgebers

  • In den Metadaten der npm-Pakete verwendete der Herausgeber eine snyk.io-E-Mail-Adresse des Teams Snyk Security Labs
  • Es wird angegeben, dass diese Herausgeber-E-Mail-Metadaten nicht fälschbar seien
  • Das Feld author erwähnt konkret einen Snyk-Mitarbeiter
  • Das Feld author ist zwar fälschbar, aber da der Herausgeber eine verifizierte Snyk-E-Mail hatte, wurde die Vermutung geäußert, dass die Pakete tatsächlich von Snyk stammten

Reaktion der Nutzer und spätere Updates

  • SourceCodeRed informierte npm, doch zu diesem Zeitpunkt waren die Pakete noch nicht als bösartig markiert
  • Viele Sicherheitswerkzeuge für die Software-Lieferkette können nur blockieren, wenn bekannt ist, dass ein Paket bösartig ist
  • Es wird empfohlen, npm-Pakete nicht unüberlegt zu installieren
  • Die betreffenden Pakete enthielten nur zwei Dateien, package.json und index.js oder main.js, was als eines von mehreren Warnsignalen gelten kann
  • Laut Update vom 15. Januar 2025 entfernte ein Snyk-Forscher die Cursor-bezogenen Pakete am Tag nach der Veröffentlichung des Blogbeitrags
  • Am 14. Januar 2025 veröffentlichte The Register einen Artikel dazu: https://www.theregister.com/2025/01/14/snyk_npm_deployment_removed/
  • Am selben Tag veröffentlichte Snyk eine Reaktion im Blog und erklärte sinngemäß, man habe nichts falsch gemacht: https://snyk.io/blog/snyk-security-labs-testing-update-cursor-com-ai-code-editor/

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-01-14
Meinungen auf Hacker News

  • [Korrektur: Nach der Antwort des Cursor-Entwicklers unten sieht es nicht so aus, als sei das von Cursor genehmigt worden] Es klingt so, als gebe es intern bei Cursor eine private NPM-Registry, in der diese Pakete liegen, und als sei es wegen der Funktionsweise von NPM für einen Angreifer leicht, sie dazu zu bringen, stattdessen das gleichnamige Paket aus der öffentlichen Registry zu beziehen.
    Vermutlich hat ein Snyk-Mitarbeiter gefunden oder vermutet, dass Teile des Cursor-Builds auf diese Weise falsch konfiguriert waren, und als Proof of Concept ein Paket hochgeladen. Da in der Paketbeschreibung „for Cursor“ stand, dachte ich, er sei dafür beauftragt worden.
    Wenn dem so ist, ist das keine große Sache; wenn es im Kern darum ging, eine Fehlkonfiguration zu zeigen, bei der die private Registry umgangen wird, hätte ein Sicherheitsforscher für den Proof of Concept wohl keine private NPM-Registry verwenden können.
    Insbesondere wählen viele Proxys die öffentliche statt der privaten Registry, wenn dort die neueste Paketversion höher ist: https://snyk.io/blog/detect-prevent-dependency-confusion-att...

    • Ich bin Cursor-Entwickler. Eine nachvollziehbare Vermutung, aber die Realität ist etwas anders. Die Snyk-Pakete sind lediglich die Namen von Erweiterungen, die wir mitliefern; wir paketieren sie nicht und laden sie in keine Registry hoch.
      Wir handhaben das genauso wie VS Code: https://github.com/microsoft/vscode/tree/main/extensions
      Wir haben Snyk nicht beauftragt, und nachdem wir sie wegen dieser Sache kontaktiert hatten, erhielten wir eine Entschuldigung. Wir haben keine Bestätigung bekommen, was sie genau vorhatten, aber die Erklärung, dass jemand eine Dependency-Confusion-Schwachstelle vermutet hat, klingt plausibel. Allerdings halte ich es für ziemlich unverantwortlich, über das öffentliche NPM tatsächlich Umgebungsvariablen versenden zu lassen.
    • Ein Proof of Concept hätte auch funktioniert, ohne Informationen über den installierenden Host und alle Umgebungsvariablen nach außen zu senden. Das scheint eine Grenze überschritten zu haben.
    • Jemandem vollständigen Zugriff auf die gesamte eigene Umgebung zu geben, also auf die Ausgabe des Befehls env, wäre für die meisten ein großes Problem.
    • Ich bin bei Snyk für DevRel & SecRel zuständig. Um die Gerüchte einzuordnen, habe ich gerade einen Beitrag veröffentlicht, der ziemlich detaillierte Informationen zur Situation enthält: https://snyk.io/blog/snyk-security-labs-testing-update-curso...
    • Hätte das nicht in NPM behoben werden müssen? Ich erinnere mich, dass ein Forscher von PortSwigger dazu vor einiger Zeit einen Vortrag gehalten hat, und soweit ich mich erinnere, waren damals fast alle FAANG-Unternehmen wie Apple, Microsoft und Meta verwundbar.

  • Interessanterweise hat ein Snyk-Mitgründer einen Cursor-Konkurrenten gegründet.
    https://www.tessl.io/ https://techcrunch.com/2024/11/14/tessl-raises-125m-at-at-50...
    Hoffentlich gab es kein Fehlverhalten.

    • Da all meine Interaktionen mit ihnen sehr negativ waren, halte ich die Wahrscheinlichkeit für ziemlich hoch, dass es Fehlverhalten gab.

  • Ich habe das Gefühl, dass man inzwischen alle Entwicklung ernsthaft in einer virtuellen Maschine machen sollte. Eine VM pro Projekt. Es gibt einfach zu viele raffinierte Wege, wie ich unbemerkt durch einen Fehler die Sicherheit ruinieren kann. Der einzige Trost ist, dass ich ein Niemand bin und keine Geheimnisse oder Vermögenswerte habe, die man stehlen könnte.
    Wir vertrauen viel zu viel Code blind: IDEs, Plugins, Entwickler-Utilities, Sprachbibliotheken, Betriebssystempakete und so weiter.

    • Wegen Docker-Containern scheint Vagrant an Popularität verloren zu haben, aber als Methode zum Aufbau von Entwicklungsumgebungen gefällt mir Vagrant immer noch am besten.
      Bei einem früheren Arbeitgeber vor ein paar Jahren waren Webbrowser und Entwicklungstools auf dem Laptop verboten. Wenn man einen Browser brauchte, musste man Citrix verwenden; wenn man programmieren musste, nutzte man VDI oder führte die Tools in einer VM aus.
      Damals wirkte diese Vorgehensweise fast verrückt, aber ich verstehe sie zunehmend.
    • Das eigentliche Problem ist die Grafikleistung von VMs. Die ist immer noch einfach nicht gut. Wenn man Cinnamon in einer VM laufen lässt, ist es fast unmöglich, GL-Beschleunigung ordentlich zum Laufen zu bringen.
      NVIDIA sperrt virtualisierte GPU-Funktionen hinter Enterprise-Karten weg, sodass man auf wirkungslose Befehlsübersetzung angewiesen ist.
      Fast den gesamten übrigen VM-Overhead kann man ertragen, aber eine ruckelnde und nicht reagierende GUI wirkt sich ergonomisch schlechter aus, als man denkt, und zieht merkwürdigerweise auch andere Leistung nach unten.
      Wenn dieses Problem zumindest für die Virtualisierung von Linux auf Linux gelöst würde, wäre die Option, alles zu virtualisieren, deutlich realistischer.
    • Es ist schrecklich, wie sehr Vertrauen inzwischen erodiert ist, und auch monatliche Betriebssystem-Updates im GB-Bereich beruhigen nicht. Die Idee, pro Projekt eine stabile, isolierte VM zu haben, gefällt mir. Gibt es dafür ein standardmäßiges Open-Source-Tool?
      Konkret bin ich gerade dabei, meine Go- und Zig-Entwicklungsumgebung von einem alten Mac auf M1 mit Asahi Linux umzuziehen, und scheitere schon daran, Ersatz für TrueCrypt und Little Snitch zu finden. Unterstützen solche VM-Tools verschlüsselte VMs und Firewall-Regeln? Vagrant wurde hier erwähnt und scheint Netzwerkkapselung zumindest teilweise zu lösen, aber was könnte man sonst empfehlen?
    • Ich weiß, wie sich das anfühlt, und habe selbst oft darüber nachgedacht. Im Moment möchte ich es nicht machen, aber der Hauptgrund ist nicht der Aufwand.
      Eine VM kann mich schützen, aber nicht die Nutzer der Software, die ich baue. Wie kann ich ein Produkt, das ich selbst nur im Schutzanzug anfassen kann, an Kunden ausliefern und erwarten, dass sie es ohne Schutz sicher verwenden?
      Das ist nicht die Umgebung, die ich will.
      Die aktuelle Lösung besteht darin, bei Abhängigkeiten extrem wählerisch zu sein. Genauer gesagt: Ich denke, man sollte nicht Projekten oder Firmen vertrauen, sondern nur Menschen. Das ist nicht einfach, aber im Moment sehe ich keine bessere Alternative.
    • Ich entwickle mehrere Projekte unter Linux. Vor allem weil ich befürchte, dass Tools, Build-Skripte oder Tests sensible Daten lesen oder versehentlich Daten zerstören könnten, beschränke ich mit Linux-Namespaces und bubblewrap den Dateizugriff während der Projektarbeit.
      In einer einfachen Dot-Datei pro Projekt trage ich Dateisystem-Binds ein, und wenn ich während der Arbeit ein neues Terminal öffne, wird es anhand dieser Dot-Datei automatisch isoliert. Die kognitive Belastung ist sehr gering, und es integriert sich fast nahtlos. Ich vermute, viele Entwickler haben ähnliche Skripte. Früher habe ich nach so einem Projekt gesucht, aber nichts gefunden; ich weiß nicht, ob es zu simpel ist, um daraus ein Projekt zu machen, oder ob ich einfach nicht weiß, wie andere Leute das nennen. Es wäre schön, etwas als Referenz zu haben.
      Den Netzwerkzugriff beschränke ich nicht. Ich habe mit Experimenten gearbeitet, bei denen sämtlicher Traffic aufgezeichnet und automatisch ein Man-in-the-Middle-Proxy eingerichtet wurde, aber für den normalen Gebrauch war das nicht komfortabel genug. Natürlich bleibt die Kernel-Angriffsfläche bestehen. Meine Hauptsorge ist jedoch, dass Dateien gelesen oder zerstört werden.

  • Der Teil des Artikels, dem ich nicht zustimme, ist die Aussage: „Man sollte NPM-Pakete nicht blind installieren, und es gibt Signale, an denen man erkennen kann, ob ein Paket verdächtig ist. Diese Pakete bestehen nur aus zwei Dateien, package.json und index.js oder main.js, und das ist eines der Flags zur Beurteilung, ob sie legitim sind.“
    Das mag für Top-Level-Pakete einigermaßen funktionieren, aber es ist praktisch unmöglich, auch alle transitiven Abhängigkeiten zu prüfen.
    Wenn man ein Paket mit 400 Abhängigkeiten einbindet, wie soll man auch nur 10 % dieser Angriffsfläche vernünftig überprüfen? https://gist.github.com/anvaka/8e8fa57c7ee1350e3491#top-1000...

    • Der passende Sicherheitshinweis dafür ist ein anderer: kein Paket mit 400 Abhängigkeiten einbinden.
    • An dieser Stelle lag die große Richtung von SELinux richtig. Wenn man Dateien vorab nach Sensitivität der Daten klassifiziert und den Zugriff entsprechend verweigert, löst das dieses Problem weitgehend, etwa dass eine NPM-Installation nicht auf id_rsa zugreifen kann.
    • Wie zum Teufel hat eine React-Karussell-Komponente über 400 Abhängigkeiten …
    • Bei uns in der Firma verwenden wir ein hervorragendes Sicherheitstool namens Snyk. Unbedingt ansehen /s

  • Snyk ist auch ein Unternehmen, das öffentliche Schlüssel nicht rotiert, sondern sie einfach ohne Vorankündigung austauscht: https://github.com/snyk/cli/pull/5649
    Wenn ein Projekt von GitHub zu einem anderen Repository-Hosting umzieht, markieren sie es als „abandoned“, und selbst wenn es neue Releases auf npm/PyPI gibt, bleibt es weiterhin ein aufgegebenes Projekt.
    Ich glaube nicht, dass ihre Kompetenz ihrem Ruf entspricht.
    Außerdem hat mich ein Snyk-Vertriebsmitarbeiter per E-Mail beleidigt. Offenbar bedeutet kein Interesse am Kauf des Produkts, dass man ein unfähiger Entwickler ist, der nur von Sicherheitslücken durchzogene Software verwenden kann.

    • Sie bestrafen auch Bibliotheken, die fertig entwickelt sind und nur minimale Wartung benötigen.
      Das wirkt wie komplett verkehrte Software, die Unternehmen kaufen, weil Versicherer verlangen, dass Punkte auf einer Sicherheits-Checkliste abgehakt werden.
    • Dieses Label „abandoned“ ist besonders bedauerlich. Ich versuche mich auch gerade von GitHub zu lösen, und es fühlt sich so an, als hätte GitHub zu viel Kontrolle.
      Codeberg sieht interessant aus, und wenn man die Wartung stemmen kann, wirken selbst gehostete Optionen wie Forejo ebenfalls gut.
    • Ein Projekt als „abandoned“ einzustufen, nur weil es in ein anderes Repository als GitHub umgezogen ist, und das beizubehalten, obwohl es neue Releases auf npm/PyPI gibt – das ist doch ein Zeichen für ein gutes Team /s
      Über Snyk habe ich außer einem gewissen Stolz nicht viel gehört, aber das ist eine ziemlich interessante Perspektive.
    • Du könntest den Text dieser E-Mail doch sicher in angemessen geschwärzter Form bereitstellen?

  • Ohne weiteren Kontext sieht das auch für Snyk nicht gut aus. Es bedeutet, dass ein Mitarbeiter den eigenen Dienst per NPM in einer realen Umgebung getestet hat oder dass es bei einer legitimen Prüfung von Cursor an Kontrollen und Verfahren fehlte, die die Nutzung öffentlicher Ressourcen verhindern.

    • Warum soll das nicht gehen? NPM verhält sich seltsam, wenn es ein öffentliches Paket mit demselben Namen wie ein Paket in einem privaten Repository gibt, und holt in manchen Fällen das öffentliche Paket. Ich kenne das unter Begriffen wie Package-Squatting. Vielleicht wurde im Rahmen der Bewertung nur gezeigt, dass das möglich ist. Meiner Meinung nach gab es keinen Schaden und kein Problem.

  • Das wirkt wie ein White-Hat-Audit von Snyk. oastify.com ist der Standardserver von Burp Collaborator, daher wurde es wohl erkannt.
    Für den Test hätte ein privates npm-Repository verwendet werden müssen, und ein lokales Überschreiben ist nicht schwer. Auch ein eigener Collaborator-Server hätte genutzt werden müssen.

    • Weil aktiv Daten exfiltriert wurden, ist es kein White-Hat. Wenn es nur darum gegangen wäre zu beweisen, dass es funktioniert, hätte auch ein console.log, ein Fehlschlagen von npm install oder eine Methode ohne Extraktion der Payload gereicht.

  • NPM scheint Jobs in der Sicherheitsbranche zu schaffen. Es ist ein nicht zu reparierendes Chaos, und ich hoffe, dass Konkurrenten wie JSR genug Druck auf die Organisation ausüben.

    • Das ist kein reines NPM-Problem, sondern ein allgemeines Problem des Vertrauens in Third-Party-Libraries. Auch auf Plattformen wie NuGet gibt es Exploits, wenn auch deutlich seltener. Bei JSR wird es sie ebenfalls geben. Durch Unveränderlichkeit ist es sicherer, aber sie verhindert nicht, dass bösartige Pakete heruntergeladen werden, bevor sie auffliegen.
      Eher ist damit zu rechnen, dass Regulierungen wie DORA und NSIS Audits von Third-Party-Paketen zunehmend verlangen werden. Das wird in wichtigen Branchen erzwingen, dass sich die Art der Entwicklung ändert. Außerdem glaube ich, dass im LLM-Zeitalter die Nutzung externer Pakete deutlich zurückgehen wird. Warum sollte man ein externes Paket einbinden, nur um etwa eine OpenAPI-Spezifikation zu erzeugen? Ein LLM kann mit ein bis zwei Stunden Konfiguration das benötigte CLI-Skript schreiben. Ebenso muss man ein LLM nicht direkt verwenden, um die langweiligen Teile des Codes automatisch zu generieren; man kann es ein CLI-Tool dafür bauen lassen. Dann ist man nicht von externen Faktoren abhängig, und auch wenn diese CLI-Tools fast garantiert chaotischer Cowboy-Code sind, lässt sich der Output durch Nachschärfen des Tools in die gewünschte Form bringen.
      Wenn man Sprachen wie Go betrachtet, die das Nötige in Standardpakete packen, sieht man eine Welt, in der sich schon mit der Standardbibliothek sehr vieles sehr einfach erledigen lässt.

  • Etwas off-topic, aber hat schon einmal jemand ein ordentliches SBOM für Snyks eigene Tools und Services bekommen? Ich frage, weil sie unserem Unternehmen eine Lösung zur Erstellung von SBOMs verkaufen wollen.

    • Snyk wurde von ehemaligen Angehörigen der israelischen Unit 8200 gegründet.
      Selbst wenn man mich dafür bezahlen würde, würde ich es wohl nicht installieren. Unit 8200 bringt ständig Gründer hervor und finanziert sie, sodass es sich so anfühlt, als hätten sie – ähnlich wie die NSA – bereits einen Fuß in der Tür.
    • Mit Syft habe ich bessere Ergebnisse erzielt.
    • Nach meiner Erfahrung gab es viele False Positives.

  • Snyk Research Labs leistet der Community regelmäßig Beiträge durch Tests und Forschung an verbreiteten Softwarepaketen. Diese Cursor-Forschung war nicht böswillig, und die Pakete enthielten Snyk Research Labs sowie Kontaktinformationen des Forschers. Wir haben sehr gezielt Dependency Confusion in einigen VS-Code-Erweiterungen untersucht, und diese Pakete waren nicht dafür gedacht, direkt von Entwicklern installiert zu werden.
    Snyk hält sich an eine Responsible-Disclosure-Richtlinie. Niemand hat dieses Paket bezogen, aber falls es jemand getan hätte, hätten wir sofort nachgefasst.

    • Einen Angriff im öffentlichen Raum auszulegen und darauf zu hoffen, dass er das Ziel trifft, ist das genaue Gegenteil von verantwortlichem Handeln. Der einzige „gute“ Aspekt ist, dass ihr auf frischer Tat erwischt wurdet, bevor jemand anderes von einer Querschläger-Kugel getroffen wurde.
      Als Reaktion klingt das, als würdet ihr dem Betroffenen einen Entschuldigungsbrief zur Beerdigung schicken. Selbst wenn es „gut gemeint“ war: Wenn Zugangsdaten kompromittiert werden, ist die Person bereits kompromittiert und muss genauso reagieren, als wäre es ein böswilliger Angreifer gewesen.
      Das liegt so nah an Böswilligkeit, dass der Unterschied kaum zu erkennen ist.
      Außerdem sollten alle daran denken, dass ein Snyk-Stakeholder derzeit offenbar ein Konkurrenzprodukt zu Cursor herausbringen will. Das macht es deutlich schwieriger, gute Absichten zu unterstellen.
    • Schön. Aber warum wurden dann die Umgebungsvariablen der Nutzer nach Hause geschickt? Für den Nachweis der Schwachstelle hätten Dummy-Werte statt echter Umgebungswerte völlig ausgereicht.
    • Im besten Fall ist das Grey-Hat. Die Absicht mag gut gewesen sein, aber dieses Team hat Software erstellt und verteilt, die ohne Erlaubnis auf Daten zugreift und sie exfiltriert, und das ist höchst illegal. Bevor man so etwas in ein öffentliches Forum schreibt, sollte man besser mit der Rechtsabteilung sprechen.
    • Klingt zwar plausibel, aber warum wurden die Umgebungsvariablen per POST zurückgeschickt? Selbst wenn es vollständig gut gemeint war, möchte ich nicht, dass ein beliebiges Paket meine env-Ausgabe besitzt.
    • Es ist gut möglich, dass das tatsächlich der Snyk-CTO ist, und die offizielle Antwort sollten die Leute sehen, deshalb empfehle ich sie hoch. Trotzdem wirkt das wirklich unverantwortlich. Man hätte einen Proof of Concept liefern können, ohne tatsächlich die Zugangsdaten unschuldiger Entwickler zu stehlen.
      Zudem hätte man angesichts des Interessenkonflikts mit einem Cursor-Konkurrenzprodukt besonders vorsichtig sein müssen. Sowohl die Entscheidungsfindung als auch die Reaktion sind miserabel.