Kubernetes gefährdet

Unternehmen setzen auf Kubernetes und Container als Wachstumsmotor für ihre digitale Innovation und Transformation. Schnelle Anwendungsentwicklung und -freigabe, rasche Fehlerbehebungen und erhöhte Geschwindigkeit sind drei der am häufigsten genannten Vorteile der Containerisierung. Wenn allerdings die Sicherheit vernachlässigt wird, kann das den größten Vorteil der Containerisierung – die Agilität – zunichtemachen.

Mehr als die Hälfte der Umfrageteilnehmer in einer Studie von Red Hat (55 %) mussten schon einmal den Rollout einer Anwendung aufgrund von Sicherheitsbedenken verzögern. Der Rollout einer Anwendung, die eine Sicherheitsprüfung nicht bestanden hat, setzt das Unternehmen einem erheblichen Risiko aus.

Um Verzögerungen bei der Anwendungsbereitstellung zu vermeiden und die die Vorteile von Containern und Kubernetes zu nutzen, müssen Unternehmen müssen Unternehmen die Sicherheit in die Entwicklungsphase einbauen.

Neue Analyse von Palo Alto Networks

Zwischen Oktober 2020 und Februar 2021 scannten und analysierten Forscher von Palo Alto Networks regelmäßig ungesicherte Kubernetes-Cluster im Internet. Kubernetes-Cluster können und sollten für mehr Sicherheit konfiguriert werden, aber wenn sie ungesichert bleiben, können diese Cluster von jedem, der ihre IPs, Ports und APIs kennt, anonym angesprochen werden. Die Security-Analysten identifizierten 2.100 ungesicherte Kubernetes-Cluster, die aus 5.300 Knoten, 31.340 CPUs und 75.270 Pods bestehen. In diesen ungesicherten Clustern wurde eine breite Palette von Anwendungen gesehen, die von Unternehmen aus Bereichen wie E-Commerce, Finanzen und Gesundheitswesen betrieben werden. Die reichlich vorhandenen Rechenressourcen und die große Menge an sensiblen Daten in den Anwendungen – wie API-Token, Datenbankanmeldeinformationen, Quellcode und personenbezogene Daten – machen diese ungesicherten Cluster zu attraktiven Zielen für Angreifer. Der größte Cluster, auf den die Forscher stießen, hatte mehr als 500 Knoten und 2.000 aktive Pods.

Palo Alto Networks entdeckte Malware und bösartige Aktivitäten in einigen dieser ungesicherten Kubernetes-Cluster. Während der meiste von uns beobachtete Schadcode in Pods als Container läuft, wird ein Teil direkt auf dem Host bereitgestellt. Jede containerisierte Anwendung läuft in einem isolierten Arbeitsbereich (Namespace) mit anderen Prozess-IDs, Netzwerken und Dateisystemen als alle anderen Anwendungen. Wenn Malware die Isolierung umgeht und auf die Ressourcen des zugrundeliegenden Hosts zugreift, stellt sie auch ein Risiko für die Cloud-Umgebung dar, die den Cluster hostet. Mit dieser Zugriffsebene zeigten die Forscher, dass weitere laterale oder vertikale Bewegungen möglich sind, einschließlich der Extraktion von Anmeldeinformationen, der Kompromittierung von Registrierungen und dem Zugriff auf die Daten und das Netzwerk des Hosts.

Ungesicherte Kubernetes-API-Server und ungesicherte Docker-Daemons haben viel gemeinsam. Wenn sie falsch konfiguriert sind, können Angreifer die offengelegten APIs, die dort laufen, ausnutzen, um die gesamte Container-Plattform zu kontrollieren. Unsere früheren Untersuchungen haben zahlreiche bösartige Aktivitäten in ungesicherten Docker-Daemons identifiziert (Beispiele sind Graboid, Cetus und Pro-Ocean). Interessanterweise haben wir, obwohl wir ähnliche Untersuchungen durchgeführt haben, nicht so viele bösartige Aktivitäten in Kubernetes gesehen wie in Docker.

Trotz des scheinbar geringeren Niveaus bösartiger Aktivitäten in ungesicherten Kubernetes-Clustern könnten Angreifer, die dort operieren, Zugang zu wertvolleren Zielen erhalten. Da ein kompromittierter Kubernetes-Cluster über viel mehr Ressourcen (CPU, Speicher und Netzwerk) und Anwendungsdaten verfügen kann, kann ein fähiger Angreifer leicht Command-and-Control-Server (C2) hosten, ein Botnet aufbauen oder sensible Daten stehlen. Unit 42 glaubt, dass es bald mehr Angreifer geben wird, die auf ungesicherte Kubernetes abzielen oder diese nutzen.

Fehlkonfigurierte Kubernetes-Komponenten

Kubernetes ist eine hochkomplexe Plattform, die aus mehreren Schichten und Komponenten besteht. Der modulare Aufbau macht Kubernetes flexibel und skalierbar, da die meisten Komponenten individuell konfiguriert oder ausgetauscht werden können, um ein bestimmtes Ziel zu erreichen. Die Komplexität macht es jedoch auch zu einer Herausforderung, die Plattform richtig abzusichern. Eine einzige Fehlkonfiguration kann zu kompromittierten Containern oder sogar kompromittierten Clustern führen, wie im nächsten Abschnitt gezeigt wird.

Die folgende Analyse befasst sich mit zwei Kubernetes-Komponenten, kube-apiserver (API Server) und kubelet. Beide laufen als RESTful-API-Server und nehmen Anfragen entgegen, die die zugrundeliegenden Container verwalten. Die Forscher von Palo Alto Networks konzentrieren uns auf diese beiden Komponenten, da sie in allen Kubernetes-Plattformen vorhanden sind und bei Fehlkonfiguration zu einer Kompromittierung des Hosts führen können. Die Forscher analysieren Kube-APIServer und Kubelets im Internet, auf die ohne Authentifizierung zugegriffen werden kann.

Gefährliche Aktivitäten in ungesicherten Kubernetes-Clustern

Ungesicherte Kubernetes-Cluster sind anfällig für alle Arten von Angriffen. Unter ihnen ist Kryptojacking, bei dem Angreifer bösartige Kryptominers in kompromittierten Containern einsetzen, immer noch der am häufigsten beobachtete Angriff. Die von uns beobachtete Kryptojacking-Malware wurde entweder als neuer Container bereitgestellt oder innerhalb eines gekaperten Containers gestartet. Sobald sie Zugriff auf einen Container erlangt hat, versucht manche Malware auch, sich seitlich oder vertikal zu bewegen. Durch eine seitliche Bewegung können Angreifer mehr Container oder Anwendungen kontrollieren, während eine vertikale Bewegung es Angreifern ermöglicht, den Host oder sogar die Cloud-Umgebung zu kontrollieren, in der die Cluster bereitgestellt werden.

Bereitstellen von gefährlichen Containern

Das Bereitstellen von Container-Images, die Malware enthalten, ist eine gängige Methode, um einen Angriff auf eine Container-Plattform zu starten. Da Container im Allgemeinen betriebssystemunabhängig sind, kann eine containerisierte Malware problemlos in jeder Umgebung ausgeführt werden. Öffentliche Container-Registrierungsstellen wie Docker Hub and Quay vereinfachen zudem das Hosten und Bereitstellen von bösartigen Containern. Frühere Untersuchungen haben zahlreiche bösartige Images in Docker Hub aufgedeckt (siehe frühere Untersuchungen zum Auffinden bösartiger Cryptojacking-Images in Docker Hub; Taktiken, Techniken und Vorgehensweisen von Angreifern in ungeschützten Docker-Daemons; und Verwendung von Docker-Images zum Mining von Monero).

Dennoch können auch gutartige Container-Images für bösartige Zwecke missbraucht werden. Legitime Container-Images wie Ubuntu oder Centos können in nicht autorisierten Umgebungen eingesetzt werden, die für die Ausführung von Malware umfunktioniert werden. Die meisten Container-Plattformen vertrauen standardmäßig auf diese offiziellen Images. Tabelle 1 zeigt drei Angriffe, die offizielle Docker Hub-Images nutzen, um Malware zu erstellen und auszuführen. Jeder dieser Angriffe wurde in Hunderten von ungesicherten Kubernetes-Clustern beobachtet.

Es gibt viele legitime Cryptocurrency-Mining-Tools, die in Docker Hub veröffentlicht werden. Krypto-Hobbyisten lassen diese Container oft laufen, um an einem Mining-Netzwerk teilzunehmen. Die gleichen Images können jedoch auch missbraucht werden. Tabelle 2 zeigt, wie ein Angreifer Kryptojacking-Operationen mit XMRig, einem Monero-Mining-Tool, durchführt. Das Image wurde als DaemonSet bereitgestellt, sodass jeder Arbeitsknoten mindestens eine Instanz des Containers ausführt und Pods automatisch neu geplant werden, wenn ein Knoten dem Cluster beitritt oder ihn verlässt. Um die bösartigen Prozesse zu verschleiern, benannte der Angreifer das DaemonSet als „Kube-controller“ und stellte es im kube-system-Namensraum bereit. kube-system-Namensraum wird normalerweise nur für Objekte verwendet, die vom Kubernetes-System erstellt werden. Wenn ein Administrator die laufenden Pods und Daemons überprüft, kann dieser bösartige Container aufgrund seines verschleierten Namens leicht übersehen werden.

Starten von bösartigen Prozessen in gekaperten Containern

Es ist möglich, Remote Code Execution (RCE) in einem laufenden Container über ungesicherte API-Server oder Kubelets durchzuführen. Die exec-API des API-Servers und die run-API von Kubelet ermöglichen es Angreifern, beliebige Befehle in Containern auszuführen. Das Starten eines gefährlichen Prozesses in einem gekaperten Container ist unauffälliger, da er keine neuen Images ziehen oder neue Container ausführen muss. Container-Schwachstellen-Scanner oder statische Analyse-Tools können diese Art von Angriff nicht erkennen.

In einer kürzlich durchgeführten Untersuchung deckten die Forscher von Palo Alto Networks eine Kryptojacking-Malware namens Hildegard auf, die auf falsch konfigurierte Kubernetes-Cluster abzielte. Der Angreifer kompromittierte den ersten Container über ein dem Internet zugewandtes und ungesichertes Kubelet. Anschließend bewegte er sich seitlich zu anderen Knoten innerhalb des Clusters und entführte mehrere Container. In jedem kompromittierten Container versuchte die Malware, einen IRC-Kanal zurück zu einem C2-Server aufzubauen und einen bösartigen Cryptominer zu starten. Böswillige Miner, die in laufende Container injiziert werden, haben jedoch eine kürzere Lebensdauer, da Container häufig neu gestartet oder umdisponiert werden können. Die bösartigen Miner können nach einem Neustart der Host-Container nicht bestehen bleiben.

Mögliche Angriffe gegen ungesicherte Kubernetes

In den vorherigen Abschnitten haben die Forscher ihre Erkenntnisse in ungesicherten Kubernetes-Clustern gezeigt. In diesem Abschnitt werden einige mögliche Angriffe beschrieben, die auch in solchen ungesicherten Umgebungen auftreten können. Die Forscher definieren zunächst den initialen Zugriff für jeden möglichen Angriff und zeigen, wie ein Angreifer den initialen Zugriff ausnutzen kann.

• Übermäßig freizügige Fähigkeiten. Jedem Container wird eine Teilmenge von Fähigkeiten gewährt, die von den Anforderungen der Anwendung abhängen. Wenn eine Anwendung beispielsweise eine Verbindung zu einem privilegierten Port (Portnummer unter 1024) herstellen muss, muss ihr die cap_net_bind_service-Fähigkeit gewährt werden, und wenn eine Anwendung ein ICMP-Paket senden muss, benötigt sie die cap_net_raw-Fähigkeit. Fähigkeiten wie cap_sys_module oder cap_sys_admin gewähren hoch privilegierte Rechte und erlauben Containern den Zugriff auf die Kernel-Module des Hosts. Wenn ein Container mit diesen Fähigkeiten kompromittiert wird, können Angreifer leicht Zugriff auf den Host erlangen.
• Gemeinsam genutzte Namespaces. Eine containerisierte Anwendung kann in einer Sandbox-Umgebung laufen, weil jede Ressource des Containers, wie Prozesse, Netzwerk und Dateisystem, in isolierten Namespaces untergebracht ist. In manchen Fällen muss ein Container seine Namespaces mit anderen Containern oder dem Host teilen. Wenn ein Container zum Beispiel den Netzwerkverkehr des Hosts erfassen muss, muss er im Netzwerk-Namensraum des Hosts laufen. Dieser gemeinsam genutzte Namespace stellt einen Kanal für Angreifer dar, um vom Container auf den Host zu gelangen.
• Ungepatchte Sicherheitslücken. Ungepatchte Container-Laufzeit oder Knoten-Betriebssysteme stellen ein Risiko für einen Container-Ausbruch dar. Containerisierte Anwendungen werden von der Container-Laufzeitumgebung geplant und verwaltet. Schwachstellen in der Container-Laufzeit, wie CVE-2019-5736, können es Anwendungen ermöglichen, aus den Containern auszubrechen. Da Container den Betriebssystem-Kernel des Hosts gemeinsam nutzen, können die meisten Kernel-Exploits zu einer Privilegienerweiterung führen und einen Container-Ausbruch ermöglichen.
• Gestohlenes Dienstkonto-Token. Service-Account-Token befinden sich in Containern und werden von Anwendungen zur Authentifizierung bei API-Servern verwendet. Wenn sie gestohlen werden, können sich Angreifer als die Anwendungen ausgeben und API-Server ausnutzen, um sich lateral oder vertikal zu bewegen.
• Gestohlene Cloud-Konto-Anmeldeinformationen. Angreifer können über kompromittierte Anwendungen oder Container auf Cloud-Anmeldeinformationen zugreifen, wie in der Hildegard-Forschung beschrieben. Mit Cloud-Anmeldeinformationen können Angreifer Zugriff auf die Cloud-Umgebung erhalten, in der die Kubernetes-Cluster gehostet werden, was zu einem weitaus schlimmeren Einbruch führt.

Schutz und Abhilfemaßnahmen

Alle oben genannten Probleme können durch strenge Sicherheitsrichtlinien verhindert werden, z. B:

• Häufig patchen: Bekannte Schwachstellen können für einen ersten Zugriff oder eine Privilegienerweiterung ausgenutzt werden. Anwendungen und Container-Plattformen sollten regelmäßig gescannt und regelmäßig gepatcht werden.
• Netzwerk schützen: Setzen Sie niemals Kubernetes-Komponenten wie API-Server, Kubelet oder etcd dem Internet aus. Firewall-Regeln sollten nur einer kleinen Teilmenge von IPs erlauben, mit diesen Komponenten zu kommunizieren. Erzwingen Sie gegenseitiges TLS (mTLS) auf jeder Kubernetes-Komponente, die mTLS unterstützt. Erzwingen Sie eine Netzwerksicherheitsrichtlinie, um die Pods, Namespaces und IP-Blöcke einzuschränken, mit denen ein Pod kommunizieren kann.
• Identität schützen: Erzwingen Sie eine rollenbasierte Zugriffskontrolle (RBAC) und praktizieren Sie das Prinzip des geringsten Privilegs. Gewähren Sie jeder Rolle die Berechtigungen, die unbedingt erforderlich sind. Keine Komponente sollte anonyme/unauthentifizierte Anfragen akzeptieren oder beantworten. Wechseln Sie die Anmeldeinformationen und das Zertifikat regelmäßig, um potenzielle Lecks bei den Anmeldeinformationen zu minimieren.

Fazit

Zwischen Oktober 2020 und Februar 2021 haben die Forscher von Palo Alto Networks eine große Menge an sensiblen Daten identifiziert, die aus ungesicherten Kubernetes-Clustern im Internet geleakt wurden. Zu den durchgesickerten Daten gehören API-Tokens, Datenbank-Anmeldeinformationen, Quellcode und PII. Während die Forscher keine groß angelegten oder ausgeklügelten Angriffe beobachtet haben, gab es in den letzten fünf Monaten einen zunehmenden Trend zu opportunistischen Angriffen. Mit der rasanten Verbreitung der Container-Technologie und den reichlich vorhandenen Rechenressourcen in diesen Kubernetes-Clustern ist davon auszugehen, dass bald mehr Angreifer ihre Aufmerksamkeit auf diesen unerforschten Bereich richten werden. Unabhängig davon können einfache Best Practices und kontinuierliche Überwachung die meisten dieser opportunistischen Angriffe effektiv verhindern und aufdecken. Angesichts der komplexen und dynamischen Natur der Kubernetes-Technologie ist es außerdem empfehlenswert, die Cluster mit Cloud-Workload-Schutzlösungen wie Prisma Cloud zu überwachen.