APT und gezielte Angriffe
Risiken in Cloud-nativen Metriken
Container Advisor (cAdvisor) ist ein in Cloud Services verbreitetes Open Source-Überwachungstool für Container. Falsch konfigurierte Bereitstellungen können jedoch versehentlich sensible Informationen wie Metriken preisgeben. Wo liegen die Risiken?
Save to Folio
Wie alle Umgebungen erfordern auch Cloud-native Umgebungen eine ständige Überwachung der bereitgestellten Dienste, vor allem wegen ihrer komplexen und flüchtigen Natur. Beobachtbarkeit ist die Fähigkeit, den aktuellen Zustand eines Systems zu einem bestimmten Zeitpunkt anhand der generierten Daten wie Protokolle, Metriken und Abläufe (Traces) zu beurteilen. Metriken spielen eine sehr wichtige Rolle, insbesondere für Site Reliability Engineers (SREs) und Security Operations (SecOps)-Teams, um das „Was und Wann“ von Aktivitäten in ihren Umgebungen herauszufinden.
Der Cloud Native Computing Foundation (CNCF) zufolge umfasst Monitoring „alles von der Überwachung des Festplattenspeichers, der CPU-Nutzung und des Speicherverbrauchs auf einzelnen Knoten bis hin zur Durchführung detaillierter synthetischer Transaktionen, um festzustellen, ob ein System oder eine Anwendung korrekt und zeitnah reagiert“. Die CNCF fördert eine Vielzahl diesbezüglicher Projekte.
Prometheus etwa ist ein solches von der CNCF gefördertes Projekt, das in bestimmten Zeitabständen Metriken von Umgebungen sammelt, Regelausdrücke auswertet, Ergebnisse anzeigt und Warnungen auslöst, wenn bestimmte Bedingungen festgestellt werden. Metriken spielen eine wichtige Rolle, wenn es darum geht zu verstehen, warum eine Anwendung auf eine bestimmte Weise funktioniert.
Angenommen ein Anwender stellt fest, seine Webanwendung läuft langsam. Um herauszufinden, was mit der Anwendung passiert, benötigt er einige Informationen. Zum Beispiel könnte die Anwendung langsam laufen, wenn es eine hohe Anzahl von Anfragen gibt. Verfügt er über die Metrik für die Anzahl der Anfragen, kann er feststellen, ob der Grund für die langsame Leistung viele Anfragen sind, und die Anzahl der Server erhöhen, um die Last zu bewältigen.
Prometheus bezieht Metriken von Prometheus-Zielen, die aus Jobs und Exportern bestehen. Exporter sind Bibliotheken und Server, die beim Exportieren vorhandener Metriken aus Drittsystemen helfen. Prometheus unterstützt über 200 Exporter, die Datenbanken, Hardware, Issue-Tracker, Messaging-Systeme, Speicher, HTTP-Server, APIs und Protokollierungslösungen abdecken. Die Daten werden durch eine Reihe von Regeln verarbeitet, um Warnungen auszulösen. Außerdem können sie über eine Web-Benutzeroberfläche (UI) und Projekte wie Grafana abgefragt und visualisiert werden. Im Allgemeinen wird davon ausgegangen, dass diese Metriken gutartige Informationen über eine Umgebung enthalten.
Cure53 hatte 2018 über Pen-Tests diese Schwachstelle als PRM-01-002 identifiziert, was das Prometheus-Team als erwartetes Verhalten ansah. 2022 untersuchten Forscher von Sysdig die Risiken der exponierten Prometheus-Instanzen. Seitdem ist sich die Community der Risiken bewusst, die mit der Veröffentlichung von Prometheus-Dashboards im Internet verbunden sind. Doch was können Angreifer tun, wenn der Metrik-Endpunkt eines Exporters selbst offengelegt wird? 2016 wurde in einem Sicherheitsblog erörtert, wie offene Ports die Netzwerk-Angriffsfläche von cAdvisor erweitern können. Welches sind die potenziellen Risiken von anfälligen cAdvisor-Konfigurationen, die Benutzer beachten sollten?
cAdvisor
cAdvisor, kurz für Container Advisor, ist ein von Google entwickeltes in Golang geschriebenes Open Source-Tool zur Container-Überwachung. Es läuft als Daemon, der Informationen über laufende Container sammelt, aggregiert, verarbeitet und exportiert. Öffentlichen Informationen und unseren Erkenntnissen zufolge wird cAdvisor unter anderem in Kubelets, dem Azure Machine Learning Service und AKS sowie in verschiedenen anderen Services eingesetzt, bei denen ein Container-Monitoring erforderlich ist.
Benutzer können entweder der offiziellen Prometheus-Anleitung folgen, um eine Überwachungslösung für Docker-Container mit cAdvisor einzurichten, oder es als eigenständige Binärdatei auf ihrem Linux-Host ausführen.
Welches sind die exponierten cAdvisor-Endpunkte? Wenn cAdvisor in der Standardkonfiguration ausgeführt wird, gibt es die folgenden Informationen auf Port 8080 preis:
Web UI: Nutzer erreichen es über Port 8080. Hier finden sich Informationen wie Speichergrenzen pro cgroup, CPU-Nutzung in Echtzeit, Netzwerk-E/A in Echtzeit, Dateisystemauslastung in Echtzeit, Docker-Version, Docker-API-Version, Kernel-Version, Version des Betriebssystems, Host-Name sowie eine Liste aller Container-Images.
Darüber hinaus legt Web-UI die Liste aller Container-Images auf dem Host offen, unabhängig davon, ob der auf dem Image basierende Container läuft oder gestoppt ist. Diese Erkenntnis ist besonders interessant, da die Liste der Container-Images weder über die REST-API abgerufen werden kann, noch über die Web-UI sichtbar ist, es sei denn, ein Benutzer inspiziert die Webressourcen manuell.
REST APIs: Die Schnittstelle nutzt die APIs, um Informationen zu holen wie Anzahl der Kerne, RAM-Kapazität, Speicherkapazität, Kernel-Version, Version des Betriebssystems, Cloud-Anbieter, Container-Namen, Liste aller cgroups unter jedem vom System überwachten Service und weitere. Aus Angreifersicht können diese Infos für Erkundungen auf einem Ziel genutzt werden, um festzustellen, ob es für eine Attacke interessant ist.
Umgebungsvariable in „/metrics“
Unter den verschiedenen Laufzeitoptionen, die man mit cAdvisor verwenden kann, fällt eine Option env_metadata_whitelist: auf. Es handelt sich um eine Liste von Umgebungsvariablenschlüsseln, die für Container gesammelt werden müssen. Derzeit unterstützt diese Liste nur containerd und Docker-Laufzeiten. Wir konnten folgendes feststellen:
- Es gibt eine Funktion zur Protokollierung von Umgebungsvariablen im Metrik-Endpunkt.
- Eine Diskrepanz in der REST-API und der Web-UI führt dazu, dass alle Namen von Container-Images auf dem Host angezeigt werden, unabhängig davon, ob der erstellte Container überhaupt existiert.
- Es können verschiedene Informationen über den Host und die laufenden Container eingesehen werden.
Darüber hinaus kann auf der Web-UI nur eine HTTP-Basis- oder Digest-basierte Authentifizierung eingerichtet werden, was bedeutet, dass die REST-API und der Metrik-Endpunkt in einer Standardkonfiguration ohne jegliche Authentifizierung offengelegt würden.
Angesichts der Menge an Informationen, die in Standard- und spezifischen Konfigurationen offengelegt werden, wollten wir nicht-intervenierende Scans in realen Implementierungen durchführen, um zu überprüfen, ob die öffentliche Verfügbarkeit von cAdvisor problematisch ist oder nicht. Wie bei unsicheren Standardkonfigurationen stellten wir die Preisgabe sensibler Informationen fest.
Exponierte cAdvisor
Um exponierte cAdvosors-Instanzen zu finden, begrenzten wir die Suchergebnisse auf der Grundlage der Offenlegung der Web-Benutzeroberfläche. Der Titel der Webseite, „cAdvisor - /“, kann verwendet werden, um nach sichtbaren cAdvisor-Instanzen zu suchen, und wir erstellten Abfragen für die Suche in Suchmaschinen wie Shodan.
cAdvisor REST APIs exponieren den Cloud Provider, auf dem cAdvisor betrieben wird. Weitere Informationen zu Erkenntnissen bezüglich der Versionen, Anzahl der Kerne, Speicherkapazität, Umgebungsvariablen oder Zugangsdaten beinhaltet der Originalbeitrag.
Auswirkungen
Nach Einschätzung der Risiken solcher Offenlegungen könnten remote, nicht authentifizierte Angreifer die folgenden Aktionen durchführen:
- Erkundung. Die Offenlegung von Informationen über das zugrunde liegende Host-Betriebssystem, die Kernel-Version, die Speicherkapazität, die Docker- und cAdvisor-Versionen, die laufenden Prozesse (Ausgabe des Befehls „ps“), den Cloud-Anbieter (AWS, GCP, Azure), die Anzahl der Kerne, die laufenden Dienste sowie die Netzwerk- und Festplatten-E/A könnten es Angreifern erleichtern, die Umgebung besser zu verstehen und einzuschätzen, ob das Ziel sich lohnt.
- Laterale Bewegungen und Erhöhung der Privilegien über Metriken, die Umgebungsvariablen leaken. Wenn die Benutzer die Option verwenden, um Umgebungsvariablen als Metriken zu protokollieren, könnten diese möglicherweise Umgebungsvariablen mit sensiblen Informationen wie AWS-Anmeldeinformationen, Postgres/MySQL/Grafana-Administratorpasswörtern und API-Schlüsseln preisgeben (wie in der Praxis beobachtet). Diese könnten dazu verwendet werden, sich zunächst Zugang zu verschaffen, sich nach der Kompromittierung lateral in der Umgebung zu bewegen und die Privilegien zu erweitern.
- Kompromittierte Supply-Chains durch fehlkonfigurierte Container Registries. Wenn nicht authentifizierte Angreifer die Liste aller Container-Images auf dem Host einsehen, können sie auch öffentlich erreichbare Container-Registries untersuchen. Wenn diese falsch konfiguriert sind (anonyme Pulls zulassen, falsch konfigurierte ECR-Repositories und schwache Anmeldeinformationen haben), könnte die Supply Chain, angefangen vom Container Image bis hin zur bereitgestellten Anwendung, beschädigt werden.
- Ausnutzung von Schwachstellen über Container Images. Wenn Angreifer ausnutzbare Funktionen oder Schwachstellen (bekannte oder unbekannte) in den verwendeten Container Images ausfindig machen, könnten sie potenziell Exploits entwickeln und erfolgreiche Angriffe durchführen, die vom ersten Zugriff über laterale Bewegungen bis hin zur Ausweitung von Berechtigungen reichen.
Wir haben unsere Erkenntnisse bezüglich der öffentlichen Einsehbarkeit in einer unsicheren Standardkonfiguration über die Zero Day Initiative (ZDI) an Google weiter gegeben. Die Information dazu hat das Unternehmen im Januar in der cAdvisor GitHub Dokumentation veröffentlicht.
Sicherheitsmaßnahmen
Um cAdvisor-Instanzen sicher zu gestalten, empfehlen wir die folgenden Sicherheitsmaßnahmen:
Um die Angriffsfläche zu reduzieren sollten folgende Optionen angewendet werden:
- Aktivieren von HTTP basic- oder digest-basierter Authentifizierung beim Web UI (--http_auth_file,
--http_auth_realm, --http_digest_file, and --http_digest_realm). - Deaktivieren der nicht erforderlichen Metriken (--disable_metrics).
- Ändern des Default Ports von 8080 auf einen anderen (--port).
- Nutzung eines angepassten Metrics-Endpunkts (--prometheus_endpoint).
Sofern die Veröffentlichung von Metriken über das Internet nicht bereits in im Bedrohungsmodell berücksichtigt ist, sollten Sie Metriken nicht öffentlich zugänglich machen. Der Schutz des Metrik-Endpunkts ist ebenso wichtig wie der Schutz der Prometheus-Dashboards und der Schutz Ihrer lokalen und cloudbasierten Umgebungen vor solchen Risiken.