Maschinenidentitäten durch öffentlich zugängliche Docker-Images gefährdet

Wissenschaftler der Rheinisch-Westfälischen Technischen Hochschule Aachen (RWTH) haben die Ergebnisse einer Studie veröffentlicht, in der sie Zehntausende von Container-Images, die auf Docker Hub gehostet werden, auf vertrauliche Informationen untersucht haben. Die dortigen Images enthalten teils sehr sensible Informationen, die im Falle einer Offenlegung Software, Online-Plattformen und Nutzer Cyberbedrohungen aussetzen.

Laut den Forschern wurden 22.082 kompromittierte TLS-Zertifikate gefunden, die auf offengelegten privaten Schlüsseln beruhen, darunter 7.546 private, von einer Zertifizierungsstelle signierte Zertifikate und 1.060 öffentliche, von einer Zertifizierungsstelle (CA, Certificate Authorities) signierte Zertifikate. Die tausenden von Zertifizierungsstellen signierten Zertifikaten sind besonders besorgniserregend, da sie in der Regel von einer großen Anzahl von Benutzern verwendet werden. Zum Zeitpunkt der Veröffentlichung waren nach Angaben der Verfasser noch 141 dieser signierten Zertifikate gültig.

Bereits in der Vergangenheit gab es immer wieder Vorfälle, in denen Forscher hart kodierte Secrets und Schlüssel in Docker-Images gefunden haben. Docker Hub ist ein beliebtes Open-Source-Repository für Container-Images und wird häufig im Developer-Zyklus verwendet. Das Durchsuchen dieser Repositories auf der Suche nach Secrets ist nicht neu. Tatsächlich entdeckte beispielsweise Aqua Security im Jahr 2021 eine Infrastruktur von 23 Container-Images, die in Docker Hub gespeichert waren und potenziell unerwünschte Anwendungen (PUA) enthielten, die entweder in ihren Image-Schichten versteckt waren oder während der Laufzeit in den instanziierten Container heruntergeladen wurden.

Der unbefugte Zugriff auf Secrets und private Schlüssel hat enorme Konsequenzen. Wenn sie kompromittiert werden, kann dies zur Preisgabe von Kundendaten, zu potenziellen Manipulationen und zu Denial-of-Service-Angriffen führen. Viele dieser kompromittierten Images können potenziell direkten Zugang zu kritischen Diensten bieten, die auch wertvolle Geschäftsdaten enthalten. Dies stellt ein großes Problem dar, da diese Maschinenidentitäten für die Kommunikation zwischen Workloads, Services, physischen Servern usw. verwendet werden. Die Kosten für den Widerruf der Zertifizierungsstelle und die Neuausstellung dieser Identitäten sind enorm, wenn man bedenkt, dass die Anwendungen, die sie verwenden, von IoT, Datenbanken, SIP, E-Mail, SSH und Kubernetes-Clustern reichen.

Letztlich ist das Einbinden von CA-Zertifikaten oder anderen Zertifikaten in ein Image ein Rezept für einen nur schwer aufzudeckenden Sicherheitsvorfall oder ungeplanten Systemausfall. Um zu verhindern, dass diese Images kompromittiert werden, sollten Unternehmen prüfen, ob sie Maschinenidentitäten in Workloads einfügen können, und zwar genau dann, wenn der Workload sie benötigt. Wenn ein Workload gelöscht wird, wird auch das gesamte Schlüsselmaterial gelöscht. Außerdem sollte jedes Container-Image mit einer digitalen Signatur versehen werden, um seine Authentizität und Integrität zu gewährleisten. Hierfür ist jedoch eine Automatisierung unerlässlich. Unternehmen müssen sehr strenge Sicherheitskontrollen einführen, um die Identität von Maschinen zu schützen, und sicherstellen, dass die Entwickler mit der nötigen Automatisierung und klaren Prozessen ausgestattet sind, um Sicherheits- und Schwachstellenprüfungen einzubauen. Der beste Weg, dies zu implementieren, ist eine Kontrollebene, die die Verwaltung von Maschinenidentitäten während ihres gesamten Lebenszyklus automatisiert – von der Durchsetzung von Richtlinien und Governance für verwendete Identitäten bis hin zum Widerruf und Ersatz von Maschinenidentitäten bei Bedarf.