Ein Angriff auf die Software-Lieferkette hat Maven Central kompromittiert und Angreifern ermöglicht, sich als vertrauenswürdige Jackson-JSON-Bibliothek auszugeben und Malware zu verbreiten.
Die Kampagne zeigt, wie selbst subtile Tricks bei der Namensgebung das Vertrauen von Entwicklern untergraben und unbemerkt Schadcode in Produktionsumgebungen einschleusen können.
Die Angreifer haben „… große Anstrengungen unternommen, um eine mehrstufige Payload mit verschlüsselten Konfigurationszeichenfolgen, einem entfernten Command-and-Control-Server zur Bereitstellung plattformspezifischer ausführbarer Dateien und mehreren Verschleierungsebenen zu entwickeln, die Analysen erschweren sollen“, sagten die Aikido-Forscher.
Angriff auf die Jackson-Typosquatting-Lieferkette
Der Angriff setzt auf Typosquatting und die Nachahmung von Namespaces. Der Name des bösartigen Pakets unterscheidet sich nur durch ein einziges Namespace-Element vom legitimen Namen, sodass der Unterschied leicht übersehen wird.
Um den Vorgang zusätzlich zu legitimieren, registrierten die Angreifer eine ähnlich aussehende Domain, fasterxml[.]org, die die legitime fasterxml[.]com-Projektdomain nachahmt.
WHOIS-Daten zeigen, dass die Domain erst wenige Tage vor der Entdeckung der Malware registriert wurde – eine Taktik, die häufig genutzt wird, um einer frühzeitigen Erkennung zu entgehen.
Sobald die Malware als Abhängigkeit eingebunden ist, wird sie in Spring-Boot-Umgebungen automatisch ausgeführt.
Beim Start der Anwendung sucht Spring nach @Configuration-Klassen und löst JacksonSpringAutoConfiguration aus, sodass der Schadcode ohne ausdrücklichen Aufruf durch den Entwickler ausgeführt werden kann.
Die Malware prüft, ob ApplicationRunner.class vorhanden ist, um zu bestätigen, dass sie in einer Spring-Boot-Umgebung ausgeführt wird, und so eine konsistente Ausführung sicherzustellen.
Um einer Analyse zu entgehen, verschleierten die Angreifer den Code in der JAR-Datei massiv.
Die Aikido-Forscher beobachteten Techniken, die sowohl menschliche Prüfer als auch auf maschinellem Lernen basierende Analysewerkzeuge verwirren sollen, darunter den Missbrauch von Unicode und Rauschen im Stil von Prompt-Injection-Angriffen.
Nach der Entschlüsselung stellte sich heraus, dass der Code ein Trojaner-Downloader war, der einen entfernten Command-and-Control-Server (C2) kontaktiert, um zusätzliche Payloads abzurufen.
Die Malware erstellt einen Fingerabdruck des Host-Betriebssystems und lädt mithilfe AES-verschlüsselter Konfigurationsdaten plattformspezifische Binärdateien herunter.
Die Analyse dieser Payloads bestätigte, dass es sich bei den Linux- und macOS-Varianten um Cobalt-Strike-Beacons handelt – ein Werkzeug, das von Ransomware-Gruppen und Advanced-Persistent-Threat-(APT-)Akteuren häufig für Fernzugriff, den Diebstahl von Zugangsdaten und die laterale Bewegung missbraucht wird.
Risiken in der Software-Lieferkette minimieren
Angriffe auf Software-Lieferketten zielen zunehmend auf vertrauenswürdige Open-Source-Ökosysteme ab und machen den sorgfältigen Umgang mit Abhängigkeiten sowie die Sicherheit von Builds zu Prioritäten für Entwicklerteams.
Sobald ein bösartiges Paket eingeschleust wurde, kann es sich schnell über Anwendungen, Pipelines und Umgebungen hinweg verbreiten.
Die folgenden Maßnahmen zielen darauf ab, das Risiko kompromittierter Abhängigkeiten zu senken, die Erkennung bösartigen Verhaltens zu verbessern und die Auswirkungen von Bedrohungen der Lieferkette zu begrenzen.
- Prüfen Sie Java-Projekte und Abhängigkeitsbäume auf unbekannte Pakete, entfernen Sie verdächtige Abhängigkeiten und erstellen Sie Anwendungen aus bekannten, vertrauenswürdigen Quellen neu.
- Erzwingen Sie strikte Abhängigkeitskontrollen durch das Festlegen von Versionen, die Verwendung von Allow-Lists, die Überprüfung von Prüfsummen oder Signaturen sowie die Beschränkung von Builds auf vertrauenswürdige Repository-Spiegel.
- Verwenden Sie Software-Kompositionsanalysen und verhaltensbasierte Überwachung zur Erkennung anomaler Abhängigkeiten, unerwarteten Ladens von Klassen oder ungewöhnlicher Netzwerkaktivität.
- Härten Sie CI/CD-Pipelines und Entwicklerumgebungen durch die Anwendung des Least-Privilege-Prinzips, die Beschränkung der Internetverbindung und die Überwachung der Ausführung während der Build-Phase.
- Implementieren Sie Laufzeit- und Endpunktschutz, etwa EDR oder eine Überwachung auf Anwendungsebene, um die unbefugte Ausführung von Binärdateien oder ausgehende Verbindungen zu erkennen.
- Stärken Sie Governance und Bereitschaft durch das Testen von Plänen zur Reaktion auf Sicherheitsvorfälle und die regelmäßige Überprüfung von Abhängigkeiten.
Zusammen tragen diese Kontrollen dazu bei, das Risiko für die Lieferkette zu senken, die Transparenz bei bösartigen Abhängigkeiten zu verbessern und den Schadensradius im Fall einer Kompromittierung zu begrenzen.
Das wachsende Risiko von Open-Source-Lieferketten
Dieser Vorfall verdeutlicht eine umfassendere Verschiebung der Angreiferstrategie hin zum Missbrauch der Software-Lieferkette und des inhärenten Vertrauens in Open-Source-Ökosysteme.
Moderne Entwicklungspipelines sind in hohem Maß auf Automatisierung angewiesen und führen häufig Abhängigkeiten mit nur begrenzter manueller Kontrolle ein.
Dadurch kann sich ein einziges bösartiges Paket schnell über Hunderte von Anwendungen verbreiten und die Auswirkungen einer ansonsten möglicherweise lokal begrenzten Kompromittierung verstärken.
Da Angriffe dieser Art häufiger werden, ist die Absicherung der Software-Lieferkette zu einem kritischen Schwerpunkt für Organisationen geworden, die in großem Umfang auf Open-Source-Abhängigkeiten angewiesen sind.