Diese Geschichte beginnt, als Sébastien Lorber, Betreuer von Docusaurus, dem React-basierten Open-Source-Dokumentationsprojekt, eine Pull-Request-Änderung am Paketmanifest bemerkt. Hier ist die vorgeschlagene Änderung für das beliebte cliui npm-Paket:

Konkret möchten wir unsere Aufmerksamkeit auf die Änderung der NPM-Abhängigkeiten lenken, die eine unbekannte Syntax verwenden:

  "dependencies": {
    "string-width": "^5.1.2",
    "string-width-cjs": "npm:string-width@^4.2.0",
    "strip-ansi": "^7.0.1",
    "strip-ansi-cjs": "npm:strip-ansi@^6.0.1",
    "wrap-ansi": "^8.1.0",
    "wrap-ansi-cjs": "npm:wrap-ansi@^7.0.0"

Die meisten Entwickler würden erwarten, dass im Wert eines Pakets oder vielleicht einer Git- oder dateibasierten URL ein Semver-Versionsbereich angezeigt wird. In diesem Fall gibt es jedoch eine spezielle npm:-Präfixsyntax. Was bedeutet das?

Was ist ein NPM-Paket-Aliasing?

Der npm-Paketmanager unterstützt eine Paket-Aliasing-Funktion, die die Definition benutzerdefinierter Auflösungsregeln für Pakete ermöglicht. Daher wird das Paket überall dort, wo durch Code oder die Sperrdatei referenziert wird, in den Namen und die Version aufgelöst, die durch den Alias ​​angegeben sind.

Im Falle der in dieser Pull-Anfrage vorgeschlagenen Änderung wird das Paket string-width-cjs in den Versionen ^4.2.0 in das Paket string-width aufgelöst. Das bedeutet, dass es einen node_modules-Verzeichniseintrag für string-width-cjs geben wird, jedoch mit dem Inhalt von string-width@^4.2.0 und ähnlichem Verhalten in der Sperrdatei (package-lock.json).

Paketaliasing ist eine NPM-Paketmanagerfunktion, die in Fällen wie der Unterstützung von ESM vs. CJS verwendet werden kann.

Trotzdem kann Paket-Aliasing missbraucht werden. In einem Artikel und einer Sicherheitsoffenlegung aus dem Jahr 2021 zeigte Nishant Jain, ein Snyk-Botschafter, wie das offizielle npmjs-Register dazu verleitet werden könnte, Abhängigkeitsinformationen auf der Grundlage von Paket-Aliasing als Teil einer Abhängigkeitsverwirrung und Sicherheitsbedenken in der Lieferkette falsch anzugeben.

Die Pull-Anfrage war harmlos und es bestand kein Risiko eines Angriffs auf die Lieferkette. Sébastiens Bedenken hinsichtlich des Paketnamens führten jedoch zur Entdeckung eines potenziellen Sicherheitsrisikos.

Verdächtiges Verhalten in NPM-Sperrdateien in Bezug auf bösartige Module finden

Um die Pull-Anfrage zu untersuchen, verwendete Sébastien lockfile-lint. Dieses Tool überprüft Sperrdateien wie „package-lock.json“ oder „garn.lock“ auf Anzeichen von Manipulation und stellt so sicher, dass keine schädlichen Pakete anstelle des ursprünglichen npm-Pakets eingeschleust wurden.

Beim Ausführen des Tools wurden die folgenden Warnungen angezeigt:

npx lockfile-lint --path package-lock.json --allowed-hosts yarn npm --validate-https --validate-package-names

detected resolved URL for package with a different name: string-width-cjs
    expected: string-width-cjs
    actual: string-width

detected resolved URL for package with a different name: strip-ansi-cjs
    expected: strip-ansi-cjs
    actual: strip-ansi

detected resolved URL for package with a different name: wrap-ansi-cjs
    expected: wrap-ansi-cjs
    actual: wrap-ansi

 ✖ Error: security issues detected!

Haftungsausschluss: lockfile-lint ist ein Tool, das ich 2019 im Anschluss an meine Veröffentlichung entwickelt habe, in der die Sicherheitsbedenken bei Lockfiles offengelegt wurden: Warum NPM-Lockfiles eine Sicherheitslücke für das Einschleusen bösartiger Module sein können.

Hohe Warnung: Beliebte Paket-Doppelgänger auf npm

Angesichts der oben genannten lockfile-lint-Ergebnisse hat Sébastien diese Paketnamen auf npm nachgeschlagen und überraschenderweise festgestellt, dass diese in der öffentlichen npm-Registrierung vorhanden sind:

• https://www.npmjs.com/package/string-width-cjs
• https://www.npmjs.com/package/strip-ansi-cjs
• https://www.npmjs.com/package/wrap-ansi-cjs

Sébastien stellte fest, dass diese Paketnamen nicht nur auf npm existieren, sondern auch verdächtige Merkmale aufweisen. Die Pakete waren nicht an ein öffentliches Quellcode-Repository gebunden, enthielten bei der Überprüfung keinen tatsächlichen Code und wurden anonym ohne damit verbundene persönliche Informationen veröffentlicht.

Wenn man sich das NPM-Paket „strip-ansi-cjs“ ansieht, gibt es weder eine README-Datei noch ein Quellcode-Repository. Es gibt jedoch viele legitime und beliebte Pakete, die auf dasselbe Verhalten hinweisen.

Tatsächlich ist dieses spezielle Paket beliebt, wie wir an seinen 529 abhängigen Paketen (andere Pakete, die von diesem abhängen) und 7.274 wöchentlichen Downloads sehen können.

Ein Blick auf den Code für „strip-ansi-cjs“ zeigt, dass es in diesem Paket nur eine einzige Datei gibt, die Paketmanifestdatei package.json.

Warum erhält ein Paket, das nichts tut, so viele Downloads und warum sind so viele andere Pakete davon abhängig?

Schauen wir uns den Autor dieser NPM-Pakete an.

Alle drei Pakete sind Eigentum von himanshutester002 und ihre Pakete wurden alle letztes Jahr mit programmatischen Versionsnummern veröffentlicht. Einige interessante Beobachtungen:

• Das NPM-Paket isaacs-cliui ist möglicherweise ein Tippfehlerversuch an Isaacs eigener Abzweigung des Cliui-Projekts und dem legitimen NPM-Paket unter ihrem Namensraum: @isaacs/cliui.
• Das azure-sdk-for-net-npm-Paket ist möglicherweise ein Versuch einer Kampagne zur Abhängigkeitsverwirrung, um private Pakete mit demselben Namen anzugreifen.
• Das Link-Deep-NPM-Paket übernimmt eine beliebte Funktion im Zusammenhang mit Dienstprogrammpaketen wie Lodash und anderen.

Sie können auch feststellen, dass der Benutzer himanshutester002 keine identifizierbaren Informationen auf dieser Benutzerprofilseite auf npmjs hat.

Wir haben zuvor festgestellt, dass das npm-Paket „strip-ansi-cjs“ über 500 andere Pakete hat, die es verwenden, was möglicherweise ein positiver Indikator für die Beliebtheit ist. Schauen wir sie uns an:

Dies mag aufgrund seiner Aufnahme in die Liste glaubwürdig erscheinen, aber ist es das wirklich?
Namen wie „clazz-transformer“ oder „react-native-multiply“ oder vielleicht „gh-monoproject-cli“ scheinen beispielsweise legitim zu sein, aber sind sie das auch?

Hier ist die React-Native-Multiply-NPM-Paketseite:

Für dieses Paket gibt es praktisch keine Downloads und sein Autor ist ein anonymer NPM-Benutzer ohne identifizierbare Informationen. Das Quell-URL-Repository, zu dem dieses Paket umleitet, ist das nicht vorhandene https://github[.]com/hasandader/react-native-multiply. Auch das GitHub-Benutzerprofil sieht sehr verdächtig aus und es mangelt an praktischer Aktivität.

Während das npm-Paket Quellcode zu enthalten scheint, zeigt ein genauerer Blick, dass es sich um ein generiertes Codebeispiel für einen „Hallo Welt“-Anwendungsprototyp handelt.

Sie müssen sich auch fragen: Wenn dieses Paket nur eine Multiplikationsbibliothek ist, warum benötigt es dann 776 Abhängigkeiten, um Folgendes zu tun:

import { multiply } from 'react-native-multiply';
const result = await multiply(3, 7);

Während einige Witze darüber machen, dass JavaScript durch übermäßige Abhängigkeitsnutzung zu einem astronomischen Baum verschachtelter Pakete beiträgt, ist ein Projekt mit 776 direkten Abhängigkeiten unangemessen groß.

Unter all diesen Abhängigkeiten befinden sich die drei verdächtigen NPM-Pakete, mit denen unsere Geschichte begann: string-width-cjs, strip-ansi-cjs und wrap-ansi-cjs:

Wir haben erwähnt, dass eine der Strip-Ansi-CJS-Abhängigkeiten den Namen clazz-transformer trägt. Schauen wir es uns an:

Lassen Sie uns erklären, was hier passiert. ​​Das npm-Paket clazz-transformer ist auf seiner README-Seite absichtlich falsch mit dem Titel „class-transformer“ benannt. Darüber hinaus korreliert sein Quellcode-Repository, https://github[.]com/typestack/class-transformer, nicht mit dem Paketnamen, was Bedenken hinsichtlich seiner Legitimität aufwirft.

Der Typstack/Class-Transformer des zugehörigen Repositorys auf GitHub verfügt über die package.json-Datei wie folgt:

Die package.json-Datei auf GitHub zeigt keine Deklaration von Abhängigkeiten, wenn wir jedoch den Quellcode des tatsächlichen Pakets auf npmjs untersuchen, sehen wir die 437 Abhängigkeiten, mit denen dieser Clazz-Transformer gepackt ist. Auch hier bündeln sie sehr praktisch die drei verdächtigen *-cjs-Pakete:

Weitere Gedanken zu verdächtigen NPM-Paketergebnissen

Bevor wir weitere Schlussfolgerungen ziehen, ist es wichtig, einige der oben beobachteten Merkmale der npm-Pakete zu erwähnen:

• Die React Native-Pakete scheinen vom Scaffold-Tool „create-react-native-library“ abgeleitet zu sein. Dieses Tool enthält auch das Standardbeispiel für die Multiplikationsfunktion als Teil des Standardquellcodes, der für ein neues Projekt generiert wird.
• Pakete verfügen über Verzeichnis- und Dateistrukturen und Abhängigkeiten, die aus dem Starter-Boilerplate von Next.js 14 abgeleitet werden könnten, z. B. diejenigen, die mit npx create-next-app@14 erstellt wurden.

Unsere Kollegen bei Sonatype haben bereits ähnliche Fälle der Überflutung von Open-Source-Registern mit Paketen identifiziert. In diesen Fällen bestand das ultimative Ziel für Entwickler darin, sich mit Tea-Tokens zu belohnen, einer Web3-Plattform zur Monetarisierung von Open-Source-Software.

Das Auffinden einiger tea.yaml-Dateien in den genannten Paketen stützt die These weiter, dass ein Teil des Zwecks dieser Kampagne darin besteht, Tea-Tokens durch den Missbrauch von Tea zu schürfen.

Anfang dieses Jahres, am 14. April 2024, veröffentlichte ein Benutzer des Teeforums einen Kommentar, der die Besorgnis über Teemissbrauch weiter untermauert:

Bevor ich zu meinen abschließenden Gedanken komme, möchte ich Sébastien Lorber aufrichtig für seine vorsichtige Betreuer-Denkweise und dafür danken, dass er dabei geholfen hat, diese Threads eines möglichen Angriffs auf die NPM-Lieferkette aufzudecken.

Was ist mit string-width-cjs los?

An diesem Punkt bin ich sehr zuversichtlich, dass ich weiterhin Löcher in die übrigen Pakete bohren kann, die angeblich von string-width-cjs abhängig sind, um sehr zweifelhafte Indikatoren für authentische Legitimität zu finden.

Ich gehe davon aus, dass all diese abhängigen Pakete und Download-Boosts nur dem Zweck dienen, eine falsche Legitimität für die 3 *-cjs-Pakete zu schaffen, sodass diese gefälschten Pakete zu gegebener Zeit, wenn das richtige Opfer im Spiel ist, dies tun werden installiert werden und dann eine neue bösartige Version folgen.

Damit Sie bei der Arbeit mit Open-Source-Software sicher bleiben, empfehle ich dringend die Einführung von Sicherheitspraktiken und insbesondere diese weiterführenden Bildungsressourcen:

• Warum NPM-Sperrdateien eine Sicherheitslücke für das Einschleusen bösartiger Module darstellen können
• Best Practices für die Sicherheit von 10 NPM
• NPM-Sicherheit: Angriffe auf die Lieferkette verhindern

Haben wir inmitten ihres Foulspiels eine Kampagne zur Sicherheit der Lieferkette erwischt, oder geht es hier nur um die Spur des Geldes und kann daher auf Spam und den Missbrauch öffentlicher Register wie npm und GitHub zum Mining von Tea-Tokens zurückgeführt werden?

Wie auch immer sich die Dinge entwickeln, bleiben Sie wachsam.