Abusing Roles/ClusterRoles in Kubernetes
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Hapa unaweza kupata baadhi ya mipangilio ya Roles na ClusterRoles ambayo inaweza kuwa hatari.
Kumbuka kwamba unaweza kupata rasilimali zote zinazoungwa mkono kwa kutumia kubectl api-resources
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 kimsingi mbinu 4 kuu za kupandisha mamlaka:
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/kusasisha/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, akreditivu 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.
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
Katika RBAC, ruhusa fulani zina hatari kubwa:
create: Inatoa uwezo wa kuunda rasilimali yoyote ya klasta, ikihatarisha kupanda kwa mamlaka.
list: Inaruhusu kuorodhesha rasilimali zote, ikihatarisha kuvuja kwa data nyeti.
get: Inaruhusu kufikia siri kutoka kwa akaunti za huduma, ikileta tishio la usalama.
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 inainua mamlaka kwake.
Mfano wa pod ambayo itakuwa na uwezo wa kuiba token ya akaunti ya huduma ya bootstrap-signer na kuisafirisha kwa mshambuliaji:
Ifuatayo inaonyesha haki zote ambazo kontena linaweza kuwa nazo:
Upatikanaji wa haki (kuondoa ulinzi na kuweka uwezo)
Zima namespaces hostIPC na hostPid ambazo zinaweza kusaidia kuongeza haki
Zima hostNetwork namespace, ikitoa ufikiaji wa kuiba haki za wingu za nodi na ufikiaji bora wa mitandao
Mount hosts / ndani ya kontena
Unda pod na:
Mstari mmoja kutoka hiki tweet na nyongeza chache:
Now that you can escape to the node check post-exploitation techniques in:
You probably want to be stealthier, in the following pages you can see what you would be able to access if you create a pod only enabling some of the mentioned privileges in the previous template:
Privileged + hostPID
Privileged only
hostPath
hostPID
hostNetwork
hostIPC
You can find example of how to create/abuse the previous privileged pods configurations in https://github.com/BishopFox/badPods
If you can create a pod (and optionally a service account) you might be able to obtain privileges in cloud environment by assigning cloud roles to a pod or a service account and then accessing it. Moreover, if you can create a pod with the host network namespace you can steal the IAM role of the node instance.
For more information check:
It's possible to abouse these permissions to create a new pod and estalae privileges like in the previous example.
The following yaml creates a daemonset and exfiltrates the token of the SA inside the pod:
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.
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 (ab) kutumia node:
Ruhusa hii inaruhusu kupeleka bandari moja ya ndani kwa bandari moja katika pod iliyoainishwa. Hii inakusudia 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:
Kama ilivyoonyeshwa katika utafiti huu, ikiwa unaweza kufikia au kuunda pod yenye hosts /var/log/ directory iliyowekwa juu yake, unaweza kutoroka kutoka kwenye kontena.
Hii ni kwa sababu wakati Kube-API inajaribu kupata logi za kontena (kwa kutumia kubectl logs <pod>), inafanya ombwe la faili 0.log la pod kwa kutumia /logs/ endpoint ya huduma ya Kubelet.
Huduma ya Kubelet inatoa /logs/ endpoint ambayo kimsingi ni kuweka wazi mfumo wa faili wa /var/log wa kontena.
Hivyo, mshambuliaji mwenye ufikiaji wa kuandika katika folda /var/log/ ya kontena anaweza kutumia tabia hii 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 inayotaja /etc/shadow kwa mfano. Kisha, utaweza kuhamasisha faili la kivuli cha wenyeji kwa kufanya:
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://<gateway>:10250/logs/sym/ atataja mfumo wa faili wa mizizi wa mwenyeji (kubadilisha symlink kunaweza kutoa ufikiaji wa faili).
Maabara na exploit ya otomatiki inaweza kupatikana katika https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts
Ikiwa una bahati na uwezo wa juu wa `CAP_SYS_ADMIN upo, unaweza tu kuunganisha tena folda hiyo kama rw:
Kama ilivyoelezwa katika utafiti huu inawezekana kupita ulinzi:
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:
Kwa kutumia user impersonation mamlaka, mshambuliaji anaweza kujifanya kuwa akaunti yenye mamlaka.
Tumia tu parameter --as=<username> katika amri kubectl kujifanya kuwa mtumiaji, au --as-group=<group> kujifanya kuwa kundi:
Au tumia API ya REST:
Ruhusa ya kuorodhesha siri inaweza kumruhusu mshambuliaji kusoma siri kwa kufikia mwisho wa API ya REST:
Wakati mshambuliaji mwenye token yenye ruhusa za kusoma anahitaji jina sahihi 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 herufi fulani) kulingana na kanuni ya chanzo.
Token inazalishwa kutoka kwenye seti ndogo ya herufi 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 ndani ya masaa machache, ambayo inaweza kusababisha kupandishwa vyeo kwa kufikia akaunti za huduma nyeti.
Ikiwa una vitenzi create katika rasilimali certificatesigningrequests (au angalau katika certificatesigningrequests/nodeClient). Unaweza kuunda CeSR mpya ya node mpya.
Kulingana na nyaraka inawezekana kuidhinisha maombi haya kiotomatiki, hivyo katika hali hiyo huhitaji ruhusa za ziada. Ikiwa sivyo, unahitaji kuwa na uwezo wa kuidhinisha ombi, ambayo inamaanisha sasisha katika certificatesigningrequests/approval na approve katika signers na resourceName <signerNameDomain>/<signerNamePath> au <signerNameDomain>/*
Mfano wa role yenye ruhusa zote zinazohitajika ni:
Hivyo, na CSR mpya ya node iliyothibitishwa, unaweza kuabudu ruhusa maalum za nodes ili kuchukua siri na kuinua mamlaka.
Katika post hii na hii moja usanidi wa GKE K8s TLS Bootstrap umewekwa na saini ya kiotomatiki na unatumika vibaya kuzalisha akreditif za Node mpya ya K8s na kisha kuabudu hizo ili kuinua mamlaka kwa kuchukua siri. Ikiwa una mamlaka zilizotajwa unaweza kufanya kitu kama hicho. Kumbuka kwamba mfano wa kwanza unazidi kosa linalozuia node mpya kufikia siri ndani ya kontena kwa sababu node inaweza kufikia tu siri za kontena zilizowekwa juu yake.
Njia ya kupita hii ni tu kuunda akreditif za node kwa jina la node ambapo kontena lenye siri za kuvutia limewekwa (lakini angalia tu jinsi ya kufanya hivyo katika post ya kwanza):
Wajibu wanaoweza kubadilisha configmaps katika eneo la kube-system kwenye EKS (lazima wawe ndani ya AWS) vikundi wanaweza kupata haki za usimamizi wa klasta kwa kubadilisha configmap ya aws-auth.
Vitenzi vinavyohitajika ni update na patch, au create ikiwa configmap haijaundwa:
Unaweza kutumia aws-auth kwa kuendelea kutoa ufikiaji kwa watumiaji kutoka akaunti nyingine.
Hata hivyo, aws --profile other_account eks update-kubeconfig --name <cluster-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.
Kuna njia 2 za kutoa ruhusa za K8s kwa wakuu wa GCP. Katika hali yoyote mkuu pia anahitaji ruhusa container.clusters.get ili kuwa na uwezo wa kukusanya akidi za kuingia kwenye klasta, au utahitaji kuunda faili yako ya kubectl config (fuata kiungo kinachofuata).
Wakati wa kuzungumza na kiunganishi cha K8s api, token ya uthibitisho ya GCP itatumwa. Kisha, GCP, kupitia kiunganishi cha K8s api, kwanza itachunguza kama mkuu (kwa barua pepe) ana ufikiaji wowote ndani ya klasta, kisha itachunguza kama ana ufikiaji wowote kupitia GCP IAM. Ikiwa yoyote kati ya hizo ni kweli, atajibiwa. Ikiwa siyo makosa yanayopendekeza kutoa ruhusa kupitia GCP IAM yatatolewa.
Kisha, njia ya kwanza ni kutumia GCP IAM, ruhusa za K8s zina ruhusa sawa za GCP IAM, na ikiwa mkuu ana hiyo, ataweza kuitumia.
Njia ya pili ni kutoa ruhusa za K8s ndani ya klasta kwa kutambua mtumiaji kwa barua pepe yake (akaunti za huduma za GCP zimejumuishwa).
Wakuu wanaoweza kuunda TokenRequests (serviceaccounts/token) Wakati wa kuzungumza na kiunganishi cha K8s api SAs (habari kutoka hapa).
Wakuu 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.
Wakuu 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.
Kwa mfano wa mutatingwebhookconfigurations angalia sehemu hii ya chapisho hili.
Kama unavyoweza kusoma katika sehemu inayofuata: Kuzuia Kuongeza Mamlaka ya Kijadi, mkuu cannot update wala kuunda roles au clusterroles bila kuwa na ruhusa hizo mpya. Isipokuwa ikiwa ana kitenzi escalate juu ya roles au clusterroles.
Kisha anaweza kuupdate/kuunda roles mpya, clusterroles zenye ruhusa bora kuliko zile alizonazo.
Wakuu wenye ufikiaji wa nodes/proxy subresource wanaweza kutekeleza msimbo kwenye pods kupitia Kubelet API (kulingana na hii). Taarifa zaidi kuhusu uthibitisho wa Kubelet katika ukurasa huu:
Una mfano wa jinsi ya kupata RCE ukizungumza na Kubelet API hapa.
Wakuu 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 wa pods/status) na wanaweza kufanya nodes nyingine zisizoweza kupanga (ufikiaji wa nodes/status) au kufuta nodes (delete verb juu ya nodes resource) na ana udhibiti juu ya pod, wanaweza kuiba pods kutoka nodes nyingine ili ziweze kutekelezwa katika node iliyoathirika na mshambuliaji anaweza kuiba token kutoka kwa pods hizo.
Wajibu wanaoweza kubadilisha services/status wanaweza kuweka uwanja wa status.loadBalancer.ingress.ip ili kutumia CVE-2020-8554 isiyorekebishwa na kuanzisha MiTM attacks dhidi ya kluster. Mitihani nyingi za CVE-2020-8554 zinazuia tu huduma za ExternalIP (kulingana na hii).
Wajibu wenye ruhusa za update au patch juu ya nodes/status au pods/status, wanaweza kubadilisha lebo ili kuathiri vikwazo vya kupanga vilivyowekwa.
Kubernetes ina mekanismu ya ndani ya kuzuia kuongezeka kwa haki.
Mfumo huu unahakikisha kwamba watumiaji hawawezi kuongeza haki 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.
Sheria inasema kwamba mtumiaji anaweza tu kuunda au kubadilisha jukumu ikiwa ana ruhusa zote zinazohitajika na jukumu hilo. Zaidi ya hayo, upeo wa ruhusa za mtumiaji zilizopo lazima ulingane na ule wa jukumu wanajaribu kuunda au kubadilisha: ama kwa kiwango cha kluster kwa ClusterRoles au kufungwa kwenye jina moja (au kwa kiwango cha kluster) kwa Roles.
Kuna ubaguzi wa sheria ya awali. Ikiwa wajibu ana kitenzi escalate juu ya roles au clusterroles anaweza kuongeza haki za majukumu na clusterroles hata bila kuwa na ruhusa hizo mwenyewe.
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 haki ikiwa tayari huna.
Haki ya kuunda Rolebindings inamruhusu mtumiaji kuunganisha majukumu na akaunti ya huduma. Haki hii inaweza kupelekea kuongezeka kwa haki kwa sababu inaruhusu mtumiaji kuunganisha haki za usimamizi kwa akaunti ya huduma iliyovunjika.
Kwa kawaida hakuna usimbuaji katika mawasiliano kati ya pods. Uthibitishaji wa pamoja, njia mbili, kutoka pod hadi pod.
Unda yako .yaml
Hariri .yaml yako na ongeza mistari isiyo na maoni:
Tazama kumbukumbu za proxy:
More info at: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
An admission controller inakata maombi kwa seva ya API ya Kubernetes kabla ya kudumu kwa kitu, lakini baada ya maombi kuthibitishwa na kuidhinishwa.
Ikiwa mshambuliaji kwa namna fulani anafanikiwa kuingiza Mutationg Admission Controller, ataweza kubadilisha maombi ambayo tayari yameidhinishwa. Kuwa na uwezo wa kuweza privesc, na kwa kawaida kudumu katika klasta.
Mfano kutoka https://blog.rewanthtammana.com/creating-malicious-admission-controllers:
Angalia hali ili kuona kama iko tayari:
Kisha peleka pod mpya:
Wakati unaweza kuona kosa la ErrImagePull, angalia jina la picha kwa moja ya maswali yafuatayo:
Kama unavyoona katika picha hapo juu, tulijaribu kuendesha picha nginx lakini picha iliyotekelezwa mwishowe ni rewanthtammana/malicious-image. Nini kimetokea!!?
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 yaliyoshuhudiwa:
The above snippet replaces the first container image in every pod with rewanthtammana/malicious-image.
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.
Injini ya Uchaguzi: Hakikisha kuwa watumiaji muhimu pekee wanajumuishwa katika RoleBindings au ClusterRoleBindings. Kagua mara kwa mara na uondoe watumiaji wasiohusika ili kudumisha usalama mkali.
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.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
