Microsoft hat kürzlich eine Liste mit verschiedenen Angriffs-Szenarien für Kubernetes Umgebungen vorgestellt. Ich dachte es wäre ganz interessant, die Liste mal anzuschauen und sich Gedanken zu machen, wie man sich vor diesen Angriffsvektoren schützt.

Attack Matrix Kubernetes
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/)


1. Initial Access

Hier geht es um die Frage, wie Angreifer überhaupt in die Kubernetes Umgebung hineinkommen und sich Zugriff verschaffen. Microsoft listet hier 5 verschiedene Techniken auf:

1.1. Using cloud credentials

Falls man ein Kubernetes-Cluster in einer öffentlichen Cloud betreibt, dann sind Cloud Credentials (Login-Informationen) ein sehr beliebter Angriffsvektor. Dies gilt genauso für K8s Cluster, die man selber in IaaS betreibt, wie auch für managed Cluster (AKS, GKE oder EKS).

Dabei unterscheidet Microsoft zwischen kompromittierten und schwachen Credentials. Zu Benutzernamen und Passwörtern kommt man immer noch am einfachsten über Phishing, Malware oder frühere Data Leaks. Username /Password Combos können auch eingekauft werden(3) und sind für Angreifer der schnellste Weg, um auf eine Cloud-Umgebung zu kommen. Durch den Einsatz von Two-Factor (2FA), Multifactor (MFA) Authentication und dem sogenannten Conditional Access kann einem gestohlenen User/Password entgegengewirkt werden.

Mit schwachen Credentials sind schwache Passwörter (123456, Password, qwertz, etc.) gemeint und vor allem auch Password-Reusal, d.h. der Einsatz vom gleichen Passwort in verschiedenen Umgebungen.

Wenn man z.B. das gleiche Passwort für ein persönliches Online-Forum wie auch für die Cloud-Umgebung benutzt (trotz verschiedener Benutzernamen), dann kann bei einem Data-Leak oder einem Breach im Online-Forum das gefundene Passwort eben auch die Cloud-Umgebung kompromittiert werden.

Vor allem bei Kubernetes Umgebungen in Public Clouds können kompromittierte Cloud-Credentials dazu führen, dass der gesamte Cluster von einem Angreifer übernommen werden kann. Durch den Zugriff auf das Management Backend kann der Angreifer einen permanenten Zugriff auf die Umgebung sicherstellen.

(3) Ein neuer Report über Fxmsp, einem der produktivsten Verkäufern von Zugangsdaten zu Unternehmensnetzwerken wurde kürzlich hier publiziert:
www.group-ib.com/resources/threat-research/fxmsp-report.html


1.2. Compromised images in registry

Ein kompromittiertes Image, das in einem Cluster läuft, kann den gesamten Cluster gefährden. Damit ist der Angriff auf ein Registry (wo Images gespeichert werden) ein beliebter Angriffsvektor. Oft beziehen Benutzer aber auch Images aus öffentlichen Registries (public registry wie z. B. Docker Hub), wobei diese Images sehr oft Schwachstellen (Vulnerabilities) beinhalten oder schlichtweg kompromittiert sein können. Auch das Erstellen von Images, die auf nicht vertrauenswürdigen Basisimages basieren, kann zu ähnlichen Ergebnissen führen.

Vulnerability Scanning von Images ist für Container-Umgebungen ein absolutes Muss. Dabei sollten die Images nicht nur bei/nach der Erstellung, sondern auch regelmässig danach gescannt werden. Es ist ja gut möglich, dass eine Schwachstelle in einer Public Library erst nach dem ersten Scan identifiziert wird. Die Verbindungen zu Private Registries sollten geschützt sein und man braucht Policies um zu definieren, wie man mit Images aus Public Registries umgehen will.

Runtime-Security in Container Umgebungen identifiziert unübliche oder unerlaubte Aktionen. Man kann über Policies steuern, was erlaubt ist und was nicht, und wenn ein Container oder eine Applikation sich unüblich verhält, wird dies alarmiert und das potenziell kompromittierte Image wird heruntergefahren und isoliert. Runtime-Security ist ein sehr guter Zusatz zum Vulnerability Scanning, denn nicht alle Schwachstellen werden beim Scanning identifiziert.

Des Weiteren sollten nur authorisierte Registries eingesetzt werden und Container-Prozesse sollten whistelisted werden.


1.3 Kubeconfig file

Die kubeconfig Datei, die auch von kubectl verwendet wird, enthält Details über das Kubernetes-Cluster einschliesslich ihres Standorts und ihrer Zugangsdaten (Credentials). Wenn der Cluster als Cloud-Service (AKS oder GKE) gehostet wird, wird diese Datei über Cloud-Befehle (z.B. „az aks get-credential“ für AKS oder „gcloud container clusters get-credentials“ für GKE) auf den Client heruntergeladen. Wenn ein Angreifer Zugriff auf diese Datei erhält, z.B. über einen kompromittierten Client, kann sie für den Zugriff auf den Cluster verwendet werden.

Man sollte sicherstellen, dass gewisse kritische Files regelmässig auf ihre Integrität hin gescannt werden (File Integrity Scanning) und man sollte auch gewährleisten, dass die Berechtigungen so eingestellt wurden, dass normale User keinen Zugriff auf administrative Dateien haben. Das File Integrity Scanning funktioniert auf Kubernetes-Clustern gleich wie auf On-Premises Servern, wobei die überwachten Dateien der Umgebung angepasst werden.


1.4 Vulnerable Application

Wenn man eine öffentlich zugängliche und anfällige (vulnerable) Applikation in einem Cluster laufen lässt, dann riskiert man damit den ganzen Cluster. Ein Container der für eine Remote Code Execution Vulnerability (RCE) anfällig ist, kann damit ausgenutzt werden. Wenn ein Service Account mit dem Container verbunden ist (Standardverhalten bei Kubernetes), dann können diese Credentials wiederum missbraucht werden, um mit dem API Server zu kommunizieren, um Abfragen oder Befehle auszuführen.

Jedes Image muss durch ein Vulnerability Scanning laufen, das erste Mal während der Build-Phase und kontinuierlich, wenn es im Repository sitzt (oder bevor es aus dem Repository gezogen wird). Die meisten Images haben irgendwelche Vulnerabilities (3rd Party Elemente oder Open-Source Code etc.) und ein kontinuierliches Scanning ist ein fundamentaler Pfeiler jeder Container-Security Lösung.


1.5 Exposed Dashboard

Das Kubernetes Dashboard ist eine webbasierte Benutzeroberfläche, mit der man den Kubernetes-Cluster überwacht und verwaltet. Das Dashboard kommuniziert intern über den ClusterIP Service und wenn man es gegenüber dem Internet aufmacht, dann könnte ein Angreifer von extern darauf zugreifen.

In 2018 wurde z.B. die Kubernetes Infrastruktur von Tesla kompromittiert. Der Angriffsvektor war genau das Kubernetes-Dashboard, das gegenüber dem allgemeinen Internet ohne Authentifizierung und mit erhöhten Privilegien ausgesetzt war.


2. Execution

In der Execution-Phase geht es um das Ausführen von Code (auch Runtime genannt) innerhalb des Kubernetes Clusters. Hier listet Microsoft 4 verschiedene Techniken:

2.1 Exec into Container

Angreifer, die über genügend Berechtigungen verfügen, können mit dem exec-Befehl („kubectl exec“) böswillige Befehle in Containern im Cluster ausführen. Bei dieser Methode können Angreifer legitime Images, wie z.B. ein OS-Image (z.B. Ubuntu), als Backdoor-Container verwenden und ihren bösartigen Code mit „kubectl exec“ aus der Ferne ausführen (z.B. eine Shell in einem produktiven Container zu bekommen).


2.2 New Containers

Angreifer können versuchen, ihren Code im Cluster auszuführen, indem sie einen Container deployen. Wenn sie die Berechtigung haben, einen Pod oder einen Controller im Cluster zu starten (z.B. DaemonSet \ ReplicaSet\ Deployment), können sie eine neue Ressource zur Ausführung ihres Codes erstellen.


2.3 Application Exploit

Eine Applikation, die im Cluster bereitgestellt wird und für eine Schwachstelle anfällig ist (remote code execution vulnerability oder zu einer RCE führen kann), erlaubt einem Angreifer Code im Cluster auszuführen.

Service Accounts sind normalerweise mit in den Container eingebunden (Standardverhalten in Kubernetes, siehe auch weiter oben, 1.4 Vulnerable Application) und der Attacker kann mit diesen Dienstkonto Anfragen an den API-Server senden.

Ein weiterer Grund, weswegen Vulnerability Scanning so wichtig ist. Details siehe 1.4.


2.4 SSH Server Running inside Container

Ein SSH-Server (sshd), der innerhalb eines Containers läuft, kann von Angreifern ausgenutzt werden. Wenn ein Angreifer gültige Zugangsdaten zu einem Container erlangen, sei es durch Brute-Force-Attacken oder durch andere Methoden (z.B. Phishing), können sie diese benutzen, um durch SSH Remote Access auf den Container zu bekommen.

Einmal im Container, können sie andere Techniken benutzen um die Kontrolle über den ganzen Cluster zu bekommen. Siehe auch 2.1 bis 2.3.

Eine gute Container-Security Lösung kann die RBAC-Konfigurationen validieren und sicherstellen, dass die nach dem Prinzip der geringsten Privilegien erstellt wurde. Gefährdete Kubernetes Ressourcen müssen identifiziert werden können und durch eine kontinuierliche Analyse sollten anormale Admin- oder Netzwerkaktivitäten identifiziert werden können.


3. Persistence

Hier geht es um Techniken, die Angreifer benutzen können um innerhalb eines Containers oder eines Clusters einen permanenten Zugriff zu bekommen, der auch dann noch funktioniert, wenn der ursprüngliche Einstiegspunkt (oder die ursprüngliche Lücke) wieder geschlossen wird.

3.1 Backdoor Container

Angreifer führen ihren schädlichen Code (malicious code) in einem Container innerhalb eines Cluster aus. Durch die Verwendung von Kubernetes-Controllern wie DaemonSets oder Deployments können Angreifer sicherstellen, dass eine konstante Anzahl ihrer Container in einem oder allen Nodes im Cluster ausgeführt werden.


3.2 Writable hostPath Mount

hostPath-Volume hängt ein Verzeichnis oder eine Datei vom Host an den Container. Angreifer, die die Berechtigung zum Erstellen eines neuen Containers im Cluster haben, können einen Container mit einem schreibberechtigten hostPath-Volume erstellen und Persistenz auf dem darunterliegenden Host erlangen. Letzteres kann zum Beispiel durch die Erstellung eines Cron-Jobs auf dem Host erreicht werden.

Aus der Kubernetes Dokumentation (Quelle: kubernetes.io/docs/concepts/storage/volumes/#hostpath, abgerufen am 29.07.20):

“A hostPath volume mounts a file or directory from the host node’s filesystem into your Pod. This is not something that most Pods will need, but it offers a powerful escape hatch for some applications.”

 

    • Container, der Zugriff auf Docker-Internals benötigt: hostPath von /var/lib/docker
    • cAdvisor in einem Container ausführen; einen hostPath von /sys verwenden
    • einem Pod erlauben, anzugeben, ob ein bestimmter hostPath vor der Ausführung des Pods existiert, ob er erstellt werden soll und als was er existieren soll
    • Zusätzlich zu der erforderlichen Pfad-Eigenschaft kann der Benutzer optional einen Type für ein hostPath-Volume angeben.

Man kann über die Pod Security Policies die AllowedHostPaths definieren, z. B. Über eine Liste erlaubter Volume-Typen. Oder man kann (und sollte) hostPath über Admissions Controller validieren.

Mehr infos in der Kubernetes Dokumentation: kubernetes.io/docs/concepts/policy/pod-security-policy/


3.3 Kubernetes CronJob

Kubernetes CronJob ist ein Controller, der eine oder mehrere Pods erstellt und dafür sorgt, dass eine bestimmte Anzahl von ihnen erfolgreich terminiert werden. Kubernetes CronJob kann verwendet werden, um Container auszuführen, die bestimmte, zeitlich begrenzte Aufgaben ausführen (z.B. Batch-Jobs). CronJob wird normalerweise zur zeitlichen Planung (scheduling) von Befehlen verwendet. Angreifer können Kubernetes CronJob zur Planung der Ausführung von schädlichem Code missbrauchen.

Verschiedene Container-Security Lösungen können die Root-Dateisysteme überwachen, und Veränderungen erkennen und validieren. Damit kann ein böswilliges Überschreiben von Root-Daten verhindert werden.


Zu den weiteren Taktiken mehr im zweiten Teil dieser Blog Serie.