Axios bajo fuego: Así se gestó el ataque a la cadena de suministro en npm

Startseite » Python » Axios bajo fuego: Así se gestó el ataque a la cadena de suministro en npm

Für einige angespannte Stunden war eine der weltweit am häufigsten verwendeten JavaScript-Bibliotheken, Axios vorliegtwurde unerwartet zu einem Verbreitungsmedium für Schadsoftware. Lieferkettenangriff auf das npm-Ökosystem hat ein routinemäßiges Abhängigkeitsupdate in eine potenzielle Hintertür für Angreifer auf Hunderttausenden von Entwicklerrechnern und Build-Systemen verwandelt.

Ermittler mehrerer Sicherheitsfirmen und der Threat Intelligence Group von Google konnten rekonstruieren, wie ein Angreifer einen Sicherheitslücken-Datenspeicher einschleusen konnte. Remote-Access-Trojaner (RAT) in bestimmte Axios-Releases auf npm, ähnlich wie die npm-Lieferkettenwurm.

Was Axios ist und warum der Kompromiss so wichtig ist

Im Kern ist Axios ein Promise-basierter HTTP-Client für Node.js und BrowserEs arbeitet im Hintergrund unzähliger Projekte und erledigt alltägliche Aufgaben wie „Meine Nachrichten vom Server abrufen“ oder „Dieses Formular an die API senden“, ohne dass Entwickler manuell Low-Level-Netzwerkcode schreiben müssen.

Da Axios sowohl im Browser als auch auf Node.js-Servern läuft, hat es sich zu einem grundlegende Abhängigkeit in modernen JavaScript-StacksSie haben es vielleicht nie explizit installiert, nutzen es aber dennoch indirekt, wenn Sie:

• Nutzen Sie Webanwendungen, die mit Frameworks wie React, Vue oder Angular erstellt wurden und ihre API-Aufrufe mit Axios umschließen.
• Führen Sie Desktop- oder mobile Anwendungen aus, die auf Technologien wie Electron, React Native und ähnlichen webbasierten Laufzeitumgebungen basieren.
• Interagieren Sie mit kleineren SaaS-Tools, Admin-Dashboards oder selbstgehosteten Diensten, deren Entwickler Axios für HTTP-Anfragen gewählt haben.

In diesem Sinne ist Axios ein bisschen wie das Sanitärinstallationen in Ihrem HausMan denkt selten darüber nach, aber es transportiert die Daten wie „Wasser“ zwischen der eigenen App und der Außenwelt. Man bemerkt es erst, wenn es zu einem Datenleck kommt – genau das, was dieser Angriff verursacht hat, nur eben im Ausmaß eines ganzen Software-Ökosystems.

Wie der Axios-npm-Angriff ablief

Der Vorfall steht im Zusammenhang mit zwei npm-Releases: axios@1.14.1 , axios@0.30.4Mithilfe kompromittierter Zugangsdaten eines der Hauptentwickler des Projekts gelang es Angreifern, … zu veröffentlichen. bösartige Builds direkt auf npm wobei der öffentliche GitHub-Quellcode unberührt bleibt, ein Muster, das auch in der Shai-Hulud-Analyse.

Anstatt den Code von Axios sichtbar zu verändern, fügte der Angreifer eine neue, scheinbar unabhängige Abhängigkeit hinzu: plain-crypto-js@4.2.1Dieses Paket wurde speziell für den Einsatz entwickelt und wurde nirgendwo in den Quelldateien von Axios importiertEin Warnsignal für jeden, der die Unterschiede genau prüft – aber leicht zu übersehen in automatisierten Arbeitsabläufen, die einfach der Registry vertrauen.

Zusammen hatten die beiden fehlerhaften Axios-Versionen ein enormes Verbreitungspotenzial, das bis zu … reichte. wöchentlich rund 100 Millionen Downloads auf npmEs wird geschätzt, dass Axios in nahezu 80 % der Cloud-Umgebungen und CI/CD-Pipelines vorhanden ist, sodass selbst ein kurzes Expositionsfenster ein ernsthaftes systemisches Risiko darstellte.

Entscheidend ist, dass die betroffenen Versionen nie in der offizielle GitHub-Tags für das Axios-Projekt. Dieses Detail deutet stark darauf hin, dass die normalen Veröffentlichungsprozesse umgangen wurden: Der Angreifer nutzte ein gestohlenes npm-Token, um Pakete direkt in die Registry zu übertragen, außerhalb des öffentlichen Quellcodeverlaufs.

Die Mechanismen der bösartigen Abhängigkeit und des RAT

Der Kern des Kompromisses liegt in dem, was während der Installation geschah. Jeder Workflow, der ausgeführt wurde npm install und zog axios@1.14.1, axios@0.30.4 or plain-crypto-js@4.2.1 Bei aktivierten Skripten wurde eine versteckte Nachinstallationsroutine ausgelöst.

Innerhalb der bösartigen Abhängigkeit, ein postinstall script (node ​​setup.js) Das Skript wurde automatisch ausgeführt. Es lud einen verschleierten Dropper herunter, der anschließend eine plattformspezifische RAT-Payload abrief, die auf die jeweilige Plattform zugeschnitten war. macOS, Windows oder LinuxDie RAT ermöglichte dem Angreifer interaktiven Fernzugriff auf den kompromittierten Rechner.

Sobald dieser Remote-Access-Trojaner aktiv ist, kann er das System durchsuchen, Geheimnisse abgreifen und beliebige Befehle ausführen. Cloud-API-Schlüssel, CI-Bereitstellungstoken, npm-Authentifizierungstoken, SSH-Schlüssel, Repository-Zugriffstoken und andere sensible Umgebungsvariablen werden üblicherweise in Build-Agenten oder Entwickler-Laptops eingespielt.

Von dort aus könnten Angreifer weitere Schritte unternehmen: Quellcode einsehen, zukünftige Versionen manipulieren, zusätzliche Hintertüren einbauen oder sich seitlich in die Produktionsinfrastruktur ausbreiten. Für Entwickler, die an Krypto-Projekten arbeiten – Wallets, Börsen, DeFi-Frontends – könnte diese Art von Zugriff direkt zu … führen. Kryptowährungsdiebstahl oder umfassenderer Finanzbetrug.

Heimliche Taktiken: Warum der Kompromiss so schwer zu erkennen war

Die Malware-Autoren unternahmen große Anstrengungen, ihre Spuren so gering und flüchtig wie möglich zu halten. Laut Forschern ist der Dropper beseitigte seine Spuren unmittelbar nach der Ausführung.

Das bedeutet, wenn Sie untersucht haben node_modules/plain-crypto-js/package.json nachdem Bei einer Infektion würde man ein völlig harmloses Manifest sehen: kein Postinstall-Skript, keine setup.jsEs gibt keine offensichtlichen Anzeichen für ein Verbrechen. Standardwerkzeuge wie npm audit Oder eine oberflächliche manuelle Verzeichnisprüfung würde nicht aufdecken, was bereits geschehen ist.

In der Praxis führte dieses Verhalten dazu, dass die Ermittler auf externe Quellen angewiesen waren. Kompromissindikatoren (IOCs)Netzwerktelemetrie und Host-Artefakte wurden anstelle einfacher statischer Scans des npm-Paketinhalts analysiert. Als der Angriff öffentlich wurde, waren die schädlichen Versionen bereits von npm entfernt worden, was die Rekonstruktion des genauen Ausführungsablaufs zusätzlich erschwerte.

Wichtige Indikatoren für eine Kompromittierung im Axios-Vorfall

Obwohl die Schadsoftware versuchte, ihre Spuren zu verwischen, haben Sicherheitsteams konkrete Indikatoren für eine Kompromittierung (IOCs) gemeldet, die helfen können, festzustellen, ob eine Umgebung betroffen ist. Zu den wichtigsten gehören die folgenden:

Auf dem Netzwerkseite, suchen Sie nach Kommunikationsmöglichkeiten mit:

• المجال: sfrclakcom
• IP Adresse: 142.11.206.73

Beide Indikatoren wurden von den gängigen Sicherheitsanbietern blockiert, bleiben aber nützliche Markierungen in historischen Protokollen und SIEM-Suchen.

Auf dem DateisystemDie Ermittler hoben Artefakte hervor, die mit dem RAT in Verbindung stehen:

• macOS: /Library/Caches/com.apple.act.mond
• Linux: /tmp/ld.py
• Windows: Dateien unter %PROGRAMDATA%\wt und temporäre Skripte wie %TEMP%\6202033.vbs or .ps1 die möglicherweise nur kurzzeitig während der Ausführung existieren

Im Hinblick auf npm-Pakete, Kompromittierte Builds und ihre bekannten Prüfsummen sind:

• axios@1.14.1, SHA-256: 2553649f2322049666871cea80a5d0d6adc700ca
• axios@0.30.4, SHA-256: d6f3f62fd3b9f5432f5782b62d8cfd5247d5ee71
• plain-crypto-js@4.2.1, SHA-256: 07d889e2dadce6f3910dcbc253317d28ca61c766

Sicherheitsfirmen wie Huntress beobachteten mindestens 135 Systeme kontaktieren den Command-and-Control-Server des Angreifers. Während des relativ kurzen Zeitraums der Offenlegung warnten Forscher von Google davor, dass dadurch letztendlich „Hunderttausende“ von Geheimnissen abgegriffen worden sein könnten.

Wer steckte hinter dem Anschlag? Die Urheberschaft und die Verbindung zu Nordkorea

Googles Threat Intelligence Group hat den Axios-Kompromittierungsfall öffentlich mit einem mutmaßlicher nordkoreanischer Bedrohungsakteur Die Verbindung wurde unter der Kennung UNC1069 erfasst. John Hultquist, Chefanalyst der Bedrohungsabteilung von Google, merkte an, dass nordkoreanische Akteure eine lange Erfolgsgeschichte vorweisen können. Lieferkettenangriffe mit dem Ziel, Kryptowährung zu stehlen und andere Vermögenswerte.

Laut Google und anderen Sicherheitsanbietern scheint der Axios-Vorfall Teil einer umfassenderen Kampagne nordkoreanischer Gruppen zu sein, darunter Organisationen wie Lazarus, die sich auf … konzentrieren. Erpressung, Finanzdiebstahl und Datenexfiltration mit Fokus auf Sektoren wie Krypto, Fintech und Cloud-Infrastruktur.

Auch wenn die vollen Auswirkungen noch unklar sind, lässt die Kombination aus einem äußerst beliebten Softwarepaket, dem Zugriff auf Entwicklerumgebungen und der Art der gestohlenen Daten Analysten zu folgenden Erwartungen führen: Folgeangriffe in Form weiterer Lieferkettenkompromittierungen, Ransomware und direktem Kryptodiebstahl.

Wie das Maintainer-Konto und der npm-Workflow missbraucht wurden

Einer der beunruhigendsten Aspekte für die Open-Source-Community ist, wie es den Angreifern gelang, manipulierte Axios-Versionen zu veröffentlichen, ohne den öffentlichen Quellcode zu verändern. Der Schlüssel dazu war ein Kompromittiertes Maintainer-Konto auf npm, das vermutlich einem Hauptbetreuer von Axios namens jasonsaayman gehört.

Angreifer sollen die mit dem npm-Konto verknüpfte E-Mail-Adresse in eine von ihnen kontrollierte Adresse geändert haben. Dadurch könnten sie Sperre den rechtmäßigen Wartungsbenutzer aus und neue Paketversionen so zu veröffentlichen, als wären es echte Updates, während das offizielle GitHub-Repository sauber blieb.

Die Operation brachte auch ein strukturelles Problem in npm ans Licht: die Unterstützung für Legacy-Authentifizierungstoken, und die Notwendigkeit für Tools für das Lieferkettenmanagement und strengere Token-Richtlinien.

In diesem Fall wiesen Sicherheitsforscher darauf hin, dass npm immer noch wurde standardmäßig das Legacy-Token verwendet. Für die Veröffentlichung wurde das Token nicht automatisch widerrufen, sobald modernere Veröffentlichungsmethoden konfiguriert wurden. Diese Koexistenz schuf eine Sicherheitslücke, die UNC1069 ausnutzen konnte.

Expositionsfenster und Früherkennung

Der Axios-Kompromittierungsfall war kein schleichender Prozess. Untersuchungen deuten darauf hin, dass die manipulierten Versionen Für etwa drei Stunden auf npm verfügbar. zwischen Sonntagabend und Montag- oder Dienstagmorgen, je nach Zeitzone.

StepSecurity und andere Firmen stellten fest, dass der Angreifer das Ökosystem mit einem Eine saubere Version der schädlichen Abhängigkeit wurde etwa 18 Stunden zuvor erstellt. Die Anbindung der bewaffneten Variante an Axios. Dieser Schritt scheint darauf abzuzielen, eine unauffällige Historie für das Paket zu schaffen und zu vermeiden, dass automatische Anomalieerkennungen auslösen, wenn die Abhängigkeit plötzlich auftritt.

Nachdem die infizierten Axios-Versionen veröffentlicht worden waren, führte der Trojaner auf jedem System, auf dem er ausgeführt wurde, umfangreiche Aufklärungsmaßnahmen durch: Verzeichnisse scannen, laufende Prozesse auflisten, Datenträger aufzählen Anschließend wurden diese Informationen an den Server des Angreifers zurückgesendet. All dies geschah im Hintergrund während einer für die Entwickler wie eine routinemäßige Installation von Abhängigkeiten aussehenden Prozedur.

Dank der koordinierten Reaktion des Entwicklers, von npm und mehrerer Sicherheitsanbieter wurden die schädlichen Versionen innerhalb weniger Stunden entfernt. Dennoch betonten mehrere Forscher und Googles eigenes Team, Ein kurzes Expositionsfenster ist nicht gleichbedeutend mit einem geringen Risiko. wenn es sich bei dem Ziel um eine Bibliothek mit zig Millionen wöchentlichen Downloads handelt.

Auswirkungen auf Entwickler, Kryptoprojekte und Endnutzer

Aus praktischer Sicht sind die unmittelbarsten Opfer des Axios-Vorfalls folgende: Entwickler und Build-Umgebungen Dadurch wurden die schädlichen Versionen installiert. Jeder, der eine Installation oder einen Build ausgeführt hat, der axios@1.14.1, axios@0.30.4 oder plain-crypto-js@4.2.1 mit aktivierten Skripten mitinstalliert hat, muss davon ausgehen, dass das System vollständig kompromittiert sein könnte.

Für Projekte im Kryptowährungsbereich – Wallets, zentralisierte und dezentralisierte Börsen, DeFi-Dashboards, Trading-Bots und Web3-Frontends – steht besonders viel auf dem Spiel. Viele dieser Systeme Sie sind auf Axios angewiesen, um mit Blockchain-Gateways, APIs und Backend-Diensten zu kommunizieren.und sie verwalten häufig sensible Geheimnisse wie private Schlüssel, API-Zugangsdaten und Benutzerdaten.

Wenn eine Entwickler-Workstation oder ein CI-Agent in einem solchen Projekt infiziert wurde, hätten Angreifer nicht nur die lokal gespeicherten Geheimnisse erlangen können, sondern auch Zugriff auf Repositories und Deployment-PipelinesDamit könnten sie bösartigen Code in zukünftige Versionen einschleusen, Endbenutzer indirekt gefährden oder Gelder umleiten.

Im Gegensatz dazu sind Nutzer, die fertige Anwendungen einfach in ihrem Browser ausführen, im Vorteil: Die RAT wurde während Installations- und MontageschritteDer Angriff findet nicht zur Laufzeit im Browser statt. Daher löst der Besuch einer Website, die Axios für clientseitige Aufrufe verwendet, den Angriff nicht automatisch aus. Das Risiko betrifft vor allem diejenigen, die die betroffenen npm-Pakete installiert haben.

Sofortmaßnahmen, die Entwickler ergreifen sollten

Sicherheitsteams und Wartungsfirmen haben eindeutig klargestellt: Falls die Möglichkeit besteht, dass Ihre Systeme die kompromittierten Axios- oder plain-crypto-js-Versionen installiert haben, behandeln Sie diese Hosts als Bis zur Untersuchung ist sie völlig unzuverlässig.Das bedeutet mehr als nur eine Erhöhung der Versionsnummer.

Zu den von Forschern und Anbietern empfohlenen konkreten Maßnahmen gehören:

• Überprüfen Sie Ihre Abhängigkeiten und Sperrdateien: Suchen Sie nach axios@1.14.1, axios@0.30.4 , plain-crypto-js@4.2.1 in package-lock.json, pnpm-lock.yaml, yarn.lock und CI-Protokolle; siehe wie man sie sicher repariert.
• Aktualisieren Sie auf verifizierte, sichere Versionen: Wechseln Sie zu sauberen Axios-Releases (zum Beispiel den unmittelbar darauf folgenden, von den Maintainern empfohlenen Patch-Tags) und stellen Sie sicher, dass Ihre Sperrdateien neu generiert werden.
• Zugangsdaten konsequent wechseln: Gehen Sie davon aus, dass alle auf betroffenen Maschinen oder Pipelines vorhandenen Geheimnisse – Cloud-API-Schlüssel, npm-Token, SSH-Schlüssel, Bereitstellungsschlüssel, .env-Variablen – gestohlen worden sein könnten, und rotieren Sie diese.
• Kompromittierte Systeme wiederherstellen: Wo immer möglich, sollten Build-Agents, CI-Runner und Entwickler-Workstations aus vertrauenswürdigen Images neu bereitgestellt werden, anstatt sie direkt vor Ort zu bereinigen.
• Block-C2-Infrastruktur: Speichern sfrclak.com , 142.11.206.73 zu Firewalls, DNS-Sperrlisten und EDR-Regeln.
• Auf der Suche nach Artefakten: Überprüfen Sie die Dateisystempfade und temporären Dateien, die mit der RAT auf macOS-, Windows- und Linux-Hosts verknüpft sind.

Mehrere Sicherheitsunternehmen haben Organisationen, die die manipulierten Versionen installiert haben, dazu geraten, Standardmäßig von einem Kompromiss ausgehenMit anderen Worten: Gehen Sie davon aus, dass die Angreifer Zugriff hatten, und arbeiten Sie die Schritte zur Reaktion auf den Vorfall systematisch durch, anstatt darauf zu hoffen, dass die Schadsoftware nichts angerichtet hat.

Weitergehende Lehren für die Sicherheit der Software-Lieferkette

Über die unmittelbare Krisenbewältigung hinaus hat der Axios-Vorfall die Debatten darüber neu entfacht, wie das gesamte Ökosystem mit Vertrauen, Identität und Verbreitung in Open-Source-Projekten umgeht. Er verdeutlicht, wie … Einzelbibliotheks-Administratorkonto kann zu einem Dreh- und Angelpunkt für die Sicherheitslage unzähliger Organisationen werden.

Aus den Nachbetrachtungen und Lieferantenanalysen haben sich mehrere Themen herauskristallisiert:

• Legacy-Token stellen eine Belastung dar: Alte npm-Tokens können neben neueren, OIDC-basierten Workflows unbemerkt fortbestehen. Projekte benötigen explizite Richtlinien, um diese Tokens zu widerrufen, sobald sicherere Methoden implementiert sind.
• Automatisierte Updates haben zwei Seiten: Automatische Abhängigkeitsaktualisierungen beschleunigen zwar die Entwicklung, bedeuten aber auch, dass sich eine bösartige Version in Ökosystemen verbreiten kann, bevor es jemand bemerkt.
• Abhängigkeitsprüfung ist notwendig, aber nicht hinreichend: Statische Prüfungen und npm audit sind nützlich, haben aber dennoch Schwierigkeiten gegen ephemeres Verhalten wie selbstlöschende Postinstallationsskripte.
• Die Sicherheit der Wartungsanlagen ist eine kritische Infrastruktur: Eine starke Multi-Faktor-Authentifizierung, Hardware-Sicherheitsschlüssel, der sorgfältige Umgang mit Zugriffstoken und die regelmäßige Überprüfung der Veröffentlichungsberechtigungen sind heute genauso wichtig wie das Schreiben von gutem Code.

Für Gründer, CTOs und technische Führungskräfte ist der Axios-Kompromiss eine Erinnerung daran, dass Lieferkettenrisiken sind ein strategisches ThemaEs geht nicht nur um technische Aspekte. Es beeinflusst auch, wie schnell Sie Produkte ausliefern können, wie Sie Ihre CI/CD-Pipelines gestalten und wie Sie die Vorteile von Open Source mit der Notwendigkeit, die in der Produktion ausgeführten Anwendungen zu überprüfen, in Einklang bringen.

Zusammengenommen zeigt die Kompromittierung von Axios auf npm, wie ein kurzlebiger, aber gut geplanter Angriff einen vertrauenswürdigen Baustein des JavaScript-Ökosystems in ein unauffälliges Einfallstor für Schadsoftware mit Fernzugriff verwandeln kann. Da Angreifer sowohl Entwickler und Vertriebskanäle als auch Endnutzer ins Visier nehmen, hängt die Stabilität der Software-Lieferketten nun von strengeren Kontrollen der Veröffentlichungsprozesse, einer konsequenten Überwachung auf Anomalien und der Bereitschaft ab, Abhängigkeiten mit der gleichen Skepsis zu begegnen, die einst nur dem externen Netzwerkverkehr galt.

Verwandte Artikel:

Ausführlicher Leitfaden zu npm-Sicherheitsprüfungen und Lieferkettenangriffen