Ausnutzung von Schwachstellen
Über Container Registries Angriffe auf Supply-Chain
Container Registries mit ihren vertraulichen Informationen sind leider häufig ohne Authentifizierung zugänglich und damit als Angriffsvektor interessant. Was bedeutet das für die Sicherheit der in der Cloud gehosteten Container und Workloads?
Save to Folio
Wir haben eine erhebliche Anzahl öffentlich zugänglicher Registries entdeckt, also Repositories oder Datenbanken, die bei Cloud Services gehostet werden und deren Informationen ohne Authentifizierung erreichbar sind. Wir konnten die gespeicherten Inhalte erfolgreich herunterladen, einschließlich Images im Wert von über 9 TB und mehr als 20.000 gedumpter Images. Welche möglichen Folgen für die Sicherheit gibt es? Und welche Fallstricke manueller Container-Registry-Implementierungen innerhalb von Cloud-Workloads gibt es, da diese von Natur aus anfälliger für Fehlkonfigurationen sind und einen validen Angriffsvektor für Bedrohungsakteure darstellen.
Container bieten Abschottung, Portabilität und Konsistenz und ermöglichen so eine schnelle Skalierung und effiziente Integration in Cloud-Umgebungen. Mit diesen Vorteilen haben sie das Interesse an Cloud-nativen Technologien gefördert und die Art und Weise, wie viele moderne Anwendungen entwickelt, bereitgestellt und verwaltet werden, grundlegend verändert.
Ein wichtiger Aspekt bei der Arbeit mit Containern ist die Speicherung und Verwaltung der Container-Images, die zur Kapselung von Anwendungen verwendet werden. Cloud-Service-Provider (CSPs) bieten mittlerweile Managed Registry-Services dafür an, die als Image-Repositories fungieren und es Entwicklern ermöglichen, Anwendungen in verschiedenen Umgebungen gemeinsam zu nutzen und bereitzustellen. Darüber hinaus können Unternehmen ihre eigenen Container Image Registries einrichten und betreiben, entweder vor Ort oder innerhalb von Cloud-Computing-Instanzen (wie Amazon EC2).
Container Image Registries
Container Image Registries sind mehr als nur Repositories. Sie sind das Herzstück eines jeden Container-Systems. Hier werden Container-Images gespeichert, die aus statischen Dateien bestehen und Schichten mit vorinstallierten Anwendungen sowie deren Abhängigkeiten und Umgebungseinstellungen enthalten.
Jede Schicht eines Container-Images repräsentiert eine Änderung des Images, wie das Hinzufügen einer Datei oder eine Änderung der Konfiguration. Diese Schichten werden übereinander gestapelt und bilden das endgültige Image. Bei der Aktualisierung eines Images werden nur die geänderten Schichten aktualisiert, was die Verwendung von Container-Images effizient macht.
Die Erstellung eines Containers beginnt in der Regel mit der Erstellung eines Images für eine Anwendung. Dieser Prozess umfasst die Kompilierung des Anwendungscodes, die Bündelung mit den erforderlichen Abhängigkeiten und die Konfiguration der Laufzeitumgebung. Das resultierende Image ist ein eigenständiges, ausführbares Paket, das alles enthält, was zur Ausführung einer Anwendung erforderlich ist.
Dann wird das Image in eine Registry (ein privates oder öffentliches Repository) eingestellt. CSPs können je nach Bedarf und Konfiguration einen oder beide Services als Managed Service anbieten. Benutzer entscheiden selbst, wie sie den Zugang zu den Registries konfigurieren wollen (selbst öffentliche Repositories schränken ein, wer Änderungen vornehmen oder Images hochladen darf), und sie sind auch dafür verantwortlich, mögliche sensible Inhalte zu filtern, bevor sie in das Repository eingestellt werden.
Die Registry fungiert als Verteilungsstelle, die das Image speichert und bei Bedarf abrufen kann. Dies ist ein entscheidender Aspekt des Lebenszyklus von Containern, da er sicherstellt, dass verschiedene Versionen von Anwendungen konsistent und zuverlässig in verschiedenen Umgebungen bereitgestellt werden können.
Das in der Registry gespeicherte Image kapselt die Anwendung und alle ihre Software-Abhängigkeiten. Das bedeutet, dass die Anwendung unabhängig von der Umgebung, in der sie bereitgestellt wird, auf die gleiche Weise ausgeführt wird. Möglich wird das durch die Verwendung von Container-Image-Registries.
Wenn ein Container gestartet wird, wendet sich das System an die Registry, um das erforderliche Container Image zu erhalten. Dieses Image wird dann verwendet, um einen laufenden Container auf dem Hostsystem zu instanziieren. Aus diesem Grund sind die Sicherheit und Zuverlässigkeit der Registry von größter Bedeutung. Ist eine kompromittiert, kann dies zur Bereitstellung kompromittierter Images führen mit weitreichenden Auswirkungen auf die Sicherheit.
Die Rolle einer Registry geht jedoch über die reine Speicherung hinaus. Sie ermöglicht auch die Speicherung mehrerer Image-Versionen und das Tracking von Image-Varianten mithilfe von Tags. So kann ein Entwickler beispielsweise verschiedene Images für Entwicklungs-, Test- und Produktionsumgebungen mit jeweils leicht unterschiedlichen Konfigurationen haben. Die Registry kann die Nachverfolgung all dieser Varianten leisten und ermöglicht es den Entwicklern, bei Bedarf das passende Image zu nehmen.
Die Nutzung Cloud-basierter Services birgt jedoch auch Sicherheitsrisiken. Wenn beispielsweise ein böswilliger Akteur Schreibzugriff auf Container Image Registries erhält oder die Möglichkeit hat, Images zu pushen, kann er potenziell bösartigen Code in das Image einschleusen und das ursprüngliche Image innerhalb der Registry ersetzen. Erhält er hingegen Lesezugriff auf eine Registry, die eigentlich privat sein sollte, kann er die Images abrufen und sensible Informationen für seine Zwecke missbrauchen. Darum muss nicht nur die Registry selbst, sondern auch die einzelnen darin gespeicherten Images geschützt werden.
Unsere Untersuchung öffentlich zugänglicher Repositories hat gezeigt, dass eine beträchtliche Anzahl von ihnen bei Amazon Web Services (AWS) gehostet wird. Wir konnten sowohl eine Verbindung zu diesen Registries herstellen als auch ihre Inhalte herunterladen (9,31 TB Images, 197 ausgelagerte eindeutige Registries, 20.503 Image-Dumps), ohne Authentifizierung oder Brute-Force-Methoden zu verwenden.
Wir stellten außerdem fest, dass die Eigentümer nicht nur einzelne Benutzer und kleinere Unternehmen waren. Vielmehr befanden sich einige im Besitz privater Organisationen ohne andere öffentliche Container- oder Code-Sharing-Projekte.
Die Risiken von öffentlich zugänglichen Registries
Die potenziellen Auswirkungen eines uneingeschränkten Zugriffs lassen sich auf zwei Szenarien herunterbrechen. Erstens können alle in den Images gespeicherten geschützten oder sensiblen Daten wie API-Schlüssel, Anmeldeinfos und mehr öffentlich werden. Zweitens könnte ein böswilliger Akteur mit Schreibzugriff auf eine öffentlich zugängliche Registry ein kompromittiertes Image dorthin übertragen. Es könnte bösartigen Code enthalten, z. B. eine Backdoor, einen Cryptocurrency Miner oder sogar Ransomware. Auf jedem System, das dieses Image abruft, würde dann möglicherweise bösartiger Code ausgeführt, wodurch sich die Bedrohung über die gesamte Infrastruktur ausbreitet. Die Folgen wären unter Umständen Datendiebstahl und Systemunterbrechungen bis hin zu einem Ransomware-Angriff. Da die heutigen Software Supply Chains miteinander vernetzt sind, kann sich zudem ein kompromittiertes Image an einem Ort schnell auf andere Systeme und Organisationen übertragen.
Absicherung von Container-Image-Registries
- Authentifizierungsmaßnahmen: stellen sicher, dass nur autorisierte Benutzer auf die Registry zugreifen. Dies kann durch herkömmliche Benutzernamen und Passwörter, API-Schlüssel oder digitale Zertifikate geschehen. Eine robuste Authentifizierungsimplementierung ist die erste Verteidigungslinie gegen den unbefugten Zugriff auf die Registry. Ein angemessenes Identitätslebenszyklusmanagement für Benutzer sollte ebenfalls vorhanden sein, vom Onboarding (Erstellen einer neuen digitalen Identität und Ermöglichen des Zugriffs auf Ressourcen) bis zum Offboarding (Beenden des Zugriffs auf Ressourcen, wenn der Benutzer die Organisation verlässt). Des Weiteren ist auch das Prinzip der geringsten Privilegien als grundlegende Sicherheitspraxis wichtig. Dieser Grundsatz besagt, dass Benutzer nur die Zugriffsrechte erhalten sollten, die sie für die Ausführung ihrer Arbeit benötigen. Im Zusammenhang mit einer Registry könnte dies bedeuten, dass man einschränken sollte, wer Images pushen oder abrufen kann, oder wer bestehende Images löschen oder ändern darf.
- Scannen von Images auf Schwachstellen: Regelmäßiges Scannen von Images auf Schwachstellen kann dazu beitragen, bekannte Schwachstellen in den in Images enthaltenen Software-Abhängigkeiten zu erkennen. Es gibt verschiedene Tools, die diesen Prozess automatisieren können. Sie scannen Images, sobald sie in die Registrierung übertragen werden, und warnen die Benutzer vor möglichen Problemen. Dazu gehören nicht nur Schwachstellen, sondern auch hart kodierte sensible Daten, die zusammen mit dem Image geleakt werden könnten.
- Verschlüsselung von Daten At-Rest und bei der Übertragung: Es gibt verschiedene Methoden und Tools zur Verschlüsselung von Daten, und die beste Wahl hängt von den spezifischen Bedürfnissen des Benutzers und der gesamten Umgebung ab.
- Regelmäßiges Aktualisieren und Patchen der Registry: Die Implementierung von Updates und Patches in regelmäßigen Abständen bietet nicht nur neue Funktionen, sondern behebt auch ausnutzbare Schwachstellen und andere Sicherheitsprobleme. Bei Managed Container-Registry Services kümmert sich der CSP um das Patching und die zugrunde liegende Konfiguration.
- Implementierung von Firewall-Regeln: Firewall-Regeln dienen dazu, unerwünschte Verbindungen zum Service zu blockieren, Authentifizierungseinstellungen zu konfigurieren, Verschlüsselung zu aktivieren und das System kontinuierlich zu überwachen.
- Bereitstellung einer verwalteten Quelle für vertrauenswürdige Container: Durch die logische Zentralisierung der Quellen für diese Komponenten und ihre Abhängigkeiten bietet sich den Sicherheitsteams die Möglichkeit, die Eigenschaften der Komponenten vor der Integration zu bewerten. Darüber hinaus verringert diese Anordnung die Wahrscheinlichkeit unerwarteter Probleme, wie sie beispielsweise bei Änderungen an bestehenden Paketen auftreten können.
- Verwendung geheimnisloser Container: Container ohne Geheimnisse bieten eine sicherere und effizientere Methode für den Umgang mit sensiblen Informationen. Indem sie die Verwaltung von Geheimnissen von den Anwendungen abstrahieren, verringern sie das Risiko eines unbefugten Zugriffs auf kritische Daten.
Fazit
Der Schutz von Container Image Registries ist ein kritischer Aspekt der Containersicherheit, der für die gesamte DevOps-Umgebung und die zugehörige Infrastruktur von entscheidender Bedeutung ist. Bei dem Problem der exponierten Registries spielen Fehlkonfigurationen eine große Rolle. Obwohl dies im Vergleich zu anderen Arten von Sicherheitslücken wie ein geringes Sicherheitsproblem erscheinen mag, sollte es mit großer Sorgfalt behandelt werden, insbesondere in einer Zeit der Cloud-Technologien.
Die Sicherheit in der Cloud unterliegt in der Regel dem AWS-Modell der geteilten Verantwortung, das einen kooperativen Ansatz fördert, indem es die Stärken des Cloud-Anbieters (über die Infrastruktur und die Technologien) nutzt und sich gleichzeitig darauf verlässt, dass der Benutzer eine robuste und sichere Cloud-Umgebung aufbaut (wozu auch die ordnungsgemäße Konfiguration der Cloud-Assets gehört). Kurz gesagt, dieses Modell beruht darauf, dass beide Parteien effektiv zusammenarbeiten, um eine sichere und zuverlässige Cloud-Infrastruktur zu erhalten.
Bei der Implementierung einer privaten Registry sollten die folgenden Sicherheitsfragen gestell werden:
- Ist es notwendig, einen privaten Registry-Service einzurichten?
- Soll dieser Service vor Ort oder in der Cloud betrieben werden? Wenn er in der Cloud angesiedelt werden soll, ist sich die Organisation über die Kompromisse zwischen einem verwalteten Service und der Übernahme der vollen Verantwortung für den Betrieb eines Registers im Klaren?
- Wer kann auf die Registry zugreifen und wie? (d. h. über ein internes Netzwerk, ein Remote-Netzwerk mit Firewall-Regeln oder über ein Remote-Netzwerk mit virtuellem privatem Netzwerk-Zugang)?
- Werden in den Containern sensible oder geschützte Daten gespeichert? Wenn ja, würde sich die Verschlüsselung solcher Daten negativ auswirken?
- Enthalten die Images der Container unnötige Geheimnisse?