Abusing Roles/ClusterRoles in Kubernetes
Hapa unaweza kupata mipangilio ya Majukumu na ClusterRoles inayoweza kuwa hatari.
Kumbuka unaweza kupata rasilimali zote zinazoungwa mkono kwa kutumia kubectl api-resources
Kupandisha Hadhi
Kukusudia kama sanaa ya kupata upatikanaji wa mamlaka tofauti ndani ya kikundi na mamlaka tofauti (ndani ya kikundi cha kubernetes au kwenye mawingu ya nje) kuliko zile unazo tayari, katika Kubernetes kuna msingi wa njia 4 kuu za kupandisha hadhi:
Kuweza kujifanya mtumiaji/makundi/SAs wengine wenye mamlaka bora ndani ya kikundi cha kubernetes au kwenye mawingu ya nje
Kuweza kuunda/kusahihisha/kutekeleza podi ambapo unaweza kupata au kuambatisha SAs wenye mamlaka bora ndani ya kikundi cha kubernetes au kwenye mawingu ya nje
Kuweza kusoma siri kwani vitambulisho vya SAs hufungwa kama siri
Kuweza kutoroka kwenye node kutoka kwa chombo, ambapo unaweza kuiba siri zote za vyombo vinavyotumika kwenye node, vyeti vya node, na ruhusa za node ndani ya wingu inayotumika (ikiwapo ipo)
Njia ya tano inayostahili kutajwa ni uwezo wa kutekeleza port-forward kwenye podi, kwani unaweza kuwa na uwezo wa kupata rasilimali muhimu ndani ya podi hiyo.
Kupata Rasilimali au Kitendo chochote (Wildcard)
Wildcard (*) hutoa idhini juu ya rasilimali yoyote na kitendo chochote. Hutumiwa na wasimamizi. Ndani ya ClusterRole hii inamaanisha kwamba mshambuliaji anaweza kutumia eneo lolote katika kikundi
Pata Upatikanaji wa Rasilimali Yoyote na kitendo maalum
Katika RBAC, idhini fulani zinaleta hatari kubwa:
create: Inatoa uwezo wa kuunda rasilimali yoyote ya kikundi, ikileta hatari ya kupandishwa kwa mamlaka.list: Inaruhusu orodha ya rasilimali zote, ikileta hatari ya kuvuja kwa data nyeti.get: Inaruhusu kupata siri kutoka kwa akaunti za huduma, ikileta tishio la usalama.
Kujenga Podi - Kuiba Kitufe
Mshambuliaji mwenye ruhusa ya kujenga podi, anaweza kuambatanisha Akaunti ya Huduma yenye mamlaka ndani ya podi na kuiba kitufe ili kujifanya kuwa Akaunti ya Huduma. Kimsingi kuongeza mamlaka kwake
Mfano wa podi ambayo itaiba kitufe cha akaunti ya huduma ya bootstrap-signer na kukituma kwa mshambuliaji:
Kuunda na Kutoroka Kwenye Podi
Yafuatayo yanabainisha mamlaka yote ambayo kontena inaweza kuwa nayo:
Upatikanaji wa mamlaka (kulemaza ulinzi na kuweka uwezo)
Lemaza hostIPC na hostPid ambayo inaweza kusaidia kuinua mamlaka
Lemaza hostNetwork namespace, ikitoa ufikiaji wa kuiba mamlaka ya wingu la node na ufikiaji bora wa mitandao
Pachika / ya mwenyeji ndani ya kontena
Unda podi na:
Mstari mmoja kutoka twee hii na na baadhi ya marekebisho:
Sasa unaweza kutoroka kwa mbinu za ukaguzi wa baada ya uharibifu kwenye node:
Kujificha
Labda unataka kuwa mzito zaidi, kwenye kurasa zifuatazo unaweza kuona unachoweza kupata ufikiaji ikiwa utaunda podu ikiwezesha baadhi ya ruhusa zilizotajwa katika templeti iliyotangulia:
Ruhusa + hostPID
Ruhusa pekee
hostPath
hostPID
hostNetwork
hostIPC
Unaweza kupata mfano wa jinsi ya kuunda/kutumia mizunguko ya podu iliyopewa ruhusa hapo awali katika https://github.com/BishopFox/badPods
Kuunda Podu - Hamia kwenye wingu
Ikiwa unaweza kuunda podu (na hiari akaunti ya huduma) unaweza kuwa na uwezo wa kupata ruhusa katika mazingira ya wingu kwa kupitisha majukumu ya wingu kwa podu au akaunti ya huduma na kisha kufikia. Zaidi ya hayo, ikiwa unaweza kuunda podu na nafasi ya mtandao wa mwenyeji unaweza kuiba jukumu la IAM la mfano wa node.
Kwa habari zaidi angalia:
pagePod Escape PrivilegesKuunda/Kurekebisha Upelekaji, Daemonsets, Statefulsets, Replicationcontrollers, Replicasets, Jobs na Cronjobs
Inawezekana kutumia vibali hivi kwa kuunda podu mpya na kudanganya ruhusa kama katika mfano uliotangulia.
Yaml ifuatayo inaunda daemonset na kuchukua tokeni ya SA ndani ya podu:
Pods Exec
pods/exec ni rasilimali katika kubernetes inayotumika kwa kutekeleza amri katika kikasha ndani ya kisanduku. Hii inaruhusu kutekeleza amri ndani ya vyombo au kupata kikasha ndani.
Hivyo basi, ni fasihi kuingia katika kisanduku na kuiba tokeni ya SA, au kuingia katika kisanduku cha kipekee, kutoroka kwenye node, na kuiba tokeni zote za visanduku kwenye node na (ku)tumia node:
port-forward
Haki hii inaruhusu kusonga mmoja wa bandari za ndani kwenda kwa bandari moja kwenye pod iliyotajwa. Hii inalenga kuwezesha kutatua matatizo ya programu zinazoendesha ndani ya pod kwa urahisi, lakini mshambuliaji anaweza kutumia vibaya kupata ufikiaji wa programu zenye umuhimu (kama DBs) au zilizo na mapungufu (mitandao?) ndani ya pod:
Weka wa Mwenyeji /var/log/ Kutoroka
Kama ilivyoelezwa katika utafiti huu, ikiwa unaweza kupata au kuunda podi na hosts /var/log/ directory imewekwa ndani yake, unaweza kutoroka kutoka kwenye chombo.
Hii ni kimsingi kwa sababu wakati Kube-API inajaribu kupata magogo ya chombo (kwa kutumia kubectl logs <pod>), inaomba faili ya 0.log ya podi kwa kutumia njia ya /logs/ ya huduma ya Kubelet.
Huduma ya Kubelet inafunua njia ya /logs/ ambayo kimsingi ni kufunua mfumo wa faili wa /var/log wa chombo.
Hivyo, mshambuliaji mwenye upatikanaji wa kuandika kwenye folda ya /var/log/ ya chombo anaweza kutumia tabia hizi kwa njia 2:
Kubadilisha faili ya
0.logya chombo chake (kawaida iko katika/var/logs/pods/namespace_pod_uid/container/0.log) iwe symlink inayoashiria/etc/shadowkwa mfano. Kisha, utaweza kuchukua faili ya kivuli ya mwenyeji kwa kufanya:
Ikiwa mshambuliaji ana udhibiti wa msingi wowote na ruhusa ya kusoma
nodes/log, anaweza tu kuunda symlink katika/host-mounted/var/log/symkwenda/na wakati wa kufikiahttps://<gateway>:10250/logs/sym/atapata orodha ya mfumo wa mizizi wa mwenyeji (kubadilisha symlink inaweza kutoa ufikiaji wa faili).
Maabara na shambulizi lililoautomatiki linaweza kupatikana katika https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts
Kupitisha ulinzi wa readOnly
Ikiwa una bahati ya kutosha na uwezo wa uwezo uliopewa kwa kiwango kikubwa CAP_SYS_ADMIN upo, unaweza tu kurejesha upya folda kama rw:
Kupitisha ulinzi wa hostPath readOnly
Kama ilivyoelezwa katika utafiti huu niwezekanavyo kupitisha ulinzi:
Ambayo ilikuwa imekusudiwa kuzuia kutoroka kama ile za awali, badala ya kutumia ujumuishaji wa hostPath, tumia PersistentVolume na PersistentVolumeClaim kuunganisha folda za mwenyeji kwenye chombo na ufikiaji wa kuandika:
Kujifanya kuwa akaunti zenye mamlaka
Kwa ujanja wa mtumiaji wa mamlaka, mkaidi anaweza kujifanya kuwa akaunti yenye mamlaka.
Tumia kipengele --as=<jina la mtumiaji> katika amri ya kubectl kujifanya kuwa mtumiaji, au --as-group=<kikundi> kujifanya kuwa kikundi:
Au tumia REST API:
Kupata Siri
Ruhusa ya kupata siri inaweza kuruhusu mshambuliaji kusoma siri hizo kwa kufikia kipengele cha API ya REST:
Kusoma siri - kufanya nguvu kwa token IDs
Mtu anayeshambulia aliye na token yenye ruhusa ya kusoma anahitaji jina sahihi la siri kutumia, tofauti na ruhusa pana ya kutaja siri, bado kuna udhaifu. Akaunti za huduma za msingi katika mfumo zinaweza kuhesabiwa, kila moja ikihusishwa na siri. Siri hizi zina muundo wa jina: kipimo cha msingi kifuatiwacho na token ya herufi tano za nambari na herufi (isipokuwa herufi fulani) kulingana na msimbo wa chanzo.
Token hutengenezwa kutoka kwa seti iliyopunguzwa ya herufi 27 (bcdfghjklmnpqrstvwxz2456789), badala ya safu kamili ya nambari na herufi. Kikomo hiki hupunguza jumla ya mchanganyiko uwezekanao hadi 14,348,907 (27^5). Kwa hivyo, mtu anayeshambulia anaweza kutekeleza shambulio la nguvu kwa urahisi kudokeza token katika masaa machache, ikisababisha uwezekano wa kupanda hadhi kwa kupata akaunti nyeti za huduma.
Maombi ya Kusaini Cheti
Ikiwa una vitenzi umba katika rasilimali certificatesigningrequests (au angalau katika certificatesigningrequests/nodeClient). Unaweza kuunda CeSR mpya ya node mpya.
Kulingana na nyaraka inawezekana kuidhinisha maombi haya moja kwa moja, hivyo katika kesi hiyo hauitaji ruhusa ziada. Vinginevyo, utahitaji kuweza kuidhinisha ombi, ambalo linamaanisha kusasisha katika certificatesigningrequests/approval na idhinisha katika signers na jina la rasilimali <signerNameDomain>/<signerNamePath> au <signerNameDomain>/*
Mfano wa jukumu lenye ruhusa zote zinazohitajika ni:
Kwa hivyo, na CSR mpya ya node ikiridhishwa, unaweza kutumia vibaya ruhusa maalum za nodes ili kuiba siri na kupandisha viwango vya ruhusa.
Katika chapisho hili na hili lingine usanidi wa GKE K8s TLS Bootstrap umesanidiwa na kuidhinisha kiotomatiki na inatumiwa kuzalisha sifa za Node mpya ya K8s na kisha kutumia hizo kwa kupandisha viwango vya ruhusa kwa kuiba siri. Ikiwa una ruhusa zilizotajwa unaweza kufanya kitu kama hicho. Tafadhali kumbuka kuwa mfano wa kwanza unapuuza kosa linalozuia node mpya kupata siri ndani ya vyombo kwa sababu node inaweza tu kupata siri za vyombo vilivyofungwa kwake.
Njia ya kuzidi hili ni kwa kusimamisha tu sifa za node kwa jina la node ambapo chombo chenye siri za kuvutia kimefungwa ( lakini angalia jinsi ya kufanya hivyo katika chapisho la kwanza):
AWS EKS aws-auth configmaps
Wahusika wanaoweza kuhariri configmaps katika eneo la kube-system kwenye mizizi ya EKS (inahitaji kuwa kwenye AWS) wanaweza kupata mamlaka ya msimamizi wa mizizi kwa kubadilisha configmap ya aws-auth. Vibweta vinavyohitajika ni update na patch, au create ikiwa configmap haikuundwa:
Unaweza kutumia aws-auth kwa uthabiti kutoa upatikanaji kwa watumiaji kutoka akaunti nyingine.
Hata hivyo, aws --profile other_account eks update-kubeconfig --name <jina-la-kikundi> haitafanya kazi kutoka kwenye akaunti tofauti. Lakini kwa kweli aws --profile other_account eks get-token --cluster-name arn:aws:eks:us-east-1:123456789098:cluster/Testing inafanya kazi ikiwa unaweka ARN ya kikundi badala ya jina tu.
Ili kufanya kubectl ifanye kazi, hakikisha tu kuweka mazingira ya kubeconfig ya waathiriwa na katika vigezo vya aws exec ongeza --profile other_account_role ili kubectl itumie wasifu wa akaunti nyingine kupata token na kuwasiliana na AWS.
Kuongeza Mamlaka katika GKE
Kuna njia 2 za kutoa ruhusa za K8s kwa mawakala wa GCP. Katika kila kesi, mawakala pia wanahitaji ruhusa ya container.clusters.get ili waweze kukusanya vibali vya kupata kikundi, au utahitaji kuunda faili yako ya kikundi cha kubectl (fuata kiungo kifuatacho).
Unapozungumza na kisitiri cha api cha K8s, tokeni ya uthibitishaji wa GCP itatumwa. Kisha, GCP, kupitia kisitiri cha api cha K8s, kwanza itaangalia ikiwa mawakala (kwa barua pepe) ana upatikanaji wowote ndani ya kikundi, kisha itaangalia ikiwa ana upatikanaji wowote kupitia GCP IAM. Ikiwa mojawapo ya hizo ni kweli, atajibiwa. Ikiwa sivyo kosa linalopendekeza kutoa ruhusa kupitia GCP IAM litatolewa.
Kisha, njia ya kwanza ni kutumia GCP IAM, ruhusa za K8s zina ruhusa sawa za GCP IAM, na ikiwa mawakala anazo, ataweza kuzitumia.
pageGCP - Container PrivescNjia ya pili ni kutoa ruhusa za K8s ndani ya kikundi kwa kutambua mtumiaji kwa barua pepe yake (akaunti za huduma za GCP pia zimejumuishwa).
Unda kitufe cha akaunti ya huduma
Mawakala wanaoweza kuunda Ombi la Kitufe (serviceaccounts/token) Wanapozungumza na kisitiri cha api cha K8s SAs (habari kutoka hapa).
ephemeralcontainers
Mawakala wanaoweza kuboresha au kupachika pods/ephemeralcontainers wanaweza kupata utekelezaji wa nambari kwenye podi zingine, na kwa uwezekano kuvunja kwenye nodi yao kwa kuongeza chombo cha muda mfupi na muktadha wa usalama uliopewa ruhusa
ValidatingWebhookConfigurations au MutatingWebhookConfigurations
Mawakala wenye vitendo vyovyote vya kuunda, kuboresha au kupachika juu ya validatingwebhookconfigurations au mutatingwebhookconfigurations wanaweza kuwa na uwezo wa kuunda moja ya webhookconfigurations ili kuweza kuongeza mamlaka.
Kwa mfano wa mutatingwebhookconfigurations angalia sehemu hii ya chapisho hili.
Kuongeza
Kama unavyoweza kusoma katika sehemu ifuatayo: Kuzuia Kuongezeka kwa Mamlaka Imejengwa, mawakala hawezi kusasisha wala kuunda majukumu au majukumu ya kikundi bila kuwa na vibali vipya hivyo. Isipokuwa ikiwa ana kitendo kuongeza juu ya majukumu au majukumu ya kikundi.
Kisha anaweza kusasisha/kuunda majukumu mapya, majukumu ya kikundi na vibali bora kuliko vile alivyo navyo.
Nodi za proksi
Mawakala wenye upatikanaji wa nodes/proxy subresource wanaweza kutekeleza nambari kwenye podi kupitia API ya Kubelet (kulingana na hii). Taarifa zaidi kuhusu uthibitishaji wa Kubelet katika ukurasa huu:
Unayo mfano wa jinsi ya kupata RCE ukiwa umethibitishwa kwa API ya Kubelet hapa.
Futa podi + nodi zisizoweza kuhesabiwa
Mawakala wanaoweza kufuta podi (futa kitendo juu ya rasilimali ya pods), au kufukuza podi (unda kitendo juu ya rasilimali ya pods/eviction), au badilisha hali ya podi (upatikanaji wa pods/status) na wanaweza kuifanya nodi zingine zisizoweza kuhesabiwa (upatikanaji wa nodes/status) au kufuta nodi (futa kitendo juu ya rasilimali ya nodes) na wana udhibiti juu ya podi, wanaweza kuiba podi kutoka kwenye nodi zingine ili ziwe zinatekelezwa kwenye nodi iliyoharibiwa na mkaidi anaweza kuiba vibali kutoka kwa podi hizo.
Hali ya Huduma (CVE-2020-8554)
Wahusika wanaoweza kurekebisha huduma/hali wanaweza kuweka uga wa status.loadBalancer.ingress.ip kutumia CVE-2020-8554 ambayo haijasahihishwa na kuanzisha mashambulizi ya MiTM dhidi ya kikundi. Hatua nyingi za kuzui CVE-2020-8554 zinazuia huduma za ExternalIP tu (kulingana na hii).
Hali za Nodes na Pods
Wahusika wenye ruhusa za sasisha au patch juu ya nodes/hali au pods/hali, wanaweza kurekebisha lebo ili kuathiri vikwazo vya upangaji vilivyowekwa.
Kuzuia Kupandishwa Kwa Hadhi Kujengwa Ndani
Kubernetes ina mfumo uliojengwa wa kuzuia kupandishwa kwa hadhi.
Mfumo huu unahakikisha kwamba watumiaji hawawezi kuinua hadhi zao kwa kurekebisha majukumu au vifungo vya majukumu. Utekelezaji wa sheria hii hufanyika kwenye kiwango cha API, kutoa kinga hata wakati msimamizi wa RBAC hajafanya kazi.
Sheria inabainisha kwamba mtumiaji anaweza tu kuunda au kusasisha jukumu ikiwa wanamiliki ruhusa zote zinazojumuisha jukumu hilo. Zaidi ya hayo, wigo wa ruhusa za mtumiaji uliopo lazima uendane na ule wa jukumu wanajaribu kuunda au kurekebisha: ama kwa kiwango cha kikundi kwa ClusterRoles au kikwazo kwa eneo moja (au kikundi kwa kiwango cha kikundi) kwa Roles.
Kuna ubaguzi kwa sheria iliyotangulia. Ikiwa msingi ana kitenzi inua juu ya majukumu au majukumu ya kikundi anaweza kuongeza hadhi ya majukumu na majukumu ya kikundi hata bila kuwa na ruhusa mwenyewe.
Pata & Sasisha Vifungo vya Majukumu/Majukumu ya Kikundi
Inaonekana mbinu hii ilifanya kazi hapo awali, lakini kulingana na majaribio yangu sasa haifanyi kazi tena kwa sababu ile ile iliyoelezwa katika sehemu iliyotangulia. Huwezi kuunda/kurekebisha kifungo cha jukumu kumpa wewe mwenyewe au SA tofauti baadhi ya ruhusa ikiwa huna tayari.
Ruhusa ya kuunda Vifungo vya Majukumu inamruhusu mtumiaji kufunga majukumu kwa akaunti ya huduma. Ruhusa hii inaweza kusababisha kupandishwa kwa hadhi kwa sababu inamruhusu mtumiaji kufunga ruhusa za msimamizi kwa akaunti ya huduma iliyoharibiwa.
Mashambulizi Mengine
Programu ya upande wa pembeni
Kwa chaguo-msingi hakuna usimbaji katika mawasiliano kati ya makasha. Uthibitisho wa pande zote, podi hadi podi.
Unda programu ya upande wa pembeni
Unda faili yako .yaml
Hariri faili yako .yaml na ongeza mistari isiyokuwa na maoni:
Angalia kumbukumbu za proksi:
Maelezo zaidi kwenye: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
Msimamizi wa Udhibiti wa Kuingilia kati wa Nia Mbaya
Msimamizi wa kuingilia kati huzuia maombi kwa seva ya API ya Kubernetes kabla ya kudumu kwa kitu, lakini baada ya ombi kuthibitishwa na kuruhusiwa.
Ikiwa mshambuliaji kwa namna fulani anafanikiwa kuingiza Msimamizi wa Kuingilia kati wa Kugeuza, ataweza kurekebisha maombi yaliyothibitishwa tayari. Kwa kuwa na uwezo wa kuboresha hali, na mara nyingi kudumu kwenye kikundi.
Mfano kutoka https://blog.rewanthtammana.com/creating-malicious-admission-controllers:
Angalia hali ili uone ikiwa iko tayari:
Kisha tumia pod mpya:
Wakati unapoona kosa la ErrImagePull, angalia jina la picha kwa kutumia mojawapo ya maswali yafuatayo:
Kama unavyoweza kuona kwenye picha hapo juu, tulijaribu kukimbia picha ya nginx lakini picha iliyotekelezwa mwishowe ni rewanthtammana/malicious-image. Kilichotokea!!
Technicalities
Skripti ya ./deploy.sh inaanzisha kudhibiti kibali cha kuingiza kibali, ambacho hubadilisha maombi kwa API ya Kubernetes kama ilivyoelezwa katika mistari yake ya usanidi, ikichochea matokeo yanayoonekana:
Mbinu Bora
Kulemaza Automount ya Vitambulisho vya Akaunti ya Huduma
Pods na Akaunti za Huduma: Kwa chaguo-msingi, pods hufunga kitambulisho cha akaunti ya huduma. Ili kuboresha usalama, Kubernetes inaruhusu kulemaza kipengele hiki cha automount.
Jinsi ya Kuomba: Weka
automountServiceAccountToken: falsekatika usanidi wa akaunti za huduma au pods kuanzia toleo la Kubernetes 1.6.
Uteuzi wa Mtumiaji wa Kizuizi katika RoleBindings/ClusterRoleBindings
Kuingizwa kwa Hiari: Hakikisha kuwa watumiaji muhimu pekee ndio wanaojumuishwa katika RoleBindings au ClusterRoleBindings. Fanya ukaguzi mara kwa mara na ondoa watumiaji wasiohusika ili kudumisha usalama thabiti.
Vitu vya Majukumu Maalum kwa Majukumu ya Kikundi kwa Upanuzi wa Kikoa
Majukumu dhidi ya Majukumu ya Kikundi: Pendekeza kutumia Majukumu na RoleBindings kwa ruhusa za kikoa maalum badala ya ClusterRoles na ClusterRoleBindings, ambayo yanatumika kwa upana wa kikundi. Mbinu hii hutoa udhibiti bora na kikomo cha ruhusa.
Tumia zana za kiotomatiki
Vyanzo
Last updated