AWS - EKS Post Exploitation
Last updated
Last updated
Leer & oefen AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Leer & oefen GCP Hacking: 
HackTricks Training GCP Red Team Expert (GRTE)
Vir meer inligting, kyk
As jy die toestemming eks:AccessKubernetesApi het, kan jy Kubernetes-objekte via die AWS EKS-console bekyk (Leer meer).
Maklike manier:
Nie so maklik nie:
As jy 'n token kan kry met aws eks get-token --name <cluster_name> maar jy het nie toestemming om cluster inligting te kry nie (describeCluster), kan jy jou eie ~/.kube/config voorberei. Maar, met die token, het jy steeds die url eindpunt om mee te verbind (as jy daarin geslaag het om 'n JWT token van 'n pod te kry, lees hier) en die naam van die cluster.
In my geval, het ek nie die inligting in CloudWatch logs gevind nie, maar ek het dit in LaunchTemplates userData gevind en in EC2 masjiene in userData ook. Jy kan hierdie inligting maklik in userData sien, byvoorbeeld in die volgende voorbeeld (die cluster naam was cluster-name):
Die skepper van die EKS-kluster sal ALTYD in staat wees om in die kubernetes kluster deel van die groep system:masters (k8s admin) te kom. Ten tyde van hierdie skrywe is daar geen direkte manier om te vind wie die kluster geskep het (jy kan CloudTrail nagaan). En daar is geen manier om daardie privilege te verwyder.
Die manier om toegang tot K8s aan meer AWS IAM gebruikers of rolle te verleen, is deur die configmap aws-auth te gebruik.
Daarom sal enige iemand met skryftoegang oor die config map aws-auth in staat wees om die hele kluster te kompromitteer.
Vir meer inligting oor hoe om addisionele privileges aan IAM rolle & gebruikers in die dieselfde of verskillende rekening te verleen en hoe om dit te misbruik, kyk na privesc check this page.
Kyk ook na hierdie wonderlike plasing om te leer hoe die authenticatie IAM -> Kubernetes werk.
Dit is moontlik om 'n OpenID-authenticatie vir kubernetes diensrekening toe te laat om hulle in staat te stel om rolle in AWS aan te neem. Leer hoe dit werk op hierdie bladsy.
Nie enige dokumentasie gevind wat die kriteria vir die 'twee karakters' en die 'nommer' verduidelik nie. Maar deur 'n paar toetse namens myself te doen, sien ek dat hierdie eene herhaaldelik voorkom:
gr7
yl4
In elk geval is dit net 3 karakters wat ons kan bruteforce. Gebruik die onderstaande skrip om die lys te genereer.
Dan met wfuzz
Onthou om te vervang & .
As 'n aanvaller die akrediteer van 'n AWS met toestemming oor 'n EKS verkry. As die aanvaller sy eie kubeconfig (sonder om update-kubeconfig te noem) soos voorheen verduidelik, genereer die get-token nie logs in Cloudtrail nie omdat dit nie met die AWS API kommunikeer nie (dit skep net die token plaaslik).
So wanneer die aanvaller met die EKS-kluster praat, sal cloudtrail niks log wat verband hou met die gebruiker wat gesteel is en toegang daartoe het nie.
Let daarop dat die EKS-kluster dalk logs geaktiveer het wat hierdie toegang sal log (alhoewel dit standaard gedeaktiveer is).
Standaard het die gebruiker of rol wat 'n kluster geskep het ALTYD administratiewe regte oor die kluster. En dit is die enigste "veilige" toegang wat AWS oor die Kubernetes-kluster sal hê.
So, as 'n aanvaller 'n kluster met fargate kompromitteer en alle ander administrateurs verwyder en die AWS gebruiker/rol wat die Kluster geskep het, verwyder, kan die aanvaller die kluster gehuurder.
Let daarop dat as die kluster EC2 VM's gebruik, dit moontlik kan wees om Administratiewe regte van die Node te verkry en die kluster te herstel.
Werklik, as die kluster Fargate gebruik, kan jy EC2 nodes of alles na EC2 na die kluster skuif en dit herstel deur toegang tot die tokens in die node.
Deur die JWT-token te ontleed, kry ons die kluster-id & ook die streek. Weet dat die standaardformaat vir EKS-URL is
Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)