Dies ist die erste Folge einer Artikelserie über die am weitesten verbreitete Art von Angriffen auf die Software-Lieferkette: Angriffe, bei denen ein öffentliches Register von Softwarekomponenten missbraucht wird, um Open-Source-Projekte um Artefakte hochzuladen, die mit anderen Benutzern geteilt werden könnten. Wenn die Bösewichte dort Schadsoftware veröffentlichen und die Registry als Vehikel zur Verbreitung von Malware verwenden, haben wir einen Supply-Chain-Angriff, wenn die betroffenen Organisationen die infizierte Softwarekomponente installieren oder ausführen.
Um die Diskussion zu vereinfachen, sprechen wir über Softwarepakete:, Komponenten in gepackter Form, die von Dritten erstellt wurden. Dazu gehören nicht nur Komponenten, die von Paketmanagern wie NPM oder Poetry verwendet werden, sondern auch Betriebssystemkomponenten einschließlich Bibliotheken und ausführbaren Binärdateien, Container-Bilder, und virtuelle Maschinen oder Werkzeugerweiterungen für Entwicklungs-, Build- und Bereitstellungstools. Schadsoftware ist allgegenwärtig. Cyberkriminelle stört das nicht: Sie nutzen die Alternativen moderner Software-Infrastrukturen und nutzen die Registry und das Tool, das ihren Zielen am besten entspricht. Denken Sie also daran, dass Softwarepakete eine Abkürzung für Container-Images, Binärpakete, Open-Source-Repositories und Erweiterungen oder Plugins aller Art (IDEs, CI/CD Systeme, Build-Tools). Alle sind regelmäßig Angriffen ausgesetzt.
Die Serie wird 5 Folgen haben:
- Was ist das Problem mit Open-Source-Paketen? Dies ist das Thema dieses Beitrags. Warum veröffentlichen Kriminelle aller Art schädliche Pakete? Warum sollte ich mir Sorgen machen?
- Anatomie bösartiger Pakete: Was sind die Trends? In dieser Folge konzentrieren wir uns auf die Bedrohung, die wir mit unserem MEW-System Tag für Tag überwachen. Bei einem starken Hintergrundrauschen aufgrund einer großen Anzahl bösartiger Pakete, die Typosquatting oder Abhängigkeitsverwirrung verwenden, ist ein kleinerer Prozentsatz der Angriffe viel heimtückischer und stellt ein größeres Risiko dar. Wie hat sich das Verhalten der böswilligen Akteure in Bezug auf das Betriebssystem in der jüngsten Vergangenheit geändert? Wie lauten die Zahlen? Welche Taktiken, Techniken und Verfahren werden verwendet und welche schädlichen Aktionen wurden beobachtet?
- Schutz vor schädlichen Open-Source-Paketen: Was (nicht) funktioniertDie meisten sicherheitsbewussten Fachleute haben Ideen, wie man mit dieser Bedrohung umgehen kann. Wir haben Sicherheitsmanager ohne Zögern sagen hören: SCA Tools erkennen bereits, wann eine Paketversion Schadsoftware enthält. Oder sie setzen bekannte, hochgeprüfte Softwarekomponenten ein, bei denen Schadsoftware umgehend erkannt und entfernt wird. Sie verwenden offene Neben-/Patch-Versionen, um Schwachstellen automatisch zu beheben. Dies ist der richtige und empfohlene Weg, das Risiko von Open-Source-Abhängigkeiten zu senken, ganz nach dem Prinzip „Patches früh und oft“. In dieser Folge untersuchen wir, warum diese Vorstellungen falsch sind und wie solche Missverständnisse zur Popularität dieses Angriffsmechanismus und zu einem enormen Risiko für Unternehmen beitragen. Abschließend erläutern wir, was funktioniert und wie viel Aufwand und Ressourcen erforderlich sind.
- Schädliche Open-Source-Pakete: Der Xygeni-Ansatz. In dieser Folge präsentieren wir die Strategie, die wir bei Xygeni für unser Malware Early Warning (MEW)-System verfolgen. Wie funktioniert dieses mehrstufige System in Echtzeit, wenn eine neue Paketversion veröffentlicht wird, wie werden Beweise aus verschiedenen Quellen erfasst, wie erfolgt die Triage, welche Klassifizierungskriterien befolgen wir und warum ist dennoch eine manuelle Analyse erforderlich, um die Art eines bösartigen Paketkandidaten zu bestätigen? Wie das Feedback unserer internen und Registrierungsteams dem System hilft, aus in der Vergangenheit gesammelten Beweisen zu lernen, um Fehlalarme auf ein Minimum zu reduzieren. Und wir werden erklären, wie wir NPM, GitHub, PyPI und anderen wichtigen Infrastrukturen in den Open-Source-Ökosystemen helfen, die Verweildauer zu verkürzen.
- Open Source ausnutzen: Was Sie von den Bösewichten erwarten können. Die Serie endet mit einem Fokus auf die neuesten Maßnahmen, die die Angreifer ergreifen, um die Angriffe heimlicher, schwerer zu erkennen, gezielter auf bestimmte Branchen auszurichten und mehr Nutzen aus dieser Angriffsklasse zu ziehen. Werden Ransomware-Angriffe über dieses Mittel durchgeführt? Wie nutzen die Bösewichte KI-Tools, um ausgefeiltere Schadpakete zu liefern? Sind beliebte Top-Projekte in Gefahr? Dies soll den Lesern ein Gefühl für dieses Wettrüsten geben und was sie kurzfristig (zweite Hälfte des Jahres 2024) und mittelfristig (2025) erwarten können. Wir werden erfahren, wie Angriffe wie die jüngsten XZ-Utils-Hintertüroder der Angriff auf die Landwirtschaft Elektronenbauer im März/März 2024 zeigen, dass wir die Entwicklung der Gegner wachsam verfolgen sollten.
Eröffnen wir die Bühne mit der ersten Episode: Was ist los mit bösartigen Open-Source-Paketen?
Was ist das Problem mit Open-Source-Paketen?
In den letzten Jahren haben Kriminelle aller Art Open-Source-Software-Registrierungen verwendet, um bösartiges Verhalten zu verbreiten. Diese Aktivitäten sind so alt wie Open Source, aber ihre Häufigkeit ist in den letzten drei Jahren explosionsartig angestiegen.
Veröffentlichung bösartiger Komponenten in öffentlichen Registern (Abhängigkeitsbasierte Angriffe) ist ein asymmetrischer Guerillakrieg, den Bedrohungsakteure zur Verbreitung von Malware einsetzen. Dabei nutzen sie das Vertrauen von Organisationen in Open-Source-Komponenten unbekannter Entwickler aus (denken Sie an die Abhängigkeit XKCD Comic?). Da Sie Paketen vertrauen und es Ihnen nichts ausmacht, den Paketinhalt und seine Abhängigkeiten manuell zu überprüfen, sind diese Angriffe außerordentlich effektiv. Und die Asymmetrie entsteht dadurch, dass sie weitgehend automatisiert werden können und die Bösewichte nicht direkt mit dem Opfer interagieren müssen. Sie laden das Paket einfach in das öffentliche Register hoch und lassen es dort.
Schädliche Pakete stieg im Jahr 6 um das 2022-facheund wuchs 2.5 weiter um das 2023-fache. Im vergangenen Jahr wurden satte 245,000 bösartige Pakete entdeckt, eine Zahl, die die Gesamtzahl der vorherigen Jahre zusammen mehr als verdoppelt. Das ist ein exponentielles Wachstum! Von Paketentfernungen als bestätigte Malware in Hunderten im Jahr 2021 und in Tausenden im Jahr 2022 sahen wir 2023 viel mehr „Hintergrundrauschen“, mit einem ähnlichen Tempo für dieses Jahr. Und versteckt in diesem Hintergrund, der von unerfahrenen Cyberkriminellen verursacht wurde, die den „Weg des geringsten Widerstands“ verfolgten, schaffte eine Minderheit von hochkarätigen Angriffen sogar in den allgemeinen Medien Schlagzeilen.
Warum ist das ein Problem von solchem Ausmaß? Es gibt eine Übermaß an Vertrauen in der gesamten Kette. Open-Source-Software wird mit ihrem Quellcode verteilt und unter einer bestimmten Lizenz veröffentlicht. Ja, jeder kann den Quellcode einsehen, aber wer tut das überhaupt? Wer erstellt die Software aus den Quellen, nachdem er überprüft hat, dass die Software keine Malware enthält? Wer übergibt die verpackte Komponente (auch bekannt als Paket) nachgelagert zum Paketmanager oder zum Build-Tool, stellt sicher, dass das Paket nicht mit Malware verseucht ist und dem vermeintlichen Quellcode entspricht, aus dem es stammen soll?
Warum sind Angriffe auf die Infrastruktur so einfach?
Paketregistrierungen sind offen und erfordern oft nur eine minimale Überprüfung der Identität des Herausgebers. „Jeder ist willkommen, seine Software hier zu veröffentlichen!“ Die Hürde für Angreifer ist niedrig: Sie verwenden Wegwerf-E-Mail-Adressen und Wegwerf-GitHub-Konten, um in kurzen, Phishing-ähnlichen Kampagnen Hunderte von bösartigen Paketen zu erstellen. Nur für gezielte Kampagnen ist eine höhere Raffinesse erforderlich: Wir haben sogar die Erstellung eines glaubwürdigen GitHub-Quell-Repositorys mit vielen Sternen und commits von mehreren gefälschten Mitwirkenden und anderen Metriken der Popularität und Wartung. Sterngucker und Reputation durch Fake-Beiträge ist nicht schwer zu automatisieren. Wir haben Missbrauch von offenen Software-Infrastrukturen aller Art gesehen, nicht nur von Malware, wie zum Beispiel Vorfall mit dem Teeprotokoll.
Paketmanager wurden für Benutzerfreundlichkeit und nicht für Sicherheit entwickelt. Sie können vor und nach der Installation Post-Install-Skripte ausführen (manchmal ist die Kompilierung von nativem Code für eine Bibliothek erforderlich). Außerdem Paketmanager Installieren Sie Pakete aus mehreren Quellen. Manchmal werden standardmäßig öffentliche Register verwendet. Sie haben nicht nach einer Nichtübereinstimmung zwischen den Metadaten in der Veröffentlichungsanforderung und den Metadaten im Paket selbst gesucht.
Abhängigkeiten sind verschachtelt und bilden einen Graphen. In bestimmten Ökosystemen wie Node (JavaScript) häufen sich kleinkörnige Abhängigkeiten zu Hunderten oder Tausenden. Eine Sache ist es, eine strikte Kontrolle über die direkten Abhängigkeiten zu haben, die von meinen Softwareprojekten deklariert werden, aber transitive Abhängigkeiten sind schwerer zu kontrollieren. Open Source folgte dem Motto „Die Freunde meiner Freunde sind meine Freunde“. Brüderlichkeit ist die Norm im wilden Fernen Osten! Bedrohungsakteure wissen das und verstecken das bösartige Verhalten tief in obskuren Abhängigkeiten, die oft unbekannt sind. Dies war der Fall bei der Ereignisstrom Vorfall, der sich gegen die Copay Brieftasche.
So funktionierte Open-Source-Software seit ihrer Einführung. Daran wird sich nicht viel ändern. Einige Paketregister verlangen bestenfalls eine Zwei-Faktor-Authentifizierung und oft nur für die beliebtesten Pakete. Einige Register bieten Bereiche, einen Namespace, der einer geprüften Organisation gehört, aber tragisch andere unterstützen es nicht (PyPI) oder machen es optional (NPM). Es ist interessant festzustellen, dass sogar ein einfaches Screening-Schema (basierend auf der Kontrolle des DNS oder GitHub-Repositorys/der Organisation, die mit der Gruppen-ID übereinstimmt) und PGP-Signaturen obligatorisch für alle Artefakte außer Prüfsummen entfernt den Großteil des „Rauschens“, Typosquatting-ähnliche bösartige Pakete, und begrenzt einen Großteil Abhängigkeitsverwirrung. Ausgefeilte Angriffe sind möglich, aber viel schwieriger, und nur wenige wie die com.github.codingandcoding:maven-compiler-plugin bekannt für Maven Central. Und nicht alle Maven-Registries folgen denselben Praktiken!
Sicherheitskontrollen bei Paketmanagern können Abhängigkeitsangriffe zwar belasten, aber nicht verhindern. Das Problem bei der Multi-Faktor-Authentifizierung besteht darin, dass für die Automatisierung abgeleitete Anmeldeinformationen wie Zugriffstoken oder APIAPI-Schlüssel für Konten generiert werden, die in APIAPI-Aufrufen verwendet werden sollen, die von Automatisierungsskripten aus erfolgen, ohne dass ein unterstützender interaktiver Benutzer einen zweiten Faktor bereitstellt. MFA ist gut geeignet, um Benutzerkonten vor Passwortlecks zu schützen, aber die generierten Zugriffstoken oder APIAPI-Schlüssel müssen geschützt werden, während sie aktiv sind, sonst werden die Angreifer sich als ihr Besitzer ausgeben. Ein großer Teil der paketbasierten Lieferkettenkampagnen beginnt mit einem durchgesickerten Schlüssel/Token. Denken Sie nur an Vorfälle wie Ledger, 3CXund viele mehr, bei denen im Zuge eines vorläufigen Eindringens zunächst nicht-interaktive Anmeldeinformationen exfiltriert wurden, um den Supply-Chain-Angriff zu starten.
Die Reaktion auf diese Bedrohung war nicht robust genug. In der dritten Folge werden wir uns darauf konzentrieren, was funktioniert hat und was kläglich gescheitert ist. Die Branche muss gemeinsam an der standards, Prozesse, Schulungen und Werkzeuge zur Risikominimierung für globale Lieferketten. Dieses Problem kann eine einzelne Organisation nicht allein lösen.
Zum Abschluss dieses Abschnitts das entscheidende Missverständnis: Wir sprechen über böswilligen Pakete, nicht verletzlich Schwachstellen entstehen durch Design- oder Programmierfehler, die versehentlich und ohne böse Absicht eingeführt werden. Die Schwachstellen können ausgenutzt werden, viele werden es aber nicht. Schädliche Pakete sind immer absichtlich erstellt und können zu 100 % ausgenutzt werden, wenn sie ausgeführt werden. Kein vergleichbares Risiko! Daher Es ist paradox zu sehen, wie viel Aufwand in die Erkennung und Beseitigung von Schwachstellen gesteckt wird und wie wenig entsprechende Maßnahmen gegen bösartige Komponenten ergriffen werden..
„Wir nehmen Sicherheit ernst“
Stellen wir uns das Übliche vor Acme Corporation. Acme, ein wichtiger Anbieter für WileCoyote.com, bezieht den Großteil seiner Software von Drittanbietern, wobei mehr als 80 % aus Open-Source-Projekten stammen. Sie produzieren Software für den internen Gebrauch, stellen aber auch Software für ihre Partner, Anbieter und Kunden/Endbenutzer bereit. Acme hat Software in Go, JavaScript, Java, C# und Python geschrieben und führt den Großteil seiner Software in der Cloud unter Kuberneteskubernetes-Clustern aus. Acme erstellt seine benutzerdefinierten Images aus Basisimages, die von Docker Hub und anderen Registern stammen. Und sie teilen auch einige Bibliotheken, Pakete und Container-Images in öffentlichen Registern.
Acme nimmt Sicherheit ernst. Sie sind sich des Problems bewusst, open source securityund das damit verbundene Risiko. Alle Entwickler, Systemmanager und DevOpsdevops-Ingenieure verwenden diese niedlichen kleinen Kryptoschlüssel als Zwei-Faktor-Authentifizierung. Alle commits zu Code-Repos sind signiert, Branch-Schutz ist mit obligatorischen Code-Überprüfungen aktiviert, CI/CD Gesperrt, Geheimnisse in einem geheimen Tresor gespeichert und mit einem internen Register, das externe Register teilweise spiegelt, in denen nur die zulässigen, auf der Whitelist aufgeführten Komponenten gespeichert sind. Von Acme erstellte Software muss Drittanbieterabhängigkeiten aus diesem Register übernehmen.
Wahrscheinlich passen die meisten Organisationen in dieses Profil. Liebe Leser, Ihre Organisation passt sicherlich, wenn Sie schon hier sind, nicht wahr?
Dann eines unglücklichen Tages, ein wichtiger Frontend-Entwickler bei Acme lief npm installiere acme-cute-lib, wobei vergessen wurde, dass @acme/cute-lib die richtige Abhängigkeit war. Der genaue Fehler ist nicht wichtig, es kann viel schiefgehen, selbst wenn man eine perfekte Kontrolle über den Software-Lebenszyklus annimmt. Unser Entwickler wusste nicht, dass eine APT-Gruppe es auf Acme abgesehen hatte und eine bösartige Komponente unter diesem Namen veröffentlichte, und zwar auf eine raffinierte Weise, sodass das bösartige Verhalten nur aktiviert wird, wenn die Software auf Acme-Computern installiert wird. Das Paket wurde nach seiner Veröffentlichung wochenlang nicht erkannt.
Es wird ein Installationsskript ausgeführt, das nach Anmeldeinformationen sucht (auf dem Laptop unseres Entwicklers befanden sich viele interessante Zugriffstoken), um Zugriff auf interne Software-Repositorys und das bereits erwähnte interne Repository zu ermöglichen, das natürlich nur über VPN zugänglich ist. Dem Schadcode gelang es, die bestehende VPN-Verbindung zu nutzen und eine Schadkomponente zweiter Stufe in der internen Registrierung zu veröffentlichen, wodurch eine gemeinsame Utilities-Bibliothek beeinträchtigt wurde, die von den meisten von Acme bereitgestellten Programmen gemeinsam genutzt wird.
Wochen später bemerkten andere Organisationen, die die veröffentlichten Tools von Acme nutzten, seltsamen Datenverkehr in ihren Netzwerken. Der Datenverkehr verwendete das Protokoll von Acme, wurde aber an Hosts geleitet, die der Acme-Domäne ähnelten. Der Datenverkehr war verschlüsselt, aber Systemüberwachungstools fanden Zugriff auf unerwartete Dateien und die Ausführung von Prozessen, die wie Systembefehle aussahen, aber letztendlich heruntergeladene ausführbare Dateien ausführten.
Der Rest ist Geschichte: Acme bestritt zunächst, dass ihnen ein solches Verhalten zuzuschreiben sei und dass alle Sicherheitsmaßnahmen getroffen worden seien. Erst als die Cybersecurity-Medien zu fragen begannen, warum die Quelle des festgestellten Verhaltens von Acmes Komponenten stammte und Sicherheitsanalysen veröffentlichten, wie durchsetzt diese Komponenten mit versteckter Malware waren, musste Acme den Vorfall erkennen und eine Incident-Response-Firma einschalten. Eine negative Marketingkampagne, die das hart erarbeitete Vertrauen in einer Sekunde untergrub.“Acme war eine npm-Installation von di entferntsaster„, lautete eine häufige Schlagzeile. Dann folgten Klagen und gekündigte Verträge.
Sehen Sie Ähnlichkeiten mit bekannten Vorfällen aus der Vergangenheit? Acme wurde in zwei Phasen Opfer eines Lieferkettenvorfalls, mit einer Mischung aus Abhängigkeitsverwirrung/Typosquatting Angriffe, bei denen die Workstation eines Entwicklers als Brückenkopf für die Infektion von Komponenten genutzt wurde, die dann in von Dritten genutzter Software landeten. Wie ließe sich dies verhindern oder eindämmen?
Warum vergiftete Pakete so beliebt sind
Dieser hypothetische Vorfall zeigt, dass Organisationen selbst bei einem vernünftigen Ansatz zur Open-Source-Sicherheit spezifische Maßnahmen benötigen, um nicht Opfer von Malware in Open-Source-Komponenten zu werden. Schematisch kann der Bedrohungsakteur:
- Erstellen Sie ein neues Paket (folgen Sie dabei den bekannten Methoden des Typosquatting oder der Abhängigkeitsverwirrung; dies ist der von den Bösewichten am häufigsten genutzte Weg).
- Versuchen Sie, eine vorhandene Malware zu infizieren, entweder durch Einschleusen in den Quellcode, durch den Versuch, sie als Mitwirkenden zu tarnen, über pull requestoder Social Engineering zu nutzen, um zum Maintainer zu werden (wie es „Jao Tan“ in der XZ Backdoor tat oder rechts9ctrl GitHub-Benutzer hat in der Ereignisstrom Vorfall im Herbst 2018) oder indem sie sich Anmeldeinformationen für ein Open-Source-Repository verschafften und sich als dessen Betreuer ausgaben;
- Schadsoftware während der Erstellung des Pakets einschleusen, entweder durch Ausführen eines bösartigen Build-Skripts, oder das Stören von Paketdownloads durch Man-in-the-Middle-Intercepts (glücklicherweise ist TLS mittlerweile in den meisten Registern immer erforderlich).
- Injizieren Sie die verpackte Komponente direkt in die Registrierung, typischerweise durch das Erfassen der Registrierungs-Anmeldeinformationen (die bevorzugte Alternative für viele ausgeklügelte Angriffe wie Acme, bei denen die kompromittierte Arbeitsstation in der ersten Phase den internen Registrierungs-Zugriffstoken hatte, z. B. in der üblichen .env or ~/.m2/settings.xml: Böse Akteure wissen, wo sie nach Geheimnissen suchen müssen). Außerdem wurden Schwachstellen in den Registern ausgenutzt.
Das Vergiften von Registern mit Malware ist die Grundlage für Abhängigkeitsangriffe. Nichts Neues unter der Sonne: Die Verbreitung ist explosionsartig angestiegen, aber die gleichen Techniken funktionieren heute noch wie vor fünf Jahren.
Quelle: Backstabber's Messer-Sammlung.
Das Schadpaket kann bei der Installation, während der Softwareerstellung oder zur Laufzeit ausgeführt werden. Und das Verhalten reicht von der Informationsexfiltration, z. B. dem Extrahieren von Geheimnissen für einen Zweitphasenversuch, bis hin zur Quellcodeextraktion und dem Einschleusen zusätzlicher Malware. In der nächsten Folge werden wir die Schadpakete und ihre Veröffentlichung analysieren.
Weiterführende Literatur
Die nächste Folge Anatomie bösartiger Pakete: Was sind die Trends? konzentriert sich auf echte Fälle, die wir mit unserem Malware-Frühwarnsystem Tag für Tag überwachen. Wir werden überprüfen, welche Arten von Malware beobachtet wurden und welche Taktiken, Techniken und Verfahren am beliebtesten sind. Wir werden die Verschleierung untersuchen und wie sie versucht, sich vor potenziellen Prüfern zu verbergen, die Ausweichtechniken, um einer Entdeckung zu entgehen, und wie sie sich durch Telemetrie und laterale Bewegung weiterentwickeln. Bitte bleiben Sie dran!
Referenzen
- Backstabber's Knife Collection: Ein Überblick über Angriffe auf die Lieferkette von Open-Source-Software. M. Ohm et al., Mai 2020.
- Open Source-Malware-Schutz. Whitepaper von Xygeni.
- Software Supply Chain Security Rückblick: Ein sichereres Jahr 2024 gestalten. Bericht von Xygeni.
