Im Frühjahr des vergangenen Jahres sorgte die Enthüllung einer raffinierten Hintertür in der Linux-Komponente "XZ Utils" für Aufsehen. Der Entwickler "Jia Tan" hatte den Schadcode über zwei Jahre hinweg vorbereitet und in die Bibliothek "liblzma.so" eingeschleust, die unter anderem vom OpenSSH-Server genutzt wird. Über manipulierte IFUNC-Resolver konnten gezielt Funktionen im SSH-Dienst gehookt und so ein verdeckter Zugriff ermöglicht werden. Die betroffenen Pakete waren zeitweise in weit verbreiteten Linux-Distributionen wie Debian, Fedora und OpenSUSE enthalten.

35 kompromittierte Images

Neue Analysen des Sicherheitsunternehmens Binarly zeigen nun, dass die Schwachstelle auch in mehreren Docker-Images fortbesteht, die zur Zeit des Vorfalls erstellt wurden. Betroffen sind nicht nur ursprüngliche Debian-basierte Images, sondern auch daraus abgeleitete Versionen, die auf Docker Hub weiterhin öffentlich verfügbar sind. Die Forscher identifizierten über 35 kompromittierte Images, darunter mindestens zwölf Debian-Varianten. Da einige dieser Images als Basis für weitere Builds dienen, könnten sie sich unbemerkt in nachgelagerte Softwareprojekte ausbreiten.

Besonders kritisch ist laut Binarly, dass sich die infizierten Images trotz der Offenlegung des Problems noch immer in öffentlichen Repositories befinden. Zwar erfordert ein erfolgreicher Angriff, dass der Angreifer über den passenden Schlüssel verfügt und Netzwerkzugang zu einem betroffenen Container mit laufendem SSH-Dienst hat. Dennoch warnt das Unternehmen vor den Risiken für die Software-Lieferkette, zumal der Umfang der Verbreitung bei anderen Distributionen wie Fedora oder OpenSUSE bislang unbekannt ist.

Container-Images überprüfen

Binarly fordert deshalb eine konsequentere Entfernung kompromittierter Container-Images und setzt mit seiner Transparency Platform auf automatisierte Erkennungsmethoden wie IFUNC-Hooking-Analysen und YARA-Regeln. Der Fall verdeutlicht nach Ansicht der Forscher, wie lange selbst kurzzeitig eingeschleuste Hintertüren unentdeckt in Container-Ökosystemen bestehen können – und dass allein die Aktualisierung auf neue Versionen keine vollständige Absicherung garantiert.

Admins sollten ihre Container-Umgebungen gezielt auf kompromittierte Images prüfen und dabei auf die von Binarly veröffentlichten Indicators of Compromise (IoCs) wie Image-Namen und Hash-Werte zurückgreifen. Ein Abgleich mit den eigenen Container-Repositories und Build-Pipelines kann helfen, infizierte Basis-Images zu identifizieren und zu ersetzen. Zusätzlich empfiehlt sich der Einsatz von Sicherheitsscannern, die auf Manipulationen im Binärcode prüfen, sowie eine konsequente Aktualisierung und Signaturprüfung von Images. Wo möglich, sollte der SSH-Dienst in Containern deaktiviert oder auf vertrauenswürdige, aktuell gepflegte Distributionen beschränkt werden.