Gefährliche Altlast: : XZ-Backdoor in Docker Hub Images entdeckt
Wer geglaubt hat, der Vorfall mit der XZ-Utils-Backdoor sei Geschichte, den belehren Sicherheitsanalysten jetzt eines besseren: Es wurden 35 Docker-Images auf Docker Hub identifiziert, die genau die berüchtigte Backdoor enthalten – fast eineinhalb Jahre nach der ursprünglichen Schreckensnachricht. Besonders kritisch: Viele dieser Images dienten als Basis für weitere Builds und verbreiten so die Hintertür unbemerkt weiter.
Das Sicherheitsunternehmen Binarly hat bei einer Untersuchung von Kundensystemen eine unangenehme Überraschung erlebt: Es wurden insgesamt 35 Docker-Images entdeckt, die mit der XZ-Utils-Backdoor infiziert sind. Was besondere Sorgen bereitet: Mehrere dieser Images dienten als Grundlage für weitere Container, wodurch sich die schädliche Codebasis transitiv über die gesamte Docker-Umgebung verbreitete.
Die Entdeckung zeigt erneut, wie anfällig die Software-Lieferkette ist – insbesondere bei öffentlich verfügbaren und weit verbreiteten Basis-Images.
Ursprung des Vorfalls
Der XZ-Utils-Supply-Chain-Angriff (CVE-2024-3094, CVSS-Score: 10,0) wurde Ende März 2024 bekannt, als der Entwickler Andres Freund eine Hintertür in den Versionen 5.6.0 und 5.6.1 der beliebten Kompressionsbibliothek entdeckte.
Der Backdoor-Code befand sich in der Bibliothek liblzma.so, die von OpenSSH-Servern genutzt wird. Sobald sich ein Client mit einem infizierten SSH-Server verband, konnte ein Angreifer mit einem speziellen privaten Schlüssel die Authentifizierung umgehen und beliebige Befehle mit Root-Rechten ausführen. Möglich wurde dies durch das gezielte Hijacking der Funktion RSA_public_decrypt über den IFUNC-Mechanismus von glibc.
Langfristig geplante Infiltration
Die Manipulation geht auf einen Entwickler mit dem Pseudonym „Jia Tan“ (JiaT75) zurück, der über fast zwei Jahre Codebeiträge lieferte, um sich das Vertrauen der Community zu erschleichen. Erst danach erhielt er die Rechte eines Maintainers – ein Indiz für die strategische, langfristige Planung des Angriffs.
Binarly wertete den Vorfall damals als hochprofessionelle, staatlich unterstützte Operation mit komplexer, mehrstufiger Implantationsstruktur, die eindeutig über den Rahmen eines einmaligen Angriffs hinausging.
Gefährliche Persistenz in der Container-Welt
Die jüngsten Analysen zeigen, dass selbst zig Monate nach Entdeckung der Backdoor kompromittierte Images im Open-Source-Ökosystem bestehen bleiben. Darunter befinden sich zwölf offizielle Debian-Docker-Images sowie mehrere darauf aufbauende Container.
Binarly teilte mit, dass das Unternehmen die kompromittierten Basis-Images den Debian-Maintainern gemeldet habe. Diese erklärten allerdings, man habe sich bewusst dafür entschieden, die Artefakte als „historische Kuriosität“ weiterhin verfügbar zu lassen – insbesondere angesichts der nach ihrer Einschätzung äußerst unwahrscheinlichen Faktoren, die für eine Ausnutzung erforderlich seien, etwa im Kontext von Containern oder Container-Images.
Allerdings wies Binarly darauf hin, dass das Belassen öffentlich zugänglicher Docker-Images mit einer potenziell über das Netzwerk erreichbaren Hintertür ein erhebliches Sicherheitsrisiko darstellt – selbst wenn die Voraussetzungen für eine erfolgreiche Ausnutzung, wie der direkte Netzwerkzugang zu einem infizierten Gerät mit aktivem SSH-Dienst, schwer zu erfüllen sind.
Lehren für die Zukunft
Der Vorfall unterstreicht, dass selbst kurzlebiger Schadcode lange Zeit unbemerkt in offiziellen Container-Images überleben kann. Über CI/CD-Pipelines und abhängige Projekte kann sie sich unauffällig verbreiten.
Binarly fordert deshalb grundsätzlich ein kontinuierliches Binär-Level-Monitoring von Container-Images, das über reine Versionskontrollen hinausgeht. Nur so lassen sich persistente Bedrohungen in komplexen Software-Lieferketten frühzeitig erkennen und eindämmen.