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
Inahusu sanaa ya kupata upatikanaji wa mamlaka tofauti ndani ya kikundi na mamlaka tofauti (ndani ya kikundi cha kubernetes au kwenye mawingu ya nje) kuliko zile unazo tayari, katika Kubernetes kuna msingi wa njia 4 kuu za kupandisha hadhi:
Kuweza kujifanya mtumiaji/makundi/SAs wengine wenye mamlaka bora ndani ya kikundi cha kubernetes au kwenye mawingu ya nje
Kuweza kuunda/kusahihisha/kuendesha podi ambapo unaweza kupata au kuambatanisha SAs wenye mamlaka bora ndani ya kikundi cha kubernetes au kwenye mawingu ya nje
Kuweza kusoma siri kwani vitambulisho vya SAs vinahifadhiwa kama siri
Kuweza kutoroka kwenye node kutoka kwa kontena, ambapo unaweza kuiba siri zote za kontena zinazoendeshwa kwenye node, vyeti vya node, na ruhusa za node ndani ya wingu inayoendeshwa (ikiwapo ipo)
Njia ya tano inayostahili kutajwa ni uwezo wa kutekeleza port-forward kwenye podi, kwani unaweza kupata rasilimali za kuvutia ndani ya podi hiyo.
Kupata Rasilimali au Kitendo chochote (Wildcard)
Wildcard (*) inatoa idhini juu ya rasilimali yoyote na kitendo chochote. Hutumiwa na wasimamizi. Ndani ya ClusterRole hii inamaanisha kwamba mshambuliaji anaweza kutumia nafasi yoyote katika kikundi
Pata Upatikanaji wa Rasilimali Yoyote na kitenzi maalum
Katika RBAC, idhini fulani zinaleta hatari kubwa:
create
: Inatoa uwezo wa kuunda rasilimali yoyote ya kikundi, ikileta hatari ya uongezaji wa mamlaka.list
: Inaruhusu orodha ya rasilimali zote, ikitoa uwezekano wa 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:
Kujenga & Kutoroka Pod
Yafuatayo inaonyesha mamlaka yote ambayo chombo kinaweza kuwa nacho:
Upatikanaji wa haki maalum (kulemaza ulinzi na kuweka uwezo)
Lemaza majina ya nafasi hostIPC na hostPid ambayo inaweza kusaidia kuinua mamlaka
Lemaza nafasi ya hostNetwork, ikitoa ufikiaji wa kuiba mamlaka ya wingu la nodes na ufikiaji bora wa mitandao
Funga / ya wenyeji ndani ya chombo
Unda podi na:
Mstari mmoja kutoka uandishi huu na pamoja na baadhi ya marekebisho:
Sasa unaweza kutoroka kwa mbinu za post-exploitation kwenye node:
Kujificha
Labda unataka kuwa mwenye kujificha zaidi, kwenye kurasa zifuatazo unaweza kuona unachoweza kupata ufikiaji ikiwa utaunda pod ukiwezesha baadhi ya mamlaka zilizotajwa katika templeti iliyotangulia:
Mamlaka + hostPID
Mamlaka pekee
hostPath
hostPID
hostNetwork
hostIPC
Unaweza kupata mfano wa jinsi ya kuunda/kutumia mazingira ya pods yenye mamlaka ya awali katika https://github.com/BishopFox/badPods
Kuunda Pod - Hamia kwenye wingu
Ikiwa unaweza kuunda pod (na hiari akaunti ya huduma) unaweza kuwa na uwezo wa kupata mamlaka katika mazingira ya wingu kwa kutenga majukumu ya wingu kwa pod au akaunti ya huduma na kisha kufikia. Zaidi ya hayo, ikiwa unaweza kuunda pod na nafasi ya mtandao wa mwenyeji unaweza kuiba jukumu la IAM la mfano wa node.
Kwa maelezo zaidi angalia:
Pod Escape PrivilegesKuunda/Kurekebisha Upelekaji, Daemonsets, Statefulsets, Replicationcontrollers, Replicasets, Jobs na Cronjobs
Inawezekana kutumia vibali hivi kwa kuunda pod mpya na kudanganya mamlaka kama katika mfano uliotangulia.
Yaml ifuatayo inaunda daemonset na kufichua token ya SA ndani ya pod:
Kutekeleza Pods
pods/exec
ni rasilimali katika kubernetes inayotumika kwa kutekeleza amri katika kifuniko ndani ya podi. Hii inaruhusu kutekeleza amri ndani ya vyombo au kupata kifuniko ndani.
Hivyo basi, ni fasihi kuingia ndani ya podi na kuiba tokeni ya SA, au kuingia katika podi yenye mamlaka, kutoroka kwenye node, na kuiba tokeni zote za podi kwenye node na (ku)abusa node:
port-forward
Haki hii inaruhusu kupeleka bandari moja ya ndani kwenda kwa bandari moja kwenye pod iliyotajwa. Hii inalenga kuwezesha kutatua matatizo ya programu zinazoendeshwa ndani ya pod kwa urahisi, lakini mshambuliaji anaweza kuitumia vibaya kupata ufikivu wa programu zenye umuhimu (kama DBs) au zilizo na mapungufu (mitandao?) ndani ya pod:
Weka wa Mwenyeji /var/log/ Kutoroka
Kama ilivyo onyeshwa katika utafiti huu, ikiwa unaweza kupata au kuunda podi na hosts /var/log/
directory imemount ndani yake, unaweza kutoroka kutoka kwenye kontena.
Hii ni kimsingi kwa sababu wakati Kube-API inajaribu kupata logs ya kontena (ikitumia kubectl logs <pod>
), ina omba faili ya 0.log
ya podi kwa kutumia endpoint ya /logs/
ya huduma ya Kubelet.
Huduma ya Kubelet inafunua endpoint ya /logs/
ambayo kimsingi ni kufunua mfumo wa faili wa /var/log
wa kontena.
Hivyo, mshambuliaji mwenye upatikanaji wa kuandika kwenye folda ya /var/log/ ya kontena anaweza kutumia tabia hizi kwa njia 2:
Kubadilisha faili ya
0.log
ya kontena yake (kawaida iko katika/var/logs/pods/namespace_pod_uid/container/0.log
) iwe symlink inayoashiria/etc/shadow
kwa mfano. Kisha, utaweza kuchukua faili ya kivuli ya mwenyeji kwa kufanya:
Ikiwa mshambuliaji ana udhibiti wa msingi wowote wenye ruhusa ya kusoma
nodes/log
, anaweza tu kuunda symlink katika/host-mounted/var/log/sym
kwenda/
na wakati akipatahttps://<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 kipekee wa CAP_SYS_ADMIN
upo, unaweza tu kurejesha upya folda kama rw:
Kupita kinga ya kusoma tu ya hostPath
Kama ilivyoelezwa katika utafiti huu ni rahisi kupita kinga:
Kile kilimaanisha kuzuia kutoroka kama vile za awali kwa badala ya kutumia kifungu cha hostPath, tumia PersistentVolume na PersistentVolumeClaim kuunganisha folda za mwenyeji kwenye chombo na ufikiaji wa kuandika:
Kujifanya kuwa akaunti zenye mamlaka
Kwa ujifanya kuwa mtumiaji mamlaka, mkaidi anaweza kujifanya kuwa akaunti yenye mamlaka.
Tumia parameter --as=<jina_la_mtumiaji>
katika amri ya kubectl
kujifanya kuwa mtumiaji, au --as-group=<kundi>
kujifanya kuwa kundi:
Au tumia REST API:
Orodha ya Siri
Ruhusa ya kuorodhesha siri inaweza kuruhusu mshambuliaji kusoma siri kwa kupata mwisho wa REST API:
Kusoma siri - kufanya nguvu kwa token IDs
Wakati mshambuliaji mwenye kitambulisho chenye ruhusa ya kusoma anahitaji jina sahihi la siri ili kuitumia, tofauti na ruhusa pana ya kutaja siri, bado kuna udhaifu. Akaunti za huduma za msingi katika mfumo zinaweza kuhesabiwa, kila moja ikihusishwa na siri. Siri hizi zina muundo wa jina: kipimo cha msingi kifuatiwacho na token la herufi tano za nambari na herufi (isipokuwa herufi fulani) kulingana na msimbo wa chanzo.
Token hutengenezwa kutoka kwa seti iliyopunguzwa ya herufi 27 (bcdfghjklmnpqrstvwxz2456789
), badala ya safu kamili ya nambari na herufi. Kikomo hiki hupunguza jumla ya mchanganyiko uwezekanao hadi 14,348,907 (27^5). Kwa hivyo, mshambuliaji anaweza kutekeleza shambulio la nguvu kwa urahisi kudokeza token katika masaa machache, ikisababisha ukuaji wa ruhusa kwa kupata akaunti nyeti za huduma.
Maombi ya Kusaini Cheti
Ikiwa una vitenzi umba
katika rasilimali certificatesigningrequests
(au angalau katika certificatesigningrequests/nodeClient
). Unaweza kuunda CeSR mpya ya node mpya.
Kulingana na nyaraka inawezekana kuidhinisha maombi haya moja kwa moja, hivyo katika kesi hiyo hauitaji ruhusa ziada. Vinginevyo, utahitaji kuweza kuidhinisha ombi, ambalo linamaanisha kusasisha katika certificatesigningrequests/approval
na idhinisha
katika signers
na jina la rasilimali <signerNameDomain>/<signerNamePath>
au <signerNameDomain>/*
Mfano wa jukumu lenye ruhusa zote zinazohitajika ni:
Kwa hivyo, na CSR mpya ya node ikiridhishwa, unaweza kutumia vibaya ruhusa maalum za nodes ili kuiba siri na kupandisha viwango vya ruhusa.
Katika chapisho hili na hili lingine usanidi wa GKE K8s TLS Bootstrap umesanidiwa na kuidhinisha moja kwa moja na kutumika kuzalisha sifa za Node mpya ya K8s na kisha kutumia hizo kwa kupandisha viwango vya ruhusa kwa kuiba siri. Ikiwa una ruhusa zilizotajwa unaweza kufanya kitu kama hicho. Tafadhali elewa kuwa mfano wa kwanza unapuuza kosa linalozuia node mpya kupata siri ndani ya vyombo kwa sababu node inaweza tu kupata siri za vyombo vilivyowekwa kwenye node hiyo.
Njia ya kuipuuza hii ni tu kuunda sifa za node kwa jina la node ambapo chombo chenye siri za kuvutia kimeunganishwa ( lakini angalia jinsi ya kufanya hivyo katika chapisho la kwanza):
AWS EKS aws-auth configmaps
Washiriki ambao wanaweza kuhariri configmaps
katika nafasi ya kube-system kwenye mizizi ya EKS (inahitaji kuwa kwenye AWS) wanaweza kupata mamlaka ya msimamizi wa mizizi kwa kubadilisha aws-auth configmap. Vibambo vinavyohitajika ni update
na patch
, au create
ikiwa configmap haikuundwa:
Unaweza kutumia aws-auth
kwa uthabiti kumpa mtumiaji kutoka akaunti nyingine.
Hata hivyo, aws --profile other_account eks update-kubeconfig --name <cluster-name>
haitafanya kazi kutoka kwenye akaunti tofauti. Lakini kwa kweli aws --profile other_account eks get-token --cluster-name arn:aws:eks:us-east-1:123456789098:cluster/Testing
inafanya kazi ikiwa utaweka ARN ya kikundi badala ya jina tu.
Ili kufanya kubectl
ifanye kazi, hakikisha tu umeweka vipimo vya kubeconfig vya waathiriwa na katika vipimo vya aws exec ongeza --profile other_account_role
ili kubectl itumie wasifu wa akaunti nyingine kupata token na kuwasiliana na AWS.
Kuongeza Mamlaka katika GKE
Kuna njia 2 za kutoa ruhusa za K8s kwa mawakala wa GCP. Katika kila kesi, mawakala pia wanahitaji ruhusa ya container.clusters.get
ili waweze kukusanya vyeti vya kupata kikundi, au utahitaji kuunda faili yako ya usanidi wa kubectl (fuata kiungo kifuatacho).
Unapozungumza na kituo cha api cha K8s, kitambulisho cha GCP kitatumwa. Kisha, GCP, kupitia kituo cha api cha K8s, kwanza itaangalia kama mawakala (kwa barua pepe) ana ufikiaji wowote ndani ya kikundi, kisha itaangalia kama ana ufikiaji wowote kupitia GCP IAM. Ikiwa mojawapo ya hizo ni kweli, atajibiwa. Ikiwa sivyo, kosa linalopendekeza kutoa ruhusa kupitia GCP IAM litatolewa.
Kisha, njia ya kwanza ni kutumia GCP IAM, ruhusa za K8s zina ruhusa sawa za GCP IAM, na ikiwa mawakala anazo, ataweza kuzitumia.
GCP - Container 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 kitambulisho cha huduma ya token
Mawakala wanaoweza kuunda Maombi ya Alama (serviceaccounts/token
) Wanapozungumza na kituo cha api cha K8s SAs (habari kutoka hapa).
ephemeralcontainers
Mawakala wanaoweza kuboresha
au kupatch
pods/ephemeralcontainers
wanaweza kupata utekelezaji wa nambari kwenye podi zingine, na kwa uwezekano kuvunja kwenye nodi yao kwa kuongeza chombo cha muda mfupi na muktadha wa usalama uliopewa ruhusa
ValidatingWebhookConfigurations au MutatingWebhookConfigurations
Mawakala wenye mojawapo ya vitenzi umba
, sasisha
au patch
juu ya validatingwebhookconfigurations
au mutatingwebhookconfigurations
wanaweza kuunda mojawapo ya webhookconfigurations ili kuweza kuongeza mamlaka.
Kwa mfano wa mutatingwebhookconfigurations
angalia sehemu hii ya chapisho hili.
Kuongeza
Kama unavyoweza kusoma katika sehemu ifuatayo: Kuzuia Kuongezeka kwa Mamlaka Imejengwa, mawakala hawezi kusasisha wala kuunda majukumu au majukumu ya kikundi bila kuwa na ruhusa mpya. Isipokuwa ikiwa ana kitenzi kuongeza
juu ya majukumu
au majukumu ya kikundi
.
Kisha anaweza kusasisha/kujenga majukumu mapya, majukumu ya kikundi na ruhusa bora kuliko zile alizo nazo.
Nodes proxy
Mawakala wenye ufikiaji wa nodes/proxy
subresource wanaweza kutekeleza nambari kwenye podi kupitia API ya Kubelet (kulingana na hii). Taarifa zaidi kuhusu uthibitishaji wa Kubelet katika ukurasa huu:
Unayo mfano wa jinsi ya kupata RCE ukiwa umethibitishwa kwa API ya Kubelet hapa.
Futa podi + nodes zisizoweza kuhudumiwa
Mawakala wanaoweza kufuta podi (futa
kitenzi juu ya rasilimali ya pods
), au kufukuza podi (umba
kitenzi juu ya rasilimali ya pods/eviction
), au badilisha hali ya podi (ufikiaji wa pods/status
) na wanaweza kufanya nodes zingine zisizoweza kuhudumiwa (ufikiaji wa nodes/status
) au kufuta nodes (futa
kitenzi juu ya rasilimali ya nodes
) na wana udhibiti juu ya podi, wanaweza kuiba podi kutoka kwenye nodes zingine ili ziwe zinatekelezwa kwenye nodi iliyoharibiwa na mkaidi anaweza kuiba vibali kutoka kwa podi hizo.
Hali ya Huduma (CVE-2020-8554)
Wahusika wanaoweza kurekebisha huduma/hali
wanaweza kuweka uga wa status.loadBalancer.ingress.ip
kutumia CVE-2020-8554 isiyosahihishwa na kuanzisha mashambulizi ya MiTM dhidi ya kikundi. Hatua nyingi za kupunguza hatari za CVE-2020-8554 zinazuia huduma za ExternalIP tu (kulingana na hii).
Hali za Nodes na Pods
Wahusika wenye ruhusa za sasisha
au patch
juu ya nodes/hali
au pods/hali
, wanaweza kurekebisha lebo ili kuathiri vikwazo vya upangaji vilivyowekwa.
Kuzuia Kupandishwa Hadhi kwa Mamlaka Imejengwa
Kubernetes ina mfumo uliojengwa wa kuzuia kupandishwa kwa mamlaka.
Mfumo huu huhakikisha kwamba watumiaji hawawezi kuinua mamlaka yao kwa kurekebisha majukumu au vifungo vya majukumu. Utekelezaji wa kizuizi hiki hufanyika kwenye kiwango cha API, kutoa kinga hata wakati msanidi wa RBAC hajafanya kazi.
Kizuizi hicho kinaeleza kwamba mtumiaji anaweza tu kuunda au kusasisha jukumu ikiwa wanamiliki ruhusa zote zinazojumuisha jukumu hilo. Zaidi ya hayo, wigo wa ruhusa za sasa za mtumiaji lazima lingane na ule wa jukumu wanajaribu kuunda au kurekebisha: ama kwa kiwango cha kikundi kwa ClusterRoles au imefungwa kwa eneo moja (au kwa kiwango cha kikundi) kwa Majukumu.
Kuna ubaguzi kwa kizuizi cha awali. Ikiwa muhimu ana kitenzi pandisha
juu ya majukumu
au majukumu ya kikundi
anaweza kuongeza mamlaka ya majukumu na majukumu ya kikundi hata bila kuwa na ruhusa mwenyewe.
Pata & Sasisha Vifungo vya Majukumu/Majukumu ya Kikundi
Inavyoonekana hii mbinu ilifanya kazi hapo awali, lakini kulingana na majaribio yangu sasa haifanyi kazi tena kwa sababu ile ile iliyoelezwa katika sehemu iliyotangulia. Huwezi kuunda/kurekebisha kifungo cha jukumu kumpa wewe mwenyewe au SA tofauti baadhi ya ruhusa ikiwa huna tayari.
Ruhusa ya kuunda Vifungo vya Majukumu inaruhusu mtumiaji kufunga majukumu kwa akaunti ya huduma. Ruhusa hii inaweza kusababisha kupandishwa kwa mamlaka kwa sababu inamruhusu mtumiaji kufunga ruhusa za msimamizi kwa akaunti ya huduma iliyoharibiwa.
Mashambulizi Mengine
Programu ya kivinjari cha upande
Kwa chaguo-msingi hakuna usimbaji katika mawasiliano kati ya makodsi. Uthibitisho wa pande mbili, podi hadi podi.
Unda programu ya kivinjari cha upande
Unda yako .yaml
Hariri faili yako .yaml na ongeza mistari isiyokuwa imefafanuliwa:
Angalia kumbukumbu za proxi:
Maelezo zaidi katika: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
Msimamizi wa Udhibiti wa Madhara
Msimamizi wa udhibiti wa madhara huzuia maombi kwa seva ya API ya Kubernetes kabla ya kudumu kwa kitu, lakini baada ya ombi kuthibitishwa na kuruhusiwa.
Ikiwa mshambuliaji kwa namna fulani anafanikiwa kuingiza Msimamizi wa Udhibiti wa Kugeuza, ataweza kurekebisha maombi yaliyothibitishwa tayari. Kwa kuwa na uwezo wa privesc, na mara nyingi kudumu katika kikundi.
Mfano kutoka https://blog.rewanthtammana.com/creating-malicious-admission-controllers:
Angalia hali ili uone ikiwa iko tayari:
Kisha tengeneza podi 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 ./deploy.sh
inaanzisha kudhibiti kibali cha kuingiza kibali, ambacho hubadilisha maombi kwa API ya Kubernetes kama ilivyoelezwa katika mistari yake ya usanidi, ikichochea matokeo yaliyoonekana:
Kuchukua Nafasi ya Picha ya Kwanza katika Kila Kikasha na rewanthtammana/malicious-image
.
rewanthtammana/malicious-image
.Kupita kwa OPA Gatekeeper
Kubernetes - OPA Gatekeeper bypassMbinu Bora
Kulemaza Automount ya Vitambulisho vya Akaunti ya Huduma
Kikasha na Akaunti za Huduma: Kwa chaguo-msingi, kikasha huchukua kibali cha akaunti ya huduma. Ili kuboresha usalama, Kubernetes inaruhusu kulemaza kipengele hiki cha automount.
Jinsi ya Kutumia: Weka
automountServiceAccountToken: false
katika usanidi wa akaunti za huduma au kikasha kuanzia toleo la Kubernetes 1.6.
Kuwazuia Uteuzi wa Mtumiaji katika RoleBindings/ClusterRoleBindings
Kuingiza kwa Hiari: Hakikisha kuwa watumiaji muhimu pekee wamejumuishwa katika RoleBindings au ClusterRoleBindings. Fanya ukaguzi mara kwa mara na ondoa watumiaji wasiohusika ili kudumisha usalama thabiti.
Vitu vya Nafasi vya Jina la Kikasha Badala ya Vitu vya Nafasi vya Kikasha Kote
Vitu vs. Vitu vya Kikasha: Penda kutumia Vitu na RoleBindings kwa ruhusa za nafasi za jina la kikasha badala ya Vitu vya Kikasha na ClusterRoleBindings, ambavyo hutekelezwa kote kwenye kikasha. Mbinu hii hutoa udhibiti bora na kikomo cha ruhusa.
Tumia zana za kiotomatiki
Vyanzo
Last updated