Lieferkettenangriffe treffen npm schwer: Das Wartungskonto von axios wurde gehackt, alle 300 Millionen Downloads pro Woche befinden sich in akuter Notlage

Das Security-Research-Unternehmen Socket hat am 31. März einen aktiven Supply-Chain-Angriff auf das npm-Kernpaket axios festgestellt. Der Angreifer drang in das npm-Konto des leitenden Maintainers von axios, jasonsaayman, ein, veröffentlichte bösartige Versionen und injizierte bösartige Abhängigkeitspakete, um plattformübergreifende Remote-Access-Trojaner (RATs) auszurollen. Zielsysteme sind macOS-, Windows- und Linux-Systeme.

Angriffskettenanalyse: Der vollständige Ablauf von der Kontenübernahme bis zum RAT-Selbstzerstörungsmechanismus

(Quelle: Socket)

Dieser Vorfall war ein sorgfältig geplanter, mehrstufiger Supply-Chain-Angriff. Der Angreifer übernahm zunächst das Wartungskonto des Maintainers und änderte die E-Mail-Adresse in ifstap@proton.me, danach veröffentlichte er manuell bösartige Versionen unter Verwendung der gestohlenen npm-Zugriffsberechtigungen und umging dabei vollständig den regulären axios-Veröffentlichungsprozess über GitHub Actions + OIDC Trusted Publisher. In beiden bösartigen Versionen gibt es in dem GitHub-Repository keine entsprechenden Commits, Tags oder Veröffentlichungsaufzeichnungen.

Auch die Vorbereitung des Angreifers war präzise: Er kontrollierte ein weiteres Konto (nrwise, nrwise@proton.me), das etwa 18 Stunden zuvor zuerst eine saubere Köderversion plain-crypto-js@4.2.0 veröffentlichte, um eine Historie aufzubauen, und veröffentlichte dann am 30. März um 23:59 UTC die bösartige Version 4.2.1.

Nach der Ausführung des bösartigen postinstall-Hooks verbindet sich der RAT-Downloader (setup.js) mit dem Command-and-Control-Server sfrclak[.]com:8000, um plattformspezifische Nutzdaten auszurollen. Nach Abschluss der Ausführung zerstört er sich selbst und ersetzt package.json durch einen sauberen Stub, sodass bei nachträglichen Prüfungen im Verzeichnis node_modules keine Infektionsspuren gefunden werden können.

Wichtige technische Indikatoren des Angriffs (IOC)

Bösartige Paketversionen: axios@1.14.1, axios@0.30.4, plain-crypto-js@4.2.1

C2-Server: sfrclak[.]com / 142.11.206.73 / [.]com:8000

Infektionsspuren unter macOS: /Library/Caches/com.apple.act.mond

Infektionsspuren unter Windows: %PROGRAMDATA%\wt.exe, %TEMP%\6202033.vbs

Infektionsspuren unter Linux: /tmp/ld.py

Angreiferkonto: jasonsaayman (übernommen), nrwise (vom Angreifer erstelltes Konto)

Sofortmaßnahmen-Leitfaden: Betroffenheit prüfen und Schritte zur Behebung

Da sich der bösartige Downloader nach der Ausführung selbst zerstört, lässt sich eine Infektion nicht durch das Prüfen des node_modules-Verzeichnisses bestätigen. Der richtige Weg ist, direkt zu prüfen, ob das Lockfile (package-lock.json oder yarn.lock) Versionsaufzeichnungen für axios@1.14.1 oder axios@0.30.4 enthält.

Sicherheits-Regression: Für 1.x-Nutzer ein Downgrade auf axios@1.14.0; für 0.x-Nutzer ein Downgrade auf axios@0.30.3 und parallel nach dem Entfernen des plain-crypto-js-Verzeichnisses aus node_modules die Abhängigkeiten erneut installieren.

Wenn im System irgendeine RAT-Infektionsspur gefunden wird (com.apple.act.mond, wt.exe, ld.py), versuchen Sie nicht, diese vor Ort zu bereinigen. Stellen Sie stattdessen das System ausgehend von einem bekannten normalen Zustand neu her und rotieren Sie umgehend alle möglicherweise kompromittierten Berechtigungsnachweise, einschließlich npm-Tokens, AWS-Zugriffsschlüssel, SSH-Private-Keys, CI/CD-Konfigurationsschlüssel und die Werte in .env-Dateien.

Für Entwickler von Kryptowährungen und Web3 ist axios eine zentrale HTTP-Bibliothek für viele DeFi-Protokoll-Frontends, Krypto-Asset-Management-Tools und On-Chain-Daten-Abfragedienste. Ein kompromittiertes Entwicklungsumfeld kann dazu führen, dass Wallet-Private-Keys, Mnemonics oder API-Schlüssel an den Angreifer gelangen. Es wird empfohlen, alle sensiblen Berechtigungsnachweise vorrangig zu überprüfen und zu rotieren.

Häufige Fragen

Wie kann ich bestätigen, ob eine betroffene axios-Version installiert ist?

Da sich der bösartige Downloader nach der Ausführung selbst zerstört, kann die Infektion nicht über das node_modules-Verzeichnis bestätigt werden. Prüfen Sie direkt, ob das Lockfile Aufzeichnungen für axios@1.14.1 oder axios@0.30.4 enthält, und ob im node_modules-Verzeichnis ein plain-crypto-js-Verzeichnis vorhanden ist. Sie können npm list axios ausführen oder direkt nach den Versionszeichenfolgen im Lockfile suchen.

Welche besondere Auswirkung hat dieser Supply-Chain-Angriff auf Krypto- und Web3-Entwickler?

axios ist eine gängige HTTP-Bibliothek für Web3-Frontend-Anwendungen und die Schnittstellen von DeFi-Protokollen. Ein kompromittiertes Entwicklungsumfeld kann dazu führen, dass private Schlüssel, Mnemonics, Exchange-API-Schlüssel oder CI/CD-Konfigurationsdaten sowie andere sensible Berechtigungsnachweise offengelegt werden. Betroffene Entwickler sollten daher vorrangig alle potenziell exponierten krypto-bezogenen Berechtigungsnachweise überprüfen und rotieren.

Wie kann man sich gegen zukünftige npm-Supply-Chain-Angriffe schützen?

Die wichtigsten Präventionsmaßnahmen sind: In CI/CD stets npm ci --ignore-scripts verwenden, um postinstall-Hooks zu deaktivieren; Versionen für wichtige Abhängigkeitspakete fest fixieren; regelmäßig die Änderungsaufzeichnungen des Lockfiles überprüfen; sowie Tools wie Socket und Aikido einsetzen, um Abhängigkeitspakete fortlaufend auf bösartige Software in Echtzeit zu überwachen.