npm-Lieferkettenangriffswelle: Was ist passiert? Wie kann man das Risiko mindern?

Original Article Title: "Supply Chain Attack Goes Viral Overnight: What Happened? How to Mitigate Risk?"

Original Article Author: Azuma, Odaily Planet Daily

Am 9. September, Ost-8-Zeitzone, veröffentlichte Charles Guillemet, Chief Technology Officer von Ledger, eine Warnung auf X und erklärte: "Ein groß angelegter Supply-Chain-Angriff ist derzeit im Gange, wobei das NPM-Konto eines bekannten Entwicklers kompromittiert wurde. Das betroffene Softwarepaket wurde über 1.1 billions Mal heruntergeladen, was darauf hindeutet, dass das gesamte JavaScript-Ökosystem gefährdet sein könnte."

Guillemet erklärte weiter: "Der bösartige Code funktioniert, indem er im Hintergrund Kryptowährungsadressen stillschweigend ändert, um Gelder zu stehlen. Wenn Sie eine Hardware-Wallet verwenden, überprüfen Sie jede Signaturtransaktion sorgfältig, dann sind Sie sicher. Wenn Sie keine Hardware-Wallet verwenden, vermeiden Sie bitte vorübergehend alle On-Chain-Transaktionen. Es ist derzeit unklar, ob der Angreifer bereits die mnemonische Phrase von Software-Wallets gestohlen hat."

Was ist passiert?

Laut dem von Guillemet zitierten Sicherheitsbericht war die unmittelbare Ursache dieses Vorfalls: Das NPM-Konto des bekannten Entwicklers @qix wurde kompromittiert, was zur Veröffentlichung bösartiger Versionen von Dutzenden von Softwarepaketen führte, darunter chalk, strip-ansi und color-convert. Der bösartige Code könnte sich auf Endnutzer ausgebreitet haben, wenn Entwickler oder Nutzer automatisch Abhängigkeiten installiert haben.

Odaily Note: Wöchentliche Downloadzahlen der kompromittierten Softwarepakete.

Kurz gesagt, dies ist ein klassischer Fall eines Supply-Chain-Angriffs – wobei ein Angreifer bösartigen Code (wie ein NPM-Paket) in ein Entwicklungstool oder ein Abhängigkeitssystem einpflanzt, um bösartige Aktivitäten durchzuführen. NPM, kurz für Node Package Manager, ist das am weitesten verbreitete Paketverwaltungstool im JavaScript/Node.js-Ökosystem. Zu den Hauptfunktionen gehören Abhängigkeitsmanagement, Paketinstallation und -aktualisierung, Code-Sharing und mehr.

Aufgrund des enormen Umfangs des NPM-Ökosystems, das derzeit aus Millionen von Softwarepaketen besteht, verlassen sich nahezu alle Web3-Projekte, Krypto-Wallets und Frontend-Tools auf NPM—genau deshalb machen die umfangreichen Abhängigkeiten und die komplexe Kette von Verknüpfungen NPM zu einem Hochrisiko-Einstiegspunkt für Supply-Chain-Angriffe. Durch das Einpflanzen von bösartigem Code in ein häufig verwendetes Softwarepaket können Angreifer potenziell Tausende von Anwendungen und Nutzern beeinflussen.

Wie im obigen Flussdiagramm zur Verbreitung des bösartigen Codes dargestellt:

· Ein bestimmtes Projekt (blaues Feld) hängt direkt von einigen gängigen Open-Source-Bibliotheken ab, wie z. B. express.

· Diese direkten Abhängigkeiten (grüne Felder) hängen dann von anderen indirekten Abhängigkeiten ab (gelbe Felder, wie lodash).

· Wenn eine indirekte Abhängigkeit heimlich von einem Angreifer mit bösartigem Code infiziert wird (rotes Feld), wird dieser entlang der Abhängigkeitskette in das Projekt übertragen.

Was bedeutet das für Kryptowährungen?

Die direkte Relevanz dieses Sicherheitsvorfalls für die Kryptowährungsbranche besteht darin, dass der vom Hacker in das oben genannte kompromittierte Softwarepaket eingepflanzte bösartige Code ein ausgeklügelter "Kryptowährungs-Clipboard-Hijacker" ist, der Krypto-Vermögenswerte stiehlt, indem er Wallet-Adressen ersetzt und Transaktionen kapert.

Stress Capital Gründer GE (@GuarEmperor) erläuterte dies auf X und erklärte, dass die "Clipboard-Hijacker"-Injektion des Hackers zwei Angriffsmodi verwendet—passiv durch Verwendung des Levenshtein-Distanz-Algorithmus zum Ersetzen von Wallet-Adressen, die visuell ähnlich sind und daher extrem schwer zu erkennen sind; aktiv durch Manipulation der Zieladresse in der im Browser erkannten Krypto-Wallet, bevor der Nutzer die Transaktion signiert.

Da dieser Angriff auf die grundlegenden Bibliotheken von JavaScript-Projekten abzielte, könnten sogar Projekte, die indirekt von diesen Bibliotheken abhängen, betroffen sein.

Wie profitiert der Hacker?

Der vom Hacker eingepflanzte bösartige Code gab auch deren Angriffsadressen preis. Die primäre Angriffsadresse des Hackers auf Ethereum ist 0xFc4a4858bafef54D1b1d7697bfb5c52F4c166976, wobei die Gelder hauptsächlich von den folgenden drei Adressen stammen:

· 0xa29eEfB3f21Dc8FA8bce065Db4f4354AA683c0240

· x40C351B989113646bc4e9Dfe66AE66D24fE6Da7B

· 0x30F895a2C66030795131FB66CBaD6a1f91461731

Das Arkham-Team hat eine Tracking-Seite für dieses Angriffsevent erstellt, auf der Sie Echtzeitinformationen über die Gewinne und Transfers des Hackers abfragen können.

Zum Zeitpunkt des Schreibens hat der Hackerangriff nur 496 $ eingebracht, aber angesichts der noch nicht festgestellten Verbreitung des bösartigen Codes ist zu erwarten, dass diese Zahl weiter steigen könnte—der Entwickler wurde benachrichtigt und arbeitet aktiv mit dem NPM-Sicherheitsteam zusammen, um das Problem zu beheben. Der bösartige Code wurde aus den meisten betroffenen Paketen entfernt, sodass die Situation unter Kontrolle ist.

Wie kann das Risiko gemindert werden?

Defillama-Gründer @0xngmi erklärte auf X, dass dieses Ereignis zwar gefährlich klingen mag, die tatsächlichen Auswirkungen jedoch nicht so weitreichend sind—da dieses Ereignis nur Websites betrifft, die seit der Veröffentlichung des kompromittierten NPM-Softwarepakets Updates durchgeführt haben, während andere Projekte weiterhin die alte Version verwenden; und die meisten Projekte ihre Abhängigkeiten festlegen, sodass sie auch bei Updates weiterhin den alten sicheren Code verwenden.

Da Endnutzer jedoch nicht wirklich wissen können, ob ein Projekt Abhängigkeiten festgelegt hat oder ob sie einige dynamisch heruntergeladene Abhängigkeiten haben, ist es derzeit unerlässlich, dass das Projekt zur Selbstinspektion und Offenlegung hervorgeht.

Zum Zeitpunkt des Schreibens haben mehrere Wallet- oder App-Projekte, darunter MetaMask, Phantom, Aave, Fluid, Jupiter, alle offengelegt, dass sie von diesem Ereignis nicht betroffen sind. Daher können Nutzer theoretisch Wallets, die als sicher bestätigt wurden, bedenkenlos verwenden, um sicher auf Protokolle zuzugreifen, die ebenfalls als sicher bestätigt wurden. Für Wallets oder Projekte, die noch keine Sicherheits-Offenlegung durchlaufen haben, ist es jedoch möglicherweise sicherer, deren Nutzung vorübergehend zu vermeiden.