Cyberbedrohungen
Gefahr durch sensible Informationen in Registries
Die Untersuchung der Dateiarten und Informationen in exponierten Registries, auf die böswillige Akteure zugreifen und als Ausgangspunkt für Angriffe nutzen könnten, sowie weitere Schwachpunkte im Konzept, verdeutlichen das bestehende Risiko.
Container Registries mit ihren vertraulichen Informationen sind leider häufig ohne Authentifizierung zugänglich und damit als Angriffsvektor interessant. Wir haben eine erhebliche Anzahl öffentlich zugänglicher Registries entdeckt und die dadurch entstehenden Risiken untersucht. In weiteren Analysen ging es um die Dateiarten und Informationen, auf die böswillige Akteure dort zugreifen und als Ausgangspunkt für Kompromittierungen nutzen könnten.
Container Registries sind vergleichbar mit Bibliotheken, in denen Container-Images gespeichert und katalogisiert werden. Um jedoch besser zu verstehen, wie verschiedene Umgebungen diese Images aus den Registrys abrufen können, muss die Rolle, die die Application Programming Interfaces (APIs) spielen, klar sein. Wenn ein Container gestartet wird, erfolgt eine API-Anfrage an die Registry, um ein Image abzurufen, das sich aus Anwendungsdateien, Umgebungsvariablen, Konfigurationsdateien und Bibliotheken zusammensetzt. Nach dem Abruf wird das Image von der Registry an die Laufzeitumgebung zurückgeschickt, die es zur Erstellung des Containers verwendet.
Bei der Untersuchung der gefundenen exponierten Registries stießen wir auf eine Fülle von sensiblen Informationen. Zunächst fiel auf, dass einige dieser privaten Registries als Versionsverwahrer verwendet wurden: ein Backup zahlreicher Versionen desselben Images für entwickelte Produkte. Für das Durchforsten der Riesendatenmenge in den verschachtelten Archivierungsschichten verwendeten wir zunächst reguläre Ausdrücke, um die Images nach Übereinstimmungen mit Geheimnissen und anderen sensiblen Daten zu durchsuchen. Als Nächstes durchsuchten wir die Container-Images mit einem Tool nach Dateigruppen, die zwar keine direkten Leaks sind, aber möglicherweise die Sicherheit des Containers oder des darauf ablaufenden Projekts gefährden könnten.
Basis-Images bilden das Rückgrat dieser Container: Sie stellen die Kernfunktionen des Betriebssystems bereit und schaffen die Umgebung, in der die containerisierten Anwendungen laufen. Sie spielen auch eine wesentliche Rolle für die Sicherheit, Geschwindigkeit und Leistung der Container. Unter den gefundenen Basis-Images machten Alpine, Debian und Ubuntu mehr als 80 % aus. Es lohnt sich zu prüfen, ob sie die Erstellung sicherer und produktionsfähiger Anwendungen ermöglichen.
Lightweight Alpine wird oft von Entwicklern bevorzugt, die ihre Container schlank halten wollen; dieses Basis Image ist abgespeckt und kompakt und eignet sich am besten für einfache Anwendungen. Das bedeutet aber auch, dass es möglicherweise nicht die Stärke und die Sicherheitsfunktionen hat, die für komplexere und anspruchsvollere Anwendungen erforderlich sind. Anhand der verfügbaren Daten stellten wir fest, dass es sich bei der überwiegenden Mehrheit der Alpine Basis-Images um ältere und möglicherweise anfällige Versionen handelte; zum Zeitpunkt der Erstellung dieses Berichts waren nur 27 Images in der neuesten Version vorhanden.
Andererseits sind die Schwergewichte Debian und Ubuntu größer und können komplexere Anwendungen unterstützen. Doch diese Fähigkeit birgt auch Risiken: Jede zusätzliche Komponente innerhalb eines Basis-Images kann von Bedrohungsakteuren für den Einstieg genutzt werden. Anwendungsentwickler sollten daher hier bei der Verwaltung von Abhängigkeiten vorsichtig sein, um zu verhindern, dass Schwachstellen ausgenutzt werden.
Bemerkenswert auch, dass nur sehr wenige Distroless Images in den offenen Registries zu finden sind. Distroless-Images sind so konzipiert, dass sie sowohl leichtgewichtig als auch sicher sind und nur das Nötigste zum Ausführen einer Anwendung bieten. Sie verzichten auf zusätzliche Komponenten, die ein Image aufblähen, was auch weniger potenzielle Sicherheitslücken bedeutet. Trotz dieser Vorteile, die wir in einer vergleichenden Studie beschreiben, werden Distroless Images offenbar nicht häufig verwendet.
Source Code und sensible Informations-Leaks
Ein weiteres beunruhigendes Ergebnis sind Quellcode-Leaks, ein schwerwiegendes Sicherheitsproblem, das Sicherheitskonfigurationen offenlegt, die es Angreifern ermöglichen könnten, gültige Token oder offene Autorisierungsdaten (OAuth) zu generieren, um unbefugten Zugriff auf Systeme und Daten zu erhalten. Somit könnte sich ein potenzieller Angreifer als Applikationsnutzer ausgeben. Quellcode-Leaks stellen auch ein Geschäftsrisiko dar, da sie proprietäre Algorithmen oder Geschäftslogik offenlegen, die entweder Wettbewerber ausnutzen können oder böswillige Akteure, um den Betrieb zu stören.
Die besorgniserregendste Entdeckung war die Offenlegung sensibler Informationen, einschließlich der Geheimnisse im Dateisystem und der Metadaten von Container-Images, die Umgebungsvariablen mit Hilfe von Umgebungsanweisungen spezifizieren. Dies sind die Arten von sensiblen Daten, die wir in den Images gefunden haben:
- S3-Schlüssel. Diese Schlüssel könnten Angreifern Zugriff auf Cloud-Speicher-Buckets geben, die weitere sensible Daten enthalten oder zum Hosten bösartiger Inhalte verwendet werden könnten.
- CSP-Zugangsschlüssel. Diese Schlüssel könnten einem Angreifer Zugang zu Cloud Service Providern (CSPs) verschaffen und es ihm ermöglichen, Ressourcen auf Kosten des Unternehmens zu erweitern, auf mehr Daten zuzugreifen oder Angriffe von der Cloud-Umgebung des Unternehmens aus durchzuführen.
- Authentifizierungsdaten der Datenbank (DB). Diese Anmeldedaten könnten einem Angreifer Zugang zu Datenbanken verschaffen, was es ihm ermöglichen könnte, Daten zu stehlen, zu ändern oder zu löschen.
- Anmeldedaten für Anwendungen. Diese können einem Angreifer Zugang zu privaten Anwendungen verschaffen, so dass er möglicherweise Aktionen als rechtmäßiger Benutzer durchführen oder auf sensiblere Daten zugreifen kann.
- JSON-Web-Token (JWT). Diese werden häufig zur Authentifizierung verwendet und könnten Angreifern Zugang zu Systemen oder Daten verschaffen.
Der Originalbeitrag beinhaltet eine ausführliche Beschreibung der Dateiarten.
Selbst gehostete versus Cloud Service Registries
Angesichts der Datenmengen stellt sich die Frage, wie Registries gesichert werden können und ob sie selbst oder in Cloud Services gehostet werden sollten. Beide Optionen bieten eine Reihe von Vor- und Nachteilen. Beim Hosten der eigenen Registry haben Sie mehr Kontrolle über den Zugriff, die Speicherung und den Speicherort der Images. Dies bedeutet jedoch auch, dass Sie die Verantwortung für die manuelle Konfiguration der Sicherheit Ihrer Registry und die Wartung des Servers, auf dem sie gehostet wird, tragen. Umgekehrt kann die Nutzung eines Cloud Service bequemer sein, da er die Wartung des Servers übernimmt und mehrere integrierte Sicherheitsfunktionen bietet, wobei der Nachteil darin besteht, dass Sie weniger Kontrolle über die Registry haben.
Das Risiko, das mit Bequemlichkeit einhergeht
Es besteht ein großer Unterschied zwischen dem traditionellen Modell der Bereitstellung von Anwendungen auf separaten Workloads und dem modernen Ansatz der Verwendung von Containern. Dieser kann erhebliche Auswirkungen auf die Sicherheit haben, und das Verständnis dieser Auswirkungen ist entscheidend für jeden, der die Entwicklung, Bereitstellung oder Sicherung von Anwendungen plant.
In einer Infrastruktur ohne Container, in der die Anwendungsdienste in der Regel auf mehrere Workloads verteilt sind, seien es virtuelle Maschinen oder physische Server, wird jeder Dienst in einer eigenen Workload ausgeführt und ist daher von den anderen isoliert. Diese Trennung kann ein gewisses Maß an Sicherheit bieten, da ein Angreifer mehrere Workloads kompromittieren müsste, um Zugang zu allen Diensten einer Anwendung zu erhalten, und erst dann würde er sein Ziel vollständig erfassen können. Das Eindringen in jede einzelne Workload könnte zeitaufwändig sein und ist eine anspruchsvolle Aufgabe, die ein hohes Maß an Fähigkeiten und Ressourcen erfordert.
Mit dem Aufkommen von Containern hat sich dies jedoch drastisch verändert. Entwickler verpacken Anwendungsdienste in eine einzige Einheit, die eine höhere Portabilität, Skalierbarkeit und Effizienz innerhalb einer stabilen Umgebung ermöglicht. Mit ihren Funktionen für die Mehrfachisolierung ist es einfach, Container als standardmäßig sicher zu erkennen. Container werden sogar über spezialisierte Workloads hinaus eingesetzt. Doch während sie viele Vorteile bieten, bringen sie auch Sicherheitsherausforderungen mit sich.
DevOps-Praktiker haben den größten Einfluss auf die Sicherheit von Container-Ökosystemen. Die Verwendung von Containern für die Erstellung von Anwendungen, das feste Codieren von Geheimnissen, die für erfolgreiche Builds erforderlich sind, und das anschließende Einfügen in dieselbe Container-Image-Registry wie das Build-Container-Image haben Folgen. Auf das Build-Container-Image, in dem alle Geheimnisse referenziert sind, sollte idealerweise nur zur Laufzeit zugegriffen werden. Das Image, mit dem die Anwendung erstellt wird, kann jedoch von derselben Container-Image-Registry aus auf die Geheimnisse zugreifen, da sie zusammen gelagert sind. Dadurch kann jeder, der Zugriff auf das Image-Repository hat, auf diese sehr sensiblen Token zugreifen. Unsere Untersuchung ergab zwar, dass die Verweise auf die Geheimnisse innerhalb des Anwendungs-Images sicher implementiert sind, aber die Build-Images enthielten diese Geheimnisse trotzdem.
Zahlreiche Container, die wir in der offenen Registry gefunden haben, wurden für CD/CI-Pipelines verwendet, darunter Zielanwendungen, Builds und Bereitstellungen. Diese erfordern naturgemäß den Zugriff auf Geheimnisse wie Content-Management-System-Software zum Abrufen von Quellcode oder API-Tokens für Repositories sowie den Zugriff auf Cloud-Dienste und Protokollsysteme, um nur einige zu nennen. Diese Geheimnisse sind in den Container-Images über das Dateisystem oder sogar als .env-Direktiven in den Dockerdateien fest kodiert. Das bedeutet, dass sie in den Metadaten des Container-Images gespeichert sind, was dem Speichern in der Datei gleichkommt. Diese stellen ein hohes Risiko für die Offenlegung von Informationen dar, wenn sie in unsichere Container-Registries übertragen werden.
Bei der Verwendung von Containern in der CI/CD-Pipeline sollte der Verwaltung von Geheimnissen besondere Aufmerksamkeit gewidmet werden. Insbesondere können Bedrohungsakteure Schwachstellen in mangelhaften Sicherheitsdesigns von Container-Images ausnutzen, da diese Designs ihnen mühelos Zugang zu den Architekturinformationen der Anwendung und einen erweiterten Angriffsvektor bieten.
Andererseits können exponierte Container-Registries, wenn sie falsch konfiguriert sind, öffentlichen Zugriff auf mehrere Container-Images bieten. Ein Angreifer, der sich Zugang dazu verschafft, kann sie im Detail untersuchen und mehr über die Struktur, die Abhängigkeiten, die Konfiguration und sogar den Quellcode der Anwendung erfahren. Deshalb ist es wichtig, Fehlkonfigurationen zu identifizieren.
Während das traditionelle Modell, jeden Server einzeln zu sichern, in der Welt der Container nicht gilt, kann dieses System nachgeahmt werden, indem Container so gesichert werden, als ob jeder eine vollständige Anwendung mit eigenen Verteidigungsmaßnahmen wäre. Dies beinhaltet die Verschlüsselung von Images, wenn möglich, und die Erstellung von ACLs, Firewalls oder die Kontrolle des Zugriffs über virtuelle private Netzwerke (VPNs).
Fazit
Wir empfehlen folgende Best Practices, um die Sicherheitsrisiken zu mindern:
- Geheimnisse nicht in Dateien innerhalb von Container-Images fest codieren.
- Verwenden Sie Tresore, um Geheimnisse und ihre Referenzen zu speichern.
- Wenn Sie Umgebungsvariablen für Geheimnisse verwenden, speichern Sie diese nicht in Dockerdateien oder .env-Dateien. Geben Sie sie stattdessen zur Laufzeit des Containers ein.
- Stellen Sie sicher, dass Ihre privaten Container-Registrierungen für die Öffentlichkeit nicht zugänglich sind.
- Verschlüsseln Sie Container-Images.
Container-Image-Registries sollten regelmäßig auf Fehlkonfigurationen überprüft und ständig auf Schwachstellen, Malware und Geheimnisse gescannt werden. Für eine leichtgewichtige und sichere Art, Anwendungen auszuführen, sollten Sie ohne Distribution auskommen und einen Secrets-Manager verwenden, um Geheimnisse in Container-Laufzeiten zu integrieren.