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 inayoweza 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/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 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.
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 tweet hii na nyongeza chache:
Sasa kwamba unaweza kukimbia hadi kwenye node angalia mbinu za baada ya unyakuzi katika:
Huenda unataka kuwa stealthier, katika kurasa zinazofuata unaweza kuona kile ambacho unaweza kufikia ikiwa utaunda pod kwa kuwezesha baadhi ya ruhusa zilizotajwa katika kiolezo kilichopita:
Privileged + hostPID
Privileged tu
hostPath
hostPID
hostNetwork
hostIPC
Unaweza kupata mfano wa jinsi ya kuunda/kutumia vibaya mipangilio ya pods zilizopatiwa ruhusa katika https://github.com/BishopFox/badPods
Ikiwa unaweza kuunda pod (na hiari akaunti ya huduma) huenda ukawa 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 mfano.
Kwa maelezo zaidi angalia:
Pod Escape PrivilegesInawezekana kutumia vibaya ruhusa hizi ili kuunda pod mpya na kuanzisha ruhusa kama katika mfano wa awali.
Yaml ifuatayo inaunda daemonset na inatoa token ya SA ndani ya 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 dhaifu (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 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.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 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 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
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 ujanja wa kujifanya 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 hizo 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 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 yanaweza 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 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):
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 itaangalia kama mkuu (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 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).
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 na securityContext yenye mamlaka.
Wakuu wenye mojawapo ya vitenzi create, update au patch juu ya validatingwebhookconfigurations au mutatingwebhookconfigurations wanaweza kuwa na uwezo wa kuunda moja 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 uthibitishaji 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 kuwekewa ratiba (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 shambulio la MiTM dhidi ya klasta. Kila njia ya kupunguza CVE-2020-8554 inazuia huduma za ExternalIP pekee (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 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 klasta kwa ClusterRoles au kufungwa kwenye namespace moja (au kwa kiwango cha klasta) 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.
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 au SA tofauti baadhi ya privileges ikiwa tayari huna.
Privilege ya kuunda Rolebindings inamruhusu mtumiaji kuunganisha majukumu na akaunti ya huduma. Privilege hii inaweza kupelekea kuinua privilege kwa sababu inaruhusu mtumiaji kuunganisha ruhusa za admin kwa akaunti ya huduma iliyovunjika.
Kwa kawaida hakuna usimbuaji katika mawasiliano kati ya pods. Uthibitishaji wa pamoja, wa pande 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 ombi 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!!?
Scripti ./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)
