Abusing Roles/ClusterRoles in Kubernetes
Hapa unaweza kupata baadhi ya mipangilio ya Roles na ClusterRoles inayoweza kuwa hatari.
Kumbuka kwamba unaweza kupata rasilimali zote zinazoungwa mkono kwa kutumia kubectl api-resources
Privilege Escalation
Inarejelea sanaa ya kupata ufikiaji wa principal tofauti ndani ya klasta ikiwa na ruhusa 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 ruhusa:
Kuwa na uwezo wa kujifanya mtumiaji/katika makundi/SAs wengine wenye ruhusa 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 ruhusa 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 zinazofanya kazi kwenye node, akidi za node, na ruhusa za node ndani ya wingu inayoendesha (ikiwa ipo)
Mbinu ya tano inayostahili kutajwa ni uwezo wa kukimbia port-forward katika pod, kwani unaweza kuwa na uwezo wa kufikia rasilimali 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
Access Any Resource with a specific verb
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.
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 inainua mamlaka kwake.
Mfano wa pod ambayo itakuwa na uwezo wa kuiba token ya akaunti ya huduma ya bootstrap-signer na kuisafirisha kwa mshambuliaji:
Pod Create & Escape
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 upatikanaji wa kuiba haki za wingu za nodi na upatikanaji bora wa mitandao
Mount hosts / ndani ya kontena
Unda pod na:
Moja kwa moja kutoka hiki tweet na nyongeza chache:
Sasa kwamba unaweza kutoroka kwenye node angalia mbinu za baada ya unyakuzi katika:
Stealth
Huenda unataka kuwa stealthier, katika kurasa zinazofuata unaweza kuona kile ambacho unaweza kufikia ikiwa utaunda pod kwa kuwezesha baadhi tu ya mamlaka yaliyotajwa katika kigezo kilichopita:
Privileged + hostPID
Privileged tu
hostPath
hostPID
hostNetwork
hostIPC
Unaweza kupata mfano wa jinsi ya kuunda/kutumia vibaya mipangilio ya pods zilizopatiwa mamlaka katika https://github.com/BishopFox/badPods
Pod Create - Hamia kwenye wingu
Ikiwa unaweza kuunda pod (na hiari akaunti ya huduma) huenda ukawa na uwezo wa kupata mamlaka 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 mfano.
Kwa maelezo zaidi angalia:
Pod Escape PrivilegesCreate/Patch Deployment, Daemonsets, Statefulsets, Replicationcontrollers, Replicasets, Jobs and Cronjobs
Inawezekana kutumia vibaya ruhusa hizi ili kuunda pod mpya na kuanzisha mamlaka kama katika mfano wa awali.
Yaml ifuatayo inaunda daemonset na inatoa token ya SA ndani ya pod:
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.
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:
port-forward
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:
Hosts Writable /var/log/ Escape
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 ya 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.logla kontena lake (ambalo kawaida liko katika/var/logs/pods/namespace_pod_uid/container/0.log) kuwa symlink inayotaja/etc/shadowkwa mfano. Kisha, utaweza kutoa 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/symhadi/na wakati anapofikiahttps://<gateway>:10250/logs/sym/atataja mfumo wa faili wa mzizi 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
Kupita ulinzi wa readOnly
Ikiwa una bahati na uwezo wa juu wa `CAP_SYS_ADMIN upo, unaweza tu kuunganisha tena folda hiyo kama rw:
Bypassing hostPath readOnly protection
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:
Kujifanya kuwa akaunti zenye mamlaka
Kwa kutumia ujumbe wa kujifanya mamlaka, mshambuliaji anaweza kujifanya kuwa akaunti yenye mamlaka.
Tumia tu parameter --as=<username> katika amri ya kubectl kujifanya kuwa mtumiaji, au --as-group=<group> kujifanya kuwa kundi:
Au tumia API ya REST:
Listing Secrets
Ruhusa ya kuorodhesha siri inaweza kumruhusu mshambuliaji kusoma siri hizo kwa kufikia mwisho wa API ya REST:
Kusoma siri – kujaribu nguvu za IDs za token
Wakati mshambuliaji mwenye token yenye ruhusa za kusoma anahitaji jina sahihi la siri ili kuweza 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 kujaribu nguvu ili kubaini token hiyo ndani ya masaa machache, ambayo inaweza kusababisha kupandishwa vyeo kwa kufikia akaunti za huduma nyeti.
Maombi ya Kusaini Cheti
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 ithibati 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 unakwepa kosa linalozuia node mpya kufikia siri ndani ya kontena kwa sababu node inaweza kufikia tu siri za kontena zilizowekwa juu yake.
Njia ya kukwepa hii ni tu kuunda ithibati ya node kwa jina la node ambapo kontena lenye siri za kuvutia limewekwa (lakini angalia tu jinsi ya kufanya hivyo katika post ya kwanza):
AWS EKS aws-auth configmaps
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.
Kuongeza Haki katika GKE
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.
GCP - Container PrivescNjia ya pili ni kutoa ruhusa za K8s ndani ya klasta kwa kutambua mtumiaji kwa barua pepe yake (akaunti za huduma za GCP zimejumuishwa).
Unda token za serviceaccounts
Wakuu wanaoweza kuunda TokenRequests (serviceaccounts/token) Wakati wa kuzungumza na kiunganishi cha K8s api SAs (habari kutoka hapa).
ephemeralcontainers
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.
ValidatingWebhookConfigurations au MutatingWebhookConfigurations
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.
Pandisha
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.
Nodes proxy
Wakuu wenye ufikiaji wa nodes/proxy subresource wanaweza kutekeleza msimbo kwenye pods kupitia Kubelet API (kulingana na hii). Habari zaidi kuhusu uthibitisho wa Kubelet katika ukurasa huu:
Una mfano wa jinsi ya kupata RCE ukizungumza na Kubelet API hapa.
Futa pods + nodes zisizoweza kupanga
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 ziwe zinatekelezwa katika node iliyoathirika na mshambuliaji anaweza kuiba token kutoka kwa pods hizo.
Hali za Huduma (CVE-2020-8554)
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 mingi ya CVE-2020-8554 inazuia tu huduma za ExternalIP (kulingana na hii).
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 vilivyowekwa.
Kinga ya Kuinua Privilege iliyojengwa ndani
Kubernetes ina mekanismu iliyojengwa ndani ya kuzuia kuinua privilege.
Mfumo huu unahakikisha kwamba watumiaji hawawezi kuinua 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.
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 wanalojaribu kuunda au kubadilisha: ama kwa kiwango cha kluster kwa ClusterRoles au kufungwa kwenye namespace 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 privileges za majukumu na clusterroles hata bila kuwa na ruhusa hizo mwenyewe.
Pata & Patch RoleBindings/ClusterRoleBindings
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.
Ruhusa ya kuunda Rolebindings inamruhusu mtumiaji kuunganisha majukumu na akaunti ya huduma. Ruhusa hii inaweza kupelekea kuinua privilege kwa sababu inaruhusu mtumiaji kuunganisha ruhusa za admin kwa akaunti ya huduma iliyovunjwa.
Mashambulizi Mengine
Programu ya proxy ya Sidecar
Kwa kawaida hakuna usimbuaji katika mawasiliano kati ya pods. Uthibitishaji wa pamoja, wa pande mbili, kutoka pod hadi pod.
Unda programu ya proxy ya sidecar
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/
Malicious Admission Controller
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 kutumia mojawapo ya maswali yafuatayo:
Kama unavyoona kwenye picha hapo juu, tulijaribu kuendesha picha nginx lakini picha iliyotekelezwa mwishowe ni rewanthtammana/malicious-image. Nini kimetokea!!?
Technicalities
Scripti ./deploy.sh inaanzisha mutating webhook admission controller, ambayo inabadilisha maombi kwa API ya Kubernetes kama ilivyoainishwa katika mistari yake ya usanidi, ikihusisha matokeo yanayoonekana:
The above snippet replaces the first container image in every pod with rewanthtammana/malicious-image.
OPA Gatekeeper bypass
Kubernetes - OPA Gatekeeper bypassBest Practices
Kuzima Automount ya Tokens za Akaunti ya Huduma
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: falsekatika usanidi wa akaunti za huduma au pods kuanzia toleo la Kubernetes 1.6.
Kuteua Watumiaji kwa Uangalifu katika RoleBindings/ClusterRoleBindings
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 Maalum ya Namespace Badala ya Majukumu ya Kiwango cha Klasta
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.
Tumia zana za kiotomatiki
Marejeleo
Last updated
