Verdächtiger Betreuer enthüllt Themen eines NPM-Supply-Chain-Angriffs

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 NPM-Abhängigkeitsänderungen 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 halber Versionsbereich angezeigt wird. In diesem Fall gibt es jedoch eine spezielle npm:-Präfixsyntax. Was bedeutet das?

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. Dies bedeutet, dass es einen node_modules-Verzeichniseintrag für string-width-cjs gibt, jedoch mit dem Inhalt von string-width@^4.2.0 und ähnlichem Verhalten in der Sperrdatei (package-lock.json).

Paket-Aliasing ist eine NPM-Paketmanagerfunktion und könnte legitimerweise für die hier angedeuteten Fälle verwendet werden (um bei der Unterstützung von ESM vs. CJS zu helfen).

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.

Diese Pull-Anfrage ist in der Tat harmlos und es besteht kein Risiko eines Angriffs auf die Lieferkette. Sébastien war jedoch misstrauisch gegenüber solchen Paketnamen und stellte fest, dass es noch mehr gab, worüber man sich Sorgen machen musste.

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

Als Sébastien den Pull-Request untersuchte, führte er ein Tool namens lockfile-lint aus, das bei der Validierung von Lockfiles wie package-lock.json oder Yarn.lock hilft, um sicherzustellen, dass sie nicht manipuliert wurden, um statt dessen bösartige Pakete einzuschleusen das ursprüngliche npm-Paket.

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 ich die Sicherheitsbedenken bei Lockfiles offengelegt habe: Warum NPM-Lockfiles ein Sicherheits-Blindspot 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 bemerkte, dass diese Paketnamen nicht nur auf npm existieren, sondern auch Indikatoren aufweisen, die Anlass zur Sorge geben:

• Diese Pakete sind nicht an ein öffentliches Quellcode-Repository gebunden
• Wenn diese Pakete auf ihren Inhalt überprüft werden, sind sie frei von jeglichem tatsächlichen Code.
• Die Identität des Autors, der diese Pakete veröffentlicht hat, ist anonym und wird nicht mit persönlichen oder identifizierbaren Informationen in Verbindung gebracht.

Wenn man sich das npm-Paket „strip-ansi-cjs“ ansieht, gibt es keine README-Datei und kein Quellcode-Repository, das dem Paket zugeordnet ist, aber es gibt viele legitime und beliebte Pakete, die das gleiche Verhalten angeben.

Tatsächlich gibt es für dieses spezielle Paket Beliebtheitssignale in Form vieler abhängiger Pakete (andere Pakete, die von diesem abhängig sind) – 529 abhängige Pakete, um genau zu sein, und auch eine wachsende Zahl wöchentlicher Downloads, insgesamt 7.274 zum Zeitpunkt des Schreibens.

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 bekommt ein Paket, das gar nichts macht, so viele Downloads und warum sind so viele andere Pakete davon abhängig?

Lassen Sie uns weiterhin den Autor dieser npm-Pakete untersuchen.

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

• isaacs-cliui npm package - potentially a typosquatting attempt on Isaac’s own fork of the cliui project and the legitimate npm package under their namespace: @isaacs/cliui.
• azure-sdk-for-net npm package - potentially an attempt at dependency confusion campaign to attack private packages of the same name.
• link-deep npm package - squatting on a popular capability related to utility packages such as lodash and others

You can also note that the user himanshutester002 has no identifiable information on this user profile page on npmjs.

We previously noted that the strip-ansi-cjs npm package has over 500 other packages that use it, therefore, potentially a positive indicator for popularity. Let’s look at them:

If you give it a glance, this might transfer some sort of legitimacy with this list, but is it?
For example, names like clazz-transformer or react-native-multiply or maybe gh-monoproject-cli seem legitimate, but are they?

Here is the react-native-multiply npm package page:

This package has virtually no downloads and its author is also an anonymous npm user with no identifiable information. The source URL repository this package redirects to is https://github[.]com/hasandader/react-native-multiply which doesn’t exist and the GitHub user profile looks very suspicious and lacks practical activity.

The npm package contents might seem like there’s some actual source code in there, but in reality, it looks like a generated code sample for a “hello world” application prototype.

You also have to wonder, if this package is just a multiplication library, then why does it need 776 dependencies to do the following:

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

While some may mock JavaScript for its abuse of dependencies, contributing to an astronomical tree of nested packages, it doesn’t make any sense for a project to declare 776 direct (top-level) dependencies.

Among all of these dependencies, are the 3 suspicious npm packages that our story began with: string-width-cjs, strip-ansi-cjs, and wrap-ansi-cjs:

We mentioned that one of the strip-ansi-cjs dependencies was named clazz-transformer. Let’s look at it:

Let’s explain what is happening here:

• The npm package name is clazz-transformer, yet the package has a title of class-transformer at the top of the README’s package page here which was purposely done.
• Similarly, the source code repository is https://github[.]com/typestack/class-transformer which might be a legitimate repository or a fake one, but it is not associating itself at all with the wording “clazz”.

The associated repository’s typstack/class-transformer on GitHub has the package.json file as  follows:

Looking at the package.json file on GitHub shows no declaration of dependencies, yet if we inspect the source code of the actual package on npmjs we see the 437 dependencies that this clazz-transformer is packaged with. Again, very conveniently bundling the 3 suspicious *-cjs packages:

Further thoughts on suspicious npm package findings

Before we draw further conclusions, it is important to mention a few of the traits of the npm packages we observed above:

• Die React Native-Pakete scheinen vom Scaffold-Tool „create-react-native-library“ abgeleitet zu sein, das auch das standardmäßige Multiplikationsfunktionsbeispiel als Teil des für ein neues Projekt generierten Standardquellcodes enthält.
• Pakete verfügen über Verzeichnis- und Dateistrukturen und Abhängigkeiten, die von Next.js 14-Starter-Boilerplate 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?

Zu diesem Zeitpunkt 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
• 10 npm-Best Practices für die Sicherheit
• 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 Geldspur 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 Lage entwickelt, bleiben Sie wachsam.

Das obige ist der detaillierte Inhalt vonVerdächtiger Betreuer enthüllt Themen eines NPM-Supply-Chain-Angriffs. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!