Supply-Chain-Angriffe: Risiken durch vertrauenswürdige Software

Was Supply-Chain-Angriffe anders macht

Bei einem traditionellen Angriff zielt der Gegner direkt auf Ihre Organisation ab – nutzt Ihre Schwachstellen aus, phisht Ihre Mitarbeiter oder brute-forciert Ihre Anmeldedaten. Ein Supply-Chain-Angriff nimmt einen indirekteren Weg: Der Angreifer kompromittiert Software, Hardware oder Dienste, denen Sie vertrauen und die Sie selbst installieren. Wenn diese vertrauenswürdige Komponente an Sie geliefert wird, kommt die bösartige Nutzlast mit.

Dieser Ansatz ist verheerend effektiv, weil Organisationen ausgereifte Abwehrmechanismen gegen direkte Angriffe haben, aber oft implizites Vertrauen in ihre Software-Anbieter, Paket-Repositories und Build-Pipelines ausdehnen. Der Angreifer muss nur einen vorgelagerten Anbieter kompromittieren, um Tausende von nachgelagerten Zielen zu erreichen.

Hochkarätige Fallstudien

SolarWinds Orion (2020)

APT29 (eine russisch staatlich gesponserte Gruppe) kompromittierte das Build-System von SolarWinds, einer weit verbreiteten IT-Monitoring-Plattform. Sie fügten eine Hintertür – SUNBURST genannt – in das legitime SolarWinds Orion Software-Update ein. Ungefähr 18.000 Organisationen installierten das trojanisierte Update, darunter das US-Finanzministerium, das Department of Homeland Security und wichtige Rüstungsunternehmen. Die Hintertür lag nach der Installation zwei Wochen lang ruhend, bevor sie aktiviert wurde, und umging verhaltensbasierte Erkennung.

Die Lektion: Selbst signierte, vom Anbieter gelieferte Software-Updates sind nicht bedingungslos vertrauenswürdig.

XZ Utils Backdoor (2024)

Ein Bedrohungsakteur verbrachte fast zwei Jahre damit, geduldig Vertrauen im XZ Utils Open-Source-Projekt unter einer falschen Identität aufzubauen und schrittweise die Wartung zu übernehmen. Dann fügten sie eine ausgefeilte Hintertür ein, die auf systemd-gebundene SSH-Daemons auf Linux-Systemen abzielte. Die Hintertür wurde von einem Microsoft-Ingenieur entdeckt, der bei SSH-Logins ungewöhnliche CPU-Auslastung bemerkte – nur wenige Tage bevor die kompromittierte Version in wichtige Distributions-Repositories gelangen sollte.

Dieser Fall demonstrierte die Raffinesse von Langzeit-Social-Engineering, das auf Open-Source-Maintainer abzielt.

npm-Paket-Vergiftung

Das JavaScript-Ökosystem hat wiederholt Supply-Chain-Vorfälle erlebt:

• event-stream (2018): Ein neuer Maintainer fügte eine Krypto-Mining-Nutzlast ein, die auf eine bestimmte Bitcoin-Wallet abzielte
• node-ipc (2022): Der Maintainer fügte absichtlich destruktiven Code ein, der auf russische und weißrussische IP-Adressen abzielte
• Typosquatting: Pakete namens lodahs, crossenv oder momnet, um bei falsch getippten npm install-Befehlen zu erwischen

Die npm-Registry allein beherbergt über zwei Millionen Pakete, und Abhängigkeitsbäume umfassen häufig Hunderte von Paketen – von denen die meisten Ihr Team nie überprüft hat.

Angriffsvektoren in der Software-Lieferkette

Supply-Chain-Angriffe dringen durch mehrere Kanäle ein:

• Kompromittierte Build-Systeme: Einschleusen von bösartigem Code während der Kompilierung (wie bei SolarWinds)
• Dependency Confusion: Ein bösartiges öffentliches Paket mit demselben Namen wie ein privates internes Paket hochladen und die Auflösungsreihenfolge des Paketmanagers ausnutzen
• Typosquatting: Pakete mit ähnlichen Namen wie beliebte Bibliotheken registrieren
• Kontoübernahme: Das Konto eines Paket-Maintainers kapern, um ein bösartiges Update zu veröffentlichen
• CI/CD-Pipeline-Kompromittierung: Bösartige Schritte in Build-Pipelines einschleusen, die breiten Zugriff auf Produktionssysteme haben
• Kompromittierte Hardware: Implantate, die während der Fertigung hinzugefügt werden (ein Problem für Firmware und Netzwerkausrüstung)

Verteidigung: Abhängigkeitsverwaltung

Abhängigkeitsversionen fixieren – verwenden Sie keine fließenden Versionsbereiche (^1.2.3 oder latest). Lock-Dateien (package-lock.json, Cargo.lock, requirements.txt mit Hashes) stellen sicher, dass Sie genau das installieren, was Sie getestet haben. Überprüfen Sie die Integrität mit Checksummen:

# npm – gegen Lock-Datei überprüfen
npm ci

# pip – Hash-Überprüfung erfordern
pip install --require-hashes -r requirements.txt

Abhängigkeiten regelmäßig prüfen: npm audit, pip-audit, cargo audit, trivy für Container. Abonnieren Sie Sicherheitshinweise für Ihre wichtigsten Abhängigkeiten über GitHubs Dependabot oder OSV.dev.

Minimieren Sie Ihren Abhängigkeitsbaum. Bevor Sie ein Paket hinzufügen, fragen Sie sich: Wird diese Abhängigkeit aktiv gepflegt? Wie weit verbreitet ist sie? Könnten Sie dies selbst in 20 Zeilen implementieren?

Verteidigung: Build-Pipeline-Sicherheit

• Verwenden Sie reproduzierbare Builds – dieselbe Quelle sollte immer eine Bit-für-Bit identische Ausgabe erzeugen, wodurch nicht autorisierte Änderungen erkennbar sind
• Signieren Sie Ihre Release-Artefakte und überprüfen Sie Signaturen vor der Bereitstellung: Verwenden Sie Sigstore/cosign für Container und Binärdateien
• Erzwingen Sie geringste Privilegien in CI/CD: Build-Jobs sollten nur Zugriff auf das haben, was sie brauchen; Geheimnisse sollten auf spezifische Pipelines und Umgebungen beschränkt sein
• Aktivieren Sie SLSA (Supply Chain Levels for Software Artifacts) – ein Framework, das überprüfbare Herkunft für Build-Artefakte bereitstellt
• Überprüfen Sie GitHub Actions Workflows und Drittanbieter-Actions – fixieren Sie Actions auf spezifische Commit-SHAs, nicht auf veränderliche Branch-Namen oder Tags

Verteidigung: Anbieter- und Open-Source-Risiko

• Pflegen Sie eine Software Bill of Materials (SBOM) – ein vollständiges Inventar aller Software-Komponenten und ihrer Versionen. Tools wie Syft und CycloneDX können SBOMs automatisch generieren.
• Bevor Sie eine kritische Open-Source-Bibliothek übernehmen, überprüfen Sie die Maintainer-Aktivität, das Governance-Modell und ob sie vergangene Sicherheitsvorfälle hatte
• Für kritische Abhängigkeiten erwägen Sie Vendoring – den Quellcode in Ihr eigenes Repository zu kopieren – um zu verhindern, dass vorgelagerte Änderungen Sie automatisch betreffen
• Implementieren Sie Netzwerk-Egress-Kontrollen in Ihrer Build-Umgebung, um zu verhindern, dass bösartige Pakete während der Build-Zeit Geheimnisse exfiltrieren