Microsoft hat kürzlich eine Liste mit verschiedenen Angriffs-Szenarien für Kubernetes Umgebungen vorgestellt. Die Liste stellt 9 verschiedene Taktiken (horizontal) mit den relevanten Techniken (vertikal) dazu dar. Im ersten Teil diese Blogserie haben wir die drei Taktiken Initial Access, Execution und Persistence angeschaut (hier geht’s zu Teil 1: www.tec-bite.ch/attacking-kubernetes-container-umgebungen-teil-1/). Heute im zweiten Teil der Serie widmen wir uns den fünf nächsten Taktiken auf der Liste: Privilege Escalation, Defense Evasion, Credential Access, Discovery und Lateral Movement.

Im dritten Teil der Serie werden wir noch auf die Impact-Taktik eingehen. Dazu aber später mehr.

Quelle: https://www.microsoft.com/security/blog/2020/04/02/attack-matrix-kubernetes/, abgerufen am 29.07.20

Die Liste ist wie die ATT&CK(1) Matrix von MITRE (Link: attack.mitre.org) gestaltet und listet 9 verschiedene Taktiken (horizontal) mit den relevanten Techniken (vertikal) dazu(2).

(1) ATT&CK steht für Adversarial Tactics, Techniques, and Common Knowledge, also für Angriffstaktiken, Techniken und allgemeines Wissen.

(2) Es gibt von MITRE übrigens auch eine allgemeinere ATT&CK Matrix für die Cloud (Link: attack.mitre.org/matrices/enterprise/cloud/)


Taktiken 1-3

Die Taktiken 1-3 sind im ersten Teil der Blogserie nachzulesen:

Attacking Kubernetes (Container-Umgebungen) – Teil 1


4. Privilege Escalation

Die Privilege Escalation Taktik besteht aus Techniken, die von den Angreifern eingesetzt werden, um in der Umgebung höhere Privilegien zu erhalten als die, die sie derzeit haben. In containerisierten Umgebungen bedeutet dies ein Zugriff auf den Node selber, ein Erlangen höherer Privilegien im Cluster oder der Zugriff auf weiterreichende Cloud Ressourcen.


4.1. Privileged container

Ein sogenannter privilegierter Container ist ein Container, der alle Funktionen des Hosts besitzt, und somit alle Einschränkungen aufhebt, die reguläre Container haben. In der Praxis bedeutet dies, dass privilegierte Container fast jede Aktion ausführen können, die direkt auf dem Host selber ausgeführt werden kann. Angreifer, die Zugriff auf einen privilegierten Container erhalten oder die Erlaubnis haben, einen neuen privilegierten Container zu erstellen (z.B. durch Verwendung von Service Accounts des kompromittierten Pods), können damit Zugriff auf die Ressourcen des Hosts erhalten.

Eine kontinuierliche Überwachung und Validierung vom Host und vor allem von kritischen Root-Dateien auf dem Host kann diese Technik blockieren oder mindestens rechtzeitig alarmieren, dass unerlaubte Aktivitäten aufgetreten sind. Oft wird dies kombiniert mit Threat Intel und einer Überwachung von Kommunikation nach aussen (Egress).


4.2. Cluster-admin binding

Die rollenbasierte Zugriffskontrolle (RBAC, Role-based access control) ist ein zentrales Sicherheitsmerkmal von Kubernetes. RBAC kann zulässige Aktionen der verschiedenen Identitäten im Cluster einschränken. Cluster-Admin zum Beispiel ist eine eingebaute hochprivilegierte Rolle in Kubernetes. Angreifer, die über Berechtigungen zum Erstellen von Bindings und Cluster-Bindings im Cluster verfügen, können sich damit die Cluster-Admin-Rolle ClusterRole oder andere Rollen mit hohen Privilegien erstellen.


4.3 hostPath mount

hostPath mount kann von Angreifern verwendet werden, um Zugriff auf den zugrundeliegenden Host zu erhalten und so vom Container zum Host zu gelangen. (Siehe „3: Writable hostPath mount“ für mehr Details).


4.4 Access cloud resources

Wenn der Kubernetes-Cluster in der Cloud betrieben wird, können Angreifer in bestimmten Fällen ihren Zugriff auf einen einzelnen Container ausnutzen, um Zugang zu anderen Cloud-Ressourcen ausserhalb des Clusters zu erhalten. Zum Beispiel enthält in AKS (Azure Kubernetes Service) jeder Node einen Service Principal Credential, der in /etc/kubernetes/azure.json gespeichert ist. AKS verwendet diese zur Erstellung und Verwaltung von Azure-Ressourcen, die für den Cluster-Betrieb benötigt werden.

Standardmässig verfügt dieser Service Account über Contributor-Berechtigungen in der Ressourcengruppe des Clusters. Angreifer, die Zugriff auf diese Datei erhalten (z.B. durch hostPath-Mount), können ihre Zugangsdaten verwenden, um auf die Cloud-Ressourcen zuzugreifen oder sie zu ändern.


5. Defense Evasion

Die Defense Evasion Taktik besteht aus Techniken, die von den Angreifern eingesetzt werden, um nicht entdeckt zu werden und ihre Aktivität zu verbergen.


5.1 Clear container logs

Angreifer können die Applikation oder die Betriebssystemprotokolle auf einem kompromittierten Container löschen, um zu verhindern, dass ihre Aktivität entdeckt wird.


5.2 Delete Kubernetes events

Ein Kubernetes-Ereignis ist ein Kubernetes-Objekt, das Zustandsänderungen und Ausfälle der Ressourcen im Cluster protokolliert. Beispiel-Ereignisse sind eine Container-Erstellung, ein Image-Pull oder ein Pod-Scheduling auf einem Node (Knoten).

Kubernetes-Ereignisse können sehr nützlich sein, um Änderungen zu identifizieren, die im Cluster auftreten. Daher möchten Angreifer diese Ereignisse möglicherweise löschen (z.B. durch die Verwendung von: „kubectl delete events-all„) in dem Versuch, die Erkennung ihrer Aktivität im Cluster zu vermeiden.

5.3 Pod / container name similarity

Pods, die von Controllern wie Deployment oder DaemonSet erstellt werden, haben ein zufälliges Suffix im Namen. Angreifer können diese Tatsache nutzen und ihre Backdoor-Pods gleich benennen, wie die, die von den Controllern erstellt wurden. Ein Angreifer könnte zum Beispiel einen bösartigen Pod namens coredns-{zufälliges Suffix} erstellen, der so aussieht, als ob er mit dem CoreDNS-Einsatz verwandt wäre.
Ausserdem können Angreifer ihre Container im gleichen Kube-System Namespace bereitstellen, in dem sich die administrativen Container befinden.


5.4 Connect from Proxy server

Angreifer können Proxy-Server verwenden, um ihre IP zu verbergen. Insbesondere nutzen Angreifer häufig anonyme Netzwerke wie TOR für ihre Aktivitäten. Dies kann für die Kommunikation mit den Anwendungen selbst oder mit dem API-Server verwendet werden.

Um zu verhindern, dass Verteidigungen umgangen werden, muss eine gute Sicherheitslösung anormale und böswillige Aktivitäten auf allen Ebenen identifizieren und erkennen können. Durch sorgfältige RBAC Kontrollen und limitierte Berechtigungen (z. B. keine Berechtigungen zum Erstellen oder Ändern von Pods oder Containern unter Verwendung des API-Servers) werden diese Risiken weiter reduziert.


6. Credential Access

Diese Taktik besteht aus Techniken, die von Angreifern zum Diebstahl von Credentials eingesetzt werden. In Container-Umgebungen gehören dazu die Credentials der laufenden Applikation, Identitäten, im Cluster gespeicherte Secrets oder Cloud-Credentials.


6.1 List Kubernetes secrets

Ein Kubernetes-Secret ist ein Objekt, mit dem Benutzer vertrauliche Informationen wie Passwörter und Connection Strings im Cluster speichern und verwalten können. Angreifer, die die Berechtigung haben, die Secrets vom API-Server abzurufen (z.B. durch Verwendung des Pod-Dienstkontos / Pod Service Account), können auf vertrauliche Informationen zugreifen, die Credentials für verschiedene Dienste enthalten können.

Ein Benutzer mit der Berechtigung, Secrets aufzulisten, kann potenziell alle Secrets im ganzen Cluster einsehen – einschliesslich der Admin-Schlüssel. Der geheime Schlüssel ist ein in base64 kodiertes JWT-Token. Ein Angreifer, der Secrets im Cluster auflisten darf, kann Curl-Befehle verwenden, um alle Geheimnisse im „kube-system“-Namensraum zu erhalten.


6.2 Mount service principal

Wenn der Cluster in der Cloud eingesetzt wird, können Angreifer in bestimmten Fällen ihren Zugriff auf einen Container im Cluster nutzen, um Cloud-Credentials zu erlangen. In AKS beispielsweise enthält jeder Node ein Service Principal Credential. (Siehe “4.4: Access cloud resources“ für weitere Einzelheiten).


6.3 Access container service account

Das Servicekonto (Servcie Account, SA) stellt in Kubernetes eine Applikationsidentität dar. Standardmässig wird ein SA an jeden Pod im Cluster verteilt. Mithilfe des SA können Container im Pod Anfragen an den Kubernetes API-Server senden. Angreifer, die Zugriff auf einen Pod gewinnen, können auf das SA-Token (das sich in /var/run/secrets/kubernetes.io/serviceaccount/token befindet) zugreifen und entsprechend den SA-Berechtigungen Aktionen im Cluster ausführen. Wenn RBAC nicht aktiviert ist, hat das SA eigentlich unbegrenzte Berechtigungen im Cluster. Wenn RBAC aktiviert ist, werden seine Berechtigungen durch die RoleBindings \ ClusterRoleBindings bestimmt.

Auch hier wird wieder klar, dass RBAC absolut fundamental ist und konsequent konfiguriert und eingesetzt werden sollte.


6.4 Application credentials in configuration files

Die Entwickler speichern sog. Geheimnisse (Secrets) in den Kubernetes-Konfigurationsdateien, wie z.B. Umgebungsvariablen der Konfiguration von Pods. Ein solches Verhalten wird häufig in Clustern beobachtet, die vom Azure Security Center überwacht werden. Angreifer, die Zugriff auf diese Konfigurationen bekommen, indem sie den API-Server abfragen oder auf Dateien auf dem Endpunkt des Entwicklers zugreifen, können die gespeicherten Geheimnisse stehlen und sie dann auch verwenden.

Die Verwundbarkeit liegt darin, dass Mechanismen und Services missbraucht werden können, wenn ein Angreifer erst einmal einen ersten Zugriff auf den Cluster bekommt.


7. Discovery

Die sogenannte Discovery Taktik besteht aus Techniken, die von Angreifern eingesetzt werden, um die Umgebung zu erforschen, zu der sie sich einen Zugang erschaffen haben. Diese Erkundung hilft den Angreifern, ein Lateral Movement auszuführen und Zugang zu zusätzlichen Ressourcen zu gewinnen.

Alle Techniken im Punkt 7 missbrauchen Mechanismen und Services die für den normalen Betrieb eines Clusters gebraucht werden. Wenn ein Angreifer erst einmal einen ersten Zugriff auf den Cluster bekommt, hat er meistens auch Zugriff auf diese legitimen Services und kann sie missbrauchen um mehr Informationen über den gesamten Cluster zu gewinnen. Eine gute Container-Security-Lösung sollte Verhaltensanomalien auf verschiedensten Ebenen erkennen können, z.B. durch Behavioral Analysis oder Baselining und sollte nicht nur die Integrität des Hosts und wichtiger Files checken, sondern auch die API und API Zugriffe überprüfen.

Der Zugriff auf die Kubernetes API kann durch API Authentication und API Authorization (RBAC) eingeschränkt werden, und dedizierte Container-Security-Lösungen können die Konfiguration gegenüber Best-Practices vergleichen und bei der richtigen Konfiguration helfen.


7.1 Zugriff auf den API-Server von Kubernetes

Der API-Server von Kubernetes ist das Eingangstor des Clusters. Aktionen im Cluster werden ausgeführt, indem verschiedene Anfragen an die RESTful-API gesendet werden. Der Status des Clusters, der alle Komponenten umfasst, die auf dem Cluster bereitgestellt werden, kann vom API-Server abgerufen werden. Angreifer können auch API-Anfragen senden, um Informationen über Container, Secrets und andere Ressourcen im Cluster zu erhalten.


7.2 Zugriff auf die Kubelet-API

Das Kubelet ist ein Kubernetes-Agent, der auf jedem Node installiert ist. Kubelet ist für die ordnungsgemässe Ausführung von Pods verantwortlich, die einem Knoten zugeordnet sind. Das Kubelet stellt einen schreibgeschützten API-Dienst bereit, der keine Authentifizierung erfordert (TCP-Port 10255). Angreifer mit Netzwerkzugriff auf den Host (z. B. durch Ausführen von Code auf einem kompromittierten Container) können API-Anfragen an diese Kubelet-API senden. Durch gezielte Abfrage von z.B. https://[NODE IP]:10255/pods/ werden die laufenden Pods auf dem Knoten abgerufen. Und https://[NODE IP]:10255/spec/ ruft Informationen über den Knoten selbst ab, wie z. B. CPU- und Speicherverbrauch.


7.3 Netzwerk-Abbildung

Angreifer können versuchen, das Cluster-Netzwerk zu visualisieren, um Informationen über die laufenden Anwendungen zu erhalten. Sie können sogar selber nach bekannten Schwachstellen suchen bzw. scannen. Standardmässig gibt es keine Beschränkung für die Kommunikation zwischen Pods in Kubernetes. Daher können Angreifer, die Zugriff auf einen einzelnen Container erhalten, diesen benutzen, um das gesamte Netz zu untersuchen.


7.4 Zugriff auf das Kubernetes Dashboard

Das Kubernetes-Dashboard ist eine webbasierte Benutzeroberfläche, die für die Überwachung und Verwaltung des Kubernetes-Clusters verwendet wird. Das Dashboard ermöglicht es Benutzern, Aktionen im Cluster unter Verwendung seines Service-Accounts (kubernetes-dashboard) mit den Berechtigungen durchzuführen, die für diesen Service-Account festgelegt sind. Angreifer, die Zugriff auf einen Container im Cluster gewinnen, können dessen Netzwerkzugriff auf den Dashboard-Pod ausnutzen. Folglich können Angreifer unter Verwendung der Identität des Dashboards Informationen über die verschiedenen Ressourcen im Cluster abrufen.


7.5 Instance Metadata API

Cloud-Anbieter bieten einen sogenannten “Instance Metadata Service” zum Abrufen von Informationen über VMs, wie z.B. Netzwerkkonfiguration, Festplatten und public SSH-Keys. Dieser Service ist für die VMs über eine nicht routbare IP-Adresse zugänglich, auf die nur von innerhalb der VM aus zugegriffen werden kann. Angreifer, die Zugriff auf einen Container gewinnen, können diesen Service abfragen, um Informationen über den zugrundeliegenden Nodes zu erhalten. In Azure würde z.B. die folgende Anfrage alle Metadateninformationen einer Instanz abrufen: http:///metadata/instance?api-version=2019-06-01


8. Lateral Movement

Die Taktik des Lateral Movements besteht aus Techniken, mit denen sich der Angreifer durch die angegriffene Umgebung bewegen kann. In containerisierten Umgebungen umfasst dies den Zugriff auf verschiedene Ressourcen im Cluster, von Container ausgehend, den Zugriff auf den darunterliegenden Node oder den Zugriff auf die Cloud-Umgebung zu gewinnen.


8.1 Zugriff auf Cloud-Ressourcen

Angreifer können von einem kompromittierten Container aus in die Cloud-Umgebung wechseln. (Siehe auch „6.3 Access container service account“ für mehr Details).


8.2 Container-Service-Konto

Angreifer, die Zugriff auf einen Container im Cluster bekommen, können das entsprechende Service-Account-Token verwenden, um Anfragen an den API-Server zu senden und damit Zugriff auf zusätzliche Ressourcen im Cluster zu erhalten. (Siehe „6.3 Access container service account” für weitere Einzelheiten).


8.3 Das Cluster Netzwerk

In einem Kubernetes Cluster ist der Netzwerkverkehr zwischen den Pods grundsätzlich immer erlaubt. Angreifer können diesen Default ausnützen, indem sie von einem kompromittierten Container aus auf weitere Container innerhalb des Clusters zugreifen.

Die Kubernetes Network Policies können so angepasst werden, dass nur diejenigen Pods netzwerktechnisch untereinander kommunizieren können, die dies auch wirklich brauchen. Dies wird in der Praxis durch eine Mikrosegmentierung der Umgebung gemacht. Die Orchestrierung der Mikrosegmentierung wird meistens durch ein 3rd-Party Tool umgesetzt.


8.4 Applications credentials in Konfigurationsdateien

Entwickler speichern oft Secrets in den Kubernetes-Konfigurationsdateien, zum Beispiel als Umgebungsvariablen (environment variables) in der Pod-Konfiguration. Mit diesen Secrets können Angreifer Zugriff auf zusätzliche Ressourcen innerhalb und ausserhalb des Clusters erlangen. (Siehe „6.4 Application credentials in configuration files“ für weitere Einzelheiten).


8.5 Schreibzugriff auf Volume auf dem Host

Angreifer können versuchen, von einem kompromittierten Container aus Zugriff auf den zugrundeliegenden Host zu erlangen. (Siehe „3.2 Writable hostPath Mount“ für weitere Einzelheiten).


8.6 Zugriff auf das Kubernetes Dashboard

Angreifer, die Zugriff auf das Kubernetes-Dashboard erlangen, können die Cluster-Ressourcen verwalten und ihren eigenen Code auf den verschiedenen Containern im Cluster ausführen, indem sie die integrierte „exec“-Funktion des Dashboards nutzen. (Siehe „7.4 Zugriff auf das Kubernetes Dashboard“ für weitere Einzelheiten).


8.7 Access tiller endpoint

Helm ist ein beliebter Paketmanager für Kubernetes, der von der CNCF (Cloud Native Computing Foundation) gepflegt wird. Tiller ist die serverseitige Komponente von Helm bis zur Version 2.

Tiller öffnet den internen gRPC-Endpoint im Cluster auf Port 44134. Standardmässig erfordert dieser Endpunkt keine Authentifizierung. Angreifer können den Code auf jedem Container ausführen, auf denen der Tiller-Service Zugriff hat, und damit Aktionen im Cluster durchführen, wobei sie den Service-Account des Tiller-Services verwenden, denn dieser verfügt häufig über hohe Privilegien.


Im dritten und letzten Teil dieser Serie schauen wir uns die letzte Taktik an und überlegen uns, was in dieser Threat Matrix noch fehlt, bzw. auf was man sonst noch achten sollte.