Pentesting Kubernetes Services

Reading time: 8 minutes

Kubernetes verwendet mehrere spezifische Netzwerkdienste, die Sie möglicherweise im Internet oder in einem internen Netzwerk finden, sobald Sie einen Pod kompromittiert haben.

Finden von exponierten Pods mit OSINT

Eine Möglichkeit könnte sein, nach Identity LIKE "k8s.%.com" in crt.sh zu suchen, um Subdomains zu finden, die mit Kubernetes in Verbindung stehen. Eine andere Möglichkeit könnte sein, nach "k8s.%.com" in GitHub zu suchen und nach YAML-Dateien zu suchen, die den String enthalten.

Wie Kubernetes Dienste exponiert

Es könnte nützlich sein, zu verstehen, wie Kubernetes Dienste öffentlich exponieren kann, um sie zu finden:

Exposing Services in Kubernetes

Finden von exponierten Pods über Port-Scanning

Die folgenden Ports könnten in einem Kubernetes-Cluster offen sein:

Nmap

nmap -n -T4 -p 443,2379,6666,4194,6443,8443,8080,10250,10255,10256,9099,6782-6784,30000-32767,44134 <pod_ipaddress>/16

Kube-apiserver

Dies ist der API Kubernetes-Dienst, mit dem die Administratoren normalerweise das Tool kubectl verwenden.

Häufige Ports: 6443 und 443, aber auch 8443 in minikube und 8080 als unsicher.

curl -k https://<IP Address>:(8|6)443/swaggerapi
curl -k https://<IP Address>:(8|6)443/healthz
curl -k https://<IP Address>:(8|6)443/api/v1

Überprüfen Sie die folgende Seite, um zu erfahren, wie Sie sensible Daten erhalten und sensible Aktionen mit diesem Dienst durchführen können:

Kubernetes Enumeration

Kubelet API

Dieser Dienst läuft auf jedem Knoten des Clusters. Es ist der Dienst, der die Pods innerhalb des Knotens steuert. Er kommuniziert mit dem kube-apiserver.

Wenn Sie diesen Dienst exponiert finden, haben Sie möglicherweise eine unauthentifizierte RCE gefunden.

Kubelet API

curl -k https://<IP address>:10250/metrics
curl -k https://<IP address>:10250/pods

Wenn die Antwort Unauthorized ist, erfordert dies eine Authentifizierung.

Wenn Sie Knoten auflisten können, können Sie eine Liste der Kubelet-Endpunkte mit folgendem Befehl erhalten:

kubectl get nodes -o custom-columns='IP:.status.addresses[0].address,KUBELET_PORT:.status.daemonEndpoints.kubeletEndpoint.Port' | grep -v KUBELET_PORT | while IFS='' read -r node; do
ip=$(echo $node | awk '{print $1}')
port=$(echo $node | awk '{print $2}')
echo "curl -k --max-time 30 https://$ip:$port/pods"
echo "curl -k --max-time 30 https://$ip:2379/version" #Check  also for etcd
done

kubelet (Nur lesen)

curl -k https://<IP Address>:10255
http://<external-IP>:10255/pods

etcd API

curl -k https://<IP address>:2379
curl -k https://<IP address>:2379/version
etcdctl --endpoints=http://<MASTER-IP>:2379 get / --prefix --keys-only

Tiller

helm --host tiller-deploy.kube-system:44134 version

Sie könnten diesen Dienst missbrauchen, um Privilegien innerhalb von Kubernetes zu eskalieren:

cAdvisor

Dienst, der nützlich ist, um Metriken zu sammeln.

curl -k https://<IP Address>:4194

NodePort

Wenn ein Port in allen Knoten über einen NodePort freigegeben wird, wird derselbe Port in allen Knoten geöffnet, um den Verkehr in den deklarierten Service zu proxifizieren. Standardmäßig liegt dieser Port im Bereich 30000-32767. Daher könnten neue, nicht überprüfte Dienste über diese Ports zugänglich sein.

sudo nmap -sS -p 30000-32767 <IP>

Verwundbare Fehlkonfigurationen

Kube-apiserver Anonymer Zugriff

Anonymer Zugriff auf kube-apiserver API-Endpunkte ist nicht erlaubt. Aber Sie könnten einige Endpunkte überprüfen:

Überprüfung des ETCD Anonymen Zugriffs

Der ETCD speichert die Clustergeheimnisse, Konfigurationsdateien und weitere sensible Daten. Standardmäßig kann der ETCD nicht anonym zugegriffen werden, aber es ist immer gut, dies zu überprüfen.

Wenn der ETCD anonym zugänglich ist, müssen Sie möglicherweise das etcdctl Tool verwenden. Der folgende Befehl ruft alle gespeicherten Schlüssel ab:

etcdctl --endpoints=http://<MASTER-IP>:2379 get / --prefix --keys-only

Kubelet RCE

Die Kubelet-Dokumentation erklärt, dass standardmäßig anonymer Zugriff auf den Dienst erlaubt ist:

Ermöglicht anonyme Anfragen an den Kubelet-Server. Anfragen, die von einer anderen Authentifizierungsmethode nicht abgelehnt werden, werden als anonyme Anfragen behandelt. Anonyme Anfragen haben einen Benutzernamen von system:anonymous und einen Gruppennamen von system:unauthenticated.

Um besser zu verstehen, wie die Authentifizierung und Autorisierung der Kubelet-API funktioniert, überprüfen Sie diese Seite:

Kubelet Authentication & Authorization

Die Kubelet-Dienst-API ist nicht dokumentiert, aber der Quellcode kann hier gefunden werden, und das Finden der exponierten Endpunkte ist so einfach wie auszuführen:

curl -s https://raw.githubusercontent.com/kubernetes/kubernetes/master/pkg/kubelet/server/server.go | grep 'Path("/'

Path("/pods").
Path("/run")
Path("/exec")
Path("/attach")
Path("/portForward")
Path("/containerLogs")
Path("/runningpods/").

Alle klingen interessant.

Sie können das Kubeletctl Tool verwenden, um mit Kubelets und ihren Endpunkten zu interagieren.

/pods

Dieser Endpunkt listet Pods und ihre Container auf:

kubeletctl pods

/exec

Dieser Endpunkt ermöglicht es, Code sehr einfach innerhalb eines Containers auszuführen:

kubeletctl exec [command]

Überprüfung der Kubelet (Nur-Lese-Port) Informationsfreigabe

Wenn ein kubelet nur-Lese-Port freigegeben ist, wird es unbefugten Parteien möglich, Informationen über die API abzurufen. Die Freigabe dieses Ports kann zur Offenlegung verschiedener Cluster-Konfigurationselemente führen. Obwohl die Informationen, einschließlich Pod-Namen, Standorte interner Dateien und anderer Konfigurationen, möglicherweise nicht kritisch sind, stellt ihre Freigabe dennoch ein Sicherheitsrisiko dar und sollte vermieden werden.

Ein Beispiel dafür, wie diese Schwachstelle ausgenutzt werden kann, besteht darin, dass ein Angreifer aus der Ferne auf eine bestimmte URL zugreift. Durch das Navigieren zu http://<external-IP>:10255/pods kann der Angreifer potenziell sensible Informationen vom kubelet abrufen:

Referenzen

Kubernetes Pentest Methodology Part 2

Threats & Research Archives - F-Secure Blog