So identifizieren Sie bösartige NX-Versionen in Ihrer Codebasis

Kürzlich ist es wieder passiert: Einige böswillige Akteure haben einen ausgeklügelten Supply-Chain-Angriff gestartet. Das nx-team und mehrere Sicherheitsforscher (1, 2) haben bereits über diesen Vorfall berichtet. Hier finden Sie eine kurze Zusammenfassung:

Was ist passiert?

nx ist ein Paket mit etwas mehr als 23 Millionen Downloads im NPM-Paketregister. Es umfasst mehrere Plugins, die Entwickler zur Vereinfachung von Code-Verwaltungsaktivitäten verwenden, wie z. B. einige Hilfsfunktionen zum Schreiben von Dateien, zum Aktualisieren der Konfiguration (devkit), zum Verwalten des Knotens selbst (node) oder zum Linitieren von JavaScript- und Typescript-Code (lint).

Die Versionen um 20.9.0 und 21.5.0 bzw. 3.2.0 (key & enterprise-cloud) wurden böswillig verändert. Sie führten eine KI-basierte Suche durch, bei der die lokalen Dateistrukturen des Arbeitsbereichs des Entwicklers ausgewertet und alle Arten von Geheimnissen zusammengetragen wurden. Diese wurden dann unter Verwendung der Git-Anmeldedaten des Entwicklers in einem öffentlichen Git-Repository veröffentlicht.

Was kann man dagegen tun?

Der allererste Schritt wäre, festzustellen, ob jemand in Ihrem Unternehmen die betroffenen nx-Tools verwendet. Wenn Sie TrustSource verwenden, müssen Sie lediglich den „Component Impact Report” öffnen und nach den betroffenen Komponenten in den angegebenen Versionen suchen, z. B. @nx/devkit in Version 21.5.0 oder 20.9.0. TrustSource listet Ihnen alle Projekte auf, in denen genau diese Komponentenversionen in der Liste der transitiven Abhängigkeiten enthalten sind.

Dies ist ein gutes Beispiel dafür, warum transitive Abhängigkeiten so wichtig sind. nx hat etwa 663 abhängige Projekte, oder anders ausgedrückt: Es gibt 663 andere Tools, die nx-Tools verwenden. Sie können sich vorstellen, wie schnell und weit sich die Verbreitung ausdehnen kann.

Wenn ein Projekt jedoch die betroffenen Versionen verwendet, müssen die Entwickler davon ausgehen, dass ihre gesamte CI/CD-Kette kompromittiert ist. Jeder Entwickler sollte überprüfen, ob er ein Repository mit „s1ngularity” im Namen hat, das in den letzten 2–3 Wochen veröffentlicht wurde. Alle Anmeldedaten, die Sie in diesem Repository finden, müssen als geleakt betrachtet werden.

Bevor Sie diese jedoch ersetzen, sollten Sie Ihren Arbeitsbereich bereinigen!

Weitere Informationen und Details zur Bereinigung Ihres Arbeitsbereichs finden Sie in diesem Artikel.

Was können wir daraus lernen?

Wir sind froh, dass wir dieses Tool nicht verwenden. Aber es gibt zwei interessante Erkenntnisse für uns:

a) Bislang haben wir uns sehr auf das Lieferartefakt konzentriert. Aus diesem Grund umfasst ts-scan beispielsweise standardmäßig keine Dev-Abhängigkeiten. Um Dev-Abhängigkeiten in Ihren Scan einzubeziehen, müssen Sie den Parameter npm:includeDevDependencieshinzufügen. Wenn Sie noch nie einen Scan mit diesen Parametern durchgeführt haben, ist es sehr wahrscheinlich, dass der oben genannte TrustSource-Komponenten-Auswirkungsbericht keine Ergebnisse anzeigt, obwohl die Tools möglicherweise von Ihren Entwicklern verwendet werden.

Dies ist wichtig zu verstehen und der Grund, warum wir empfehlen, alle Entwickler in Ihrem Unternehmen über die Situation zu informieren. Wir empfehlen sogar, Scans mit dem oben genannten Parameter anzufordern und den Bericht in den nächsten Tagen und Wochen erneut auszuführen. Einige der 663 Tools, die nx verwenden, nutzen es möglicherweise im Hintergrund, z. B. nx-python codegen, reactionary, goodiebag usw., sodass es für Ihre Entwickler möglicherweise nicht offensichtlich ist.

Wir empfehlen außerdem, die Scans, die die Entwicklungsabhängigkeiten enthalten, in ein separates Projekt/Modul zu verschieben. Angenommen, Sie haben Projekt A mit den Modulen A1 und A2, dann könnten die Scans mit den Entwicklungsabhängigkeiten auf Projekt A-DEV mit den Modulen A1 und A2 abzielen. Auf diese Weise könnten Sie alle Entwicklungsabhängigkeiten verfolgen, sie aber aus den üblichen Compliance-Abläufen heraushalten. Projekte, die kein PROJECTNAME-DEV bereitstellen, können einfach durch Sortieren der Projektliste in aufsteigender Reihenfolge identifiziert werden.

b) Oft sind Entwicklungsumgebungen offen und weniger sicher. Oft hört man den Spruch „Wer sollte in Betracht ziehen, dies zu brechen, und was könnte er dadurch erreichen?“ Aber hier sehen Sie, welche Auswirkungen dies haben kann. Angefangen bei der Verschlüsselung bis hin zur Offenlegung von Informationen und Anmeldedaten könnte die Arbeit jedes Entwicklers direkt beeinträchtigt werden. Indirekt kann dies zur Einführung von bösartigem Code führen, die Produkte des Entwicklers gefährden, den Ruf des Unternehmens des Entwicklers schädigen und das Geschäft seiner Kunden beeinträchtigen.

Während dies vor fünf Jahren noch unwahrscheinlich gewesen wäre, muss es heute als Realität berücksichtigt werden. Sie sollten Ihre Entwicklungsumgebungen entsprechend einrichten (interne Paket-Proxys, geschützte und klar dokumentierte Builds (SBOMs), strenger Schutz von CI/CD-Anmeldedaten, API-Schlüsseln und Verwendung von Schlüsselspeichern usw.). Führen Sie von Anfang an das richtige Risikomanagement ein: Was könnte schiefgehen, wenn unser Code bösartig/fehlerhaft/gehackt ist? Wie könnte das passieren? Welche Auswirkungen hätte dies auf die Vertraulichkeit/Verfügbarkeit oder Integrität der Daten/Geschäfte/Geschäftstätigkeiten unserer Kunden?

Wenn Sie Unterstützung bei der Beantwortung dieser Fragen benötigen, wenden Sie sich gerne an uns. Unsere Muttergesellschaft ist darauf spezialisiert, ihre Kunden bei der Beantwortung solcher Fragen zu unterstützen und Strategien zur Sicherung von CI/CD und den Entwicklungsergebnissen zu entwickeln. Weitere Informationen finden Sie hier.