Eine kurzzeitige Kompromittierung des beliebten Axios-npm-Pakets zeigt, wie schnell eine vertrauenswürdige Abhängigkeit zu einer weit verbreiteten Bedrohung werden kann.
Angreifer kaperten ein Maintainer-Konto und veröffentlichten manipulierte Versionen, die während routinemäßiger Paketinstallationen unbemerkt einen Remote-Access-Trojaner (RAT) installierten und damit Entwicklerumgebungen und CI/CD-Pipelines gefährdeten.
„Während traditionelle Risiken wie die manuelle Installation von Abhängigkeiten und unsichere Upgrade-Bots weiterhin von Bedeutung sind, liegt die dringendere, zukunftsorientierte Bedrohung im Hypermaßstab: vollständig autonome Coding-Agenten mit Tool-Ausführung“, sagte Liran Tal, Head of Developer Relations & Community bei Snyk, in einer E-Mail an eSecurityPlanet.
Die Lieferkettenattacke auf Axios
Snyk-Forscher stellten fest, dass der Angriff Axios betraf – eine Bibliothek mit über 100 Millionen Downloads pro Woche. Selbst eine kurzzeitige Gefährdung sorgte damit in Entwicklungs-Pipelines und Produktionsumgebungen für eine erhebliche Reichweite.
Organisationen, die auf automatisierte Builds oder nicht festgelegte Abhängigkeiten setzten, waren besonders gefährdet, da manipulierte Versionen unbemerkt eingebunden werden konnten. Dies verdeutlicht erneut, wie vertrauenswürdige Open-Source-Pakete als Waffe eingesetzt werden können, ohne ihre Kernfunktionalität zu verändern.
So lief der Angriff ab
Ursache war ein kompromittiertes Maintainer-Konto – ein Hinweis auf eine wachsende Klasse von Lieferkettenangriffen, die statt auf den Code auf Identitäten abzielen.
Durch den Missbrauch des Vertrauensmodells von npm konnte der Angreifer direkt manipulierte Versionen im offiziellen Paket veröffentlichen und herkömmliche Schutzmaßnahmen umgehen.
Statt Axios selbst zu verändern, fügte der Angreifer eine bösartige Abhängigkeit (plain-crypto-js) in das Paket ein. Dadurch konnte die Schadlast während der Installation über ein Postinstall-Skript mit minimaler Interaktion des Benutzers ausgeführt werden.
Nach der Aktivierung setzte der Angriff eine mehrstufige Schadlast ein, die mithilfe mehrschichtiger Verschleierungstechniken einer Erkennung entgehen sollte.
Die Schadsoftware lud dynamisch plattformspezifische RATs für macOS-, Windows- und Linux-Systeme nach und ermöglichte so weitreichende plattformübergreifende Auswirkungen.
Nach der Ausführung entfernte sie Spuren ihrer Installation, erschwerte dadurch die forensische Analyse und verringerte die Wahrscheinlichkeit einer Entdeckung in kompromittierten Umgebungen.
Der Angriff konnte während seines kurzen Veröffentlichungszeitraums aktiv ausgenutzt werden. Jedes System, auf dem die betroffenen Versionen installiert wurden, sollte daher als vollständig kompromittiert betrachtet werden.
Angesichts der Fähigkeit des RAT, Befehle auszuführen, Daten zu exfiltrieren und Persistenz einzurichten, verdeutlicht dieser Vorfall, wie schnell eine vertrauenswürdige Abhängigkeit zu einem Angriffskanal mit weitreichenden Auswirkungen werden kann, wenn Kontrollen der Software-Lieferkette schwach sind oder fehlen.
So lässt sich das Lieferkettenrisiko eindämmen
Angriffe auf die Software-Lieferkette werden immer zielgerichteter und schwerer zu erkennen, insbesondere wenn sie von vertrauenswürdigen Abhängigkeiten ausgehen.
Herkömmliche Sicherheitskontrollen übersehen häufig bösartiges Verhalten, das während des Build-Prozesses oder der Paketinstallation eingeschleust wird.
Um das Risiko zu verringern, benötigen Organisationen stärkere Kontrollen für das Abhängigkeitsmanagement, Build-Umgebungen und die Überwachung zur Laufzeit.
- Lockfiles prüfen und Abhängigkeiten festschreiben , um nicht autorisierte oder bösartige Paketaktualisierungen zu verhindern.
- Zugangsdaten und Secrets für potenziell offengelegte Systeme rotieren , um das Risiko nach einer Kompromittierung zu verringern.
- Postinstall-Skripte einschränken und Allowlisting für Abhängigkeiten implementieren mit DevSecOps-Tools , um die Ausführung nicht vertrauenswürdigen Codes zu begrenzen.
- Paketintegrität durch Signierung, Herkunftsnachweise oder Attestierungen verifizieren , um vertrauenswürdige Quellen sicherzustellen.
- Build-Umgebungen isolieren und den ausgehenden Netzwerkzugriff beschränken , um bösartige Rückrufverbindungen zu blockieren.
- Anomales Verhalten mithilfe von EDR oder Laufzeitkontrollen überwachen , um verdächtige Prozesse und Verbindungen zu erkennen.
- Incident-Response-Pläne für Szenarien von Lieferkettenangriffen testen und Angriffssimulations-Tools verwenden.
Zusammengenommen tragen diese Maßnahmen dazu bei, die Reichweite von Angriffen auf die Software-Lieferkette zu begrenzen und gleichzeitig die Widerstandsfähigkeit in Entwicklungs- und Bereitstellungsumgebungen zu erhöhen.
Wandel bei den Bedrohungen der Software-Lieferkette
Dieser Vorfall spiegelt einen Wandel bei Angriffen auf die Software-Lieferkette wider: Angreifer zielen zunehmend auf Maintainer und Vertriebskanäle statt auf Schwachstellen im Code.
Mit dem Wachstum von Open-Source-Ökosystemen ermöglichen diese Vorgehensweisen effizientere, unauffälligere Kompromittierungen mit größeren Auswirkungen auf nachgelagerte Systeme.
Diese Entwicklungen verdeutlichen den Bedarf an einem strukturierteren Ansatz für die Sicherheit der Software-Lieferkette in Entwicklungs- und Bereitstellungs-Workflows.