Snyk Security Labs: Testergebnisse zum KI-Code-Editor Cursor.com

Das Team von Snyk Security Labs möchte Schwachstellen in Software finden und dabei helfen, sie zu beheben, die von Entwicklerinnen und Entwicklern auf der ganzen Welt genutzt wird. Übergeordnetes Ziel ist es, die Softwaresicherheit zu verbessern. Dafür untersuchen wir Tools, die von Entwicklerinnen und Entwicklern verwendet werden, darunter neue und beliebte Softwarelösungen. Angesichts des rasanten Aufstiegs von KI-Tools – insbesondere des schnell wachsenden Bereichs KI-gestützter Entwicklungsumgebungen – beziehen wir solche Software in unsere Forschungszyklen ein.

Eine solche Software ist der KI-Code-Editor von Cursor, ein Konkurrenzprodukt zu VSCode und anderen beliebten Entwickler-IDEs. Diese Software integriert KI-gestützte Programmierhilfe in die Entwicklererfahrung. Bei dieser Art von Forschung hoffen wir, keine Schwachstellen zu finden. Falls wir doch welche entdecken, können wir sie verantwortungsvoll offenlegen und so dafür sorgen, dass alle Entwicklerinnen und Entwickler, die diese Software nutzen, besser geschützt sind. Cursor ermutigt öffentlich dazu, Sicherheitslücken im Produkt zu melden, und hat dafür einen Leitfaden sowie einen etablierten Meldekanal veröffentlicht.

Im Rahmen ihrer Forschung stellte das Snyk Security Labs Research-Team fest, dass die Software mehrere private Erweiterungen enthält. Erweiterungen für VSCode (auf dem der KI-Code-Editor Cursor basiert) werden ähnlich wie klassische Node.js-Abhängigkeiten erstellt und in package.json-Dateien beschrieben. Unsere Überlegung zu einem möglichen Angriffsvektor war, dass Cursor die VSCode-Erweiterungen intern als NPM-Pakete behandelte und sie während der Builds aus einem internen Repository bezog. Wäre das der Fall gewesen (inzwischen wissen wir, dass dem nicht so ist) und wäre das Build-System falsch konfiguriert gewesen, hätte die Gefahr eines Dependency-Confusion-Angriffs bestanden. Obwohl wir diese Konfiguration für unwahrscheinlich hielten, war sie ein lohnender Forschungsansatz: Falls sie tatsächlich vorgelegen hätte, hätte dies erhebliche Auswirkungen auf die Systeme von Cursor und dessen Nutzerinnen und Nutzer haben können.

Um diese Theorie zu überprüfen, luden wir Pakete mit Namen, von denen wir vermuteten, dass sie beim Build des KI-Code-Editors Cursor verwendet werden, in das öffentliche NPM-Repository hoch. Dies ist eine gängige Methode, um auf Dependency Confusion zu testen. Es war äußerst unwahrscheinlich, dass diese Pakete von anderen Entwicklerinnen und Entwicklern oder Systemen als denen bei Cursor installiert würden, die wir überprüften – tatsächlich war es unwahrscheinlich, dass sie überhaupt installiert würden. Dennoch kennzeichneten wir alle Pakete in ihren Beschreibungen als Testpakete des Snyk Security Labs-Teams, gaben eine direkte E-Mail-Adresse für die Kontaktaufnahme mit dem Autor an und legten ein kurzes Verfügbarkeitsfenster fest (24 Stunden). Der Quellcode dieser Pakete war sehr klein und versuchte nicht, sein Verhalten zu verschleiern. Die Pakete führten HTTP-Anfragen an unsere Forschenden durch und übermittelten dabei den Benutzernamen, den Hostnamen und das aktuelle Verzeichnis sowie (in späteren Versionen) Umgebungsvariablen. Diese ausgehenden Anfragen waren erforderlich, um festzustellen, ob eine vollständig „blinde“ Installation stattgefunden hatte. In der späteren Version ergänzten die Forschenden von Snyk die Daten um weitere Felder, um falsch positive Ergebnisse zu vermeiden, die dadurch entstehen könnten, dass automatisierte Scanner die Pakete herunterladen und ausführen – ein Vorgang, der außerhalb des Umfangs des Proof of Concept lag. Damit Snyk dem Cursor-Sicherheitsteam zuverlässige und korrekte Berichte übermitteln konnte, mussten wir bestätigen können, dass die Installationen von Cursor ausgeführt wurden und dass es sich bei dem von uns ermittelten Sachverhalt um ein tatsächliches Dependency-Confusion-Problem handelte.

Letztendlich fand Snyk Security Labs keine Hinweise darauf, dass Cursor in irgendeiner Weise für Dependency-Confusion-Angriffe anfällig ist. Außerdem wurden uns während unserer Tests keine sensiblen Daten offengelegt. Solche Angriffsvektoren – wenig komplex und wenig wahrscheinlich, aber mit großen potenziellen Auswirkungen – sind ein wichtiges Forschungsgebiet. Denn die niedrige Einstiegshürde könnte es böswilligen Akteuren relativ leicht machen, diesen Angriff auszuführen. Snyk Security Labs führt regelmäßig Schwachstellenforschung durch und strebt höchste Teststandards an, um die Sicherheit von Entwicklerinnen und Entwicklern zu verbessern.

Mit Tests auf solche Schwachstellen möchte Snyk Security Labs Angreifern zuvorkommen und sicherstellen, dass die Software und Systeme, die Entwicklerinnen und Entwickler auf der ganzen Welt täglich nutzen, sicher sind.