Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Kwa maelezo zaidi angalia
Ikiwa una ruhusa eks:AccessKubernetesApi unaweza kuangalia vitu vya Kubernetes kupitia AWS EKS console (Learn more).
Njia rahisi:
Si njia rahisi:
Ikiwa unaweza kupata token kwa aws eks get-token --name <cluster_name> lakini huna ruhusa ya kupata taarifa za klasta (describeCluster), unaweza kuandaa ~/.kube/config yako mwenyewe. Hata hivyo, ukiwa na token, bado unahitaji url endpoint ya kuungana (ikiwa umeweza kupata token ya JWT kutoka kwa pod soma hapa) na jina la klasta.
Katika kesi yangu, sikuweza kupata taarifa katika CloudWatch logs, lakini nilipata katika LaunchTemplates userData na katika mashine za EC2 katika userData pia. Unaweza kuona taarifa hii katika userData kwa urahisi, kwa mfano katika mfano ufuatao (jina la klasta lilikuwa cluster-name):
Mwandishi wa EKS cluster daima atakuwa na uwezo wa kuingia kwenye sehemu ya kundi la kubernetes system:masters (k8s admin). Wakati wa kuandika hii, hakuna njia ya moja kwa moja ya kubaini nani aliumba kundi hilo (unaweza kuangalia CloudTrail). Na hakuna njia ya kuondoa hiyo haki.
Njia ya kutoa ufikiaji kwa K8s kwa watumiaji au majukumu mengine ya AWS IAM ni kutumia configmap aws-auth.
Hivyo, mtu yeyote mwenye ufikiaji wa kuandika kwenye ramani ya config aws-auth ataweza kuharibu kundi zima.
Kwa maelezo zaidi kuhusu jinsi ya kutoa haki za ziada kwa majukumu na watumiaji wa IAM katika akaunti sawa au tofauti na jinsi ya kuitumia hii privesc angalia ukurasa huu.
Angalia pia hii nzuri post ili kujifunza jinsi uthibitishaji IAM -> Kubernetes unavyofanya kazi.
Inawezekana kuruhusu uthibitishaji wa OpenID kwa akaunti ya huduma ya kubernetes ili kuwapa uwezo wa kuchukua majukumu katika AWS. Jifunze jinsi hii inavyofanya kazi katika ukurasa huu.
Haukuweza kupata hati yoyote inayofafanua vigezo vya 'herufi mbili' na 'nambari'. Lakini nikifanya majaribio kwa niaba yangu naona zinajirudia hizi:
gr7
yl4
Hata hivyo ni herufi 3 tu tunaweza kuzishambulia kwa nguvu. Tumia script iliyo hapa chini kwa ajili ya kuunda orodha
Kisha na wfuzz
Kumbuka kubadilisha & .
Ikiwa mshambuliaji anapata akreditif za AWS zenye idhini juu ya EKS. Ikiwa mshambuliaji anapanga kubeconfig yake mwenyewe (bila kuita update-kubeconfig) kama ilivyoelezwa hapo awali, get-token haitengenezi kumbukumbu katika Cloudtrail kwa sababu haiingiliani na API ya AWS (inaunda tu token hiyo kwa ndani).
Hivyo, wakati mshambuliaji anazungumza na klasta ya EKS, cloudtrail haitarekodi chochote kinachohusiana na mtumiaji anayeporwa na kuingia.
Kumbuka kwamba klasta ya EKS inaweza kuwa na kumbukumbu zilizowezeshwa ambazo zitaandika ufikiaji huu (ingawa, kwa kawaida, zimezimwa).
Kwa kawaida, mtumiaji au jukumu lililounda klasta lina DAIMA kuwa na mamlaka ya usimamizi juu ya klasta hiyo. Na kwamba ufikiaji pekee "salama" ambao AWS itakuwa nao juu ya klasta ya Kubernetes.
Hivyo, ikiwa mshambuliaji anaharibu klasta kwa kutumia fargate na kuondoa wasimamizi wengine wote na kufuta mtumiaji/jukumu la AWS lililounda Klasta, mshambuliaji anaweza kuwa amefanya nyara klastar.
Kumbuka kwamba ikiwa klasta ilikuwa inatumia EC2 VMs, inaweza kuwa inawezekana kupata mamlaka ya Usimamizi kutoka kwa Node na kurejesha klasta.
Kwa kweli, ikiwa klasta inatumia Fargate unaweza EC2 nodes au kuhamasisha kila kitu kwenda EC2 kwenye klasta na kuirejesha kwa kufikia token katika node.
Kufungua token ya JWT tunapata kitambulisho cha kundi & pia eneo. Kujua kwamba muundo wa kawaida wa URL ya EKS ni
Jifunze & fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Jifunze & fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
