AWS - EKS Post Exploitation

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

EKS

Vir meer inligting sien

AWS - EKS Enum

Enumerate the cluster from the AWS Console

As jy die toestemming eks:AccessKubernetesApi het, kan jy Kubernetes-objekte besigtig via die AWS EKS console (Learn more).

Koppel aan AWS Kubernetes-kluster

  • Maklike manier:
# Generate kubeconfig
aws eks update-kubeconfig --name aws-eks-dev
  • Nie daardie maklike manier nie:

As jy ’n token kan kry met aws eks get-token --name <cluster_name> maar jy het nie permissies om cluster-inligting te kry (describeCluster) nie, kan jy jou eie ~/.kube/config voorberei. Alhoewel jy die token het, het jy steeds die URL-eindpunt om aan te koppel nodig (as jy daarin geslaag het om ’n JWT token van ’n pod te kry lees here) en die naam van die cluster.

In my geval het ek die inligting nie in CloudWatch logs gevind nie, maar ek het dit in LaunchTemaplates userData gevind en ook in EC2 machines in userData. Jy kan hierdie inligting maklik in userData sien, byvoorbeeld in die volgende voorbeeld (die cluster naam was cluster-name):

API_SERVER_URL=https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-east-1.eks.amazonaws.com

/etc/eks/bootstrap.sh cluster-name --kubelet-extra-args '--node-labels=eks.amazonaws.com/sourceLaunchTemplateVersion=1,alpha.eksctl.io/cluster-name=cluster-name,alpha.eksctl.io/nodegroup-name=prd-ondemand-us-west-2b,role=worker,eks.amazonaws.com/nodegroup-image=ami-002539dd2c532d0a5,eks.amazonaws.com/capacityType=ON_DEMAND,eks.amazonaws.com/nodegroup=prd-ondemand-us-west-2b,type=ondemand,eks.amazonaws.com/sourceLaunchTemplateId=lt-0f0f0ba62bef782e5 --max-pods=58' --b64-cluster-ca $B64_CLUSTER_CA --apiserver-endpoint $API_SERVER_URL --dns-cluster-ip $K8S_CLUSTER_DNS_IP --use-max-pods false
kube config ```yaml describe-cache-parametersapiVersion: v1 clusters: - cluster: certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUMvakNDQWVhZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJeU1USXlPREUyTWpjek1Wb1hEVE15TVRJeU5URTJNamN6TVZvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTDlXCk9OS0ZqeXZoRUxDZGhMNnFwWkMwa1d0UURSRVF1UzVpRDcwK2pjbjFKWXZ4a3FsV1ZpbmtwOUt5N2x2ME5mUW8KYkNqREFLQWZmMEtlNlFUWVVvOC9jQXJ4K0RzWVlKV3dzcEZGbWlsY1lFWFZHMG5RV1VoMVQ3VWhOanc0MllMRQpkcVpzTGg4OTlzTXRLT1JtVE5sN1V6a05pTlUzSytueTZSRysvVzZmbFNYYnRiT2kwcXJSeFVpcDhMdWl4WGRVCnk4QTg3VjRjbllsMXo2MUt3NllIV3hhSm11eWI5enRtbCtBRHQ5RVhOUXhDMExrdWcxSDBqdTl1MDlkU09YYlkKMHJxY2lINjYvSTh0MjlPZ3JwNkY0dit5eUNJUjZFQURRaktHTFVEWUlVSkZ4WXA0Y1pGcVA1aVJteGJ5Nkh3UwpDSE52TWNJZFZRRUNQMlg5R2c4Q0F3RUFBYU5aTUZjd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0hRWURWUjBPQkJZRUZQVXFsekhWZmlDd0xqalhPRmJJUUc3L0VxZ1hNQlVHQTFVZEVRUU8KTUF5Q0NtdDFZbVZ5Ym1WMFpYTXdEUVlKS29aSWh2Y05BUUVMQlFBRGdnRUJBS1o4c0l4aXpsemx0aXRPcGcySgpYV0VUSThoeWxYNWx6cW1mV0dpZkdFVVduUDU3UEVtWW55eWJHbnZ5RlVDbnczTldMRTNrbEVMQVE4d0tLSG8rCnBZdXAzQlNYamdiWFovdWVJc2RhWlNucmVqNU1USlJ3SVFod250ZUtpU0J4MWFRVU01ZGdZc2c4SlpJY3I2WC8KRG5POGlHOGxmMXVxend1dUdHSHM2R1lNR0Mvd1V0czVvcm1GS291SmtSUWhBZElMVkNuaStYNCtmcHUzT21UNwprS3VmR0tyRVlKT09VL1c2YTB3OTRycU9iSS9Mem1GSWxJQnVNcXZWVDBwOGtlcTc1eklpdGNzaUJmYVVidng3Ci9sMGhvS1RqM0IrOGlwbktIWW4wNGZ1R2F2YVJRbEhWcldDVlZ4c3ZyYWpxOUdJNWJUUlJ6TnpTbzFlcTVZNisKRzVBPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg== server: https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-west-2.eks.amazonaws.com name: arn:aws:eks:us-east-1::cluster/ contexts: - context: cluster: arn:aws:eks:us-east-1::cluster/ user: arn:aws:eks:us-east-1::cluster/ name: arn:aws:eks:us-east-1::cluster/ current-context: arn:aws:eks:us-east-1::cluster/ kind: Config preferences: {} users: - name: arn:aws:eks:us-east-1::cluster/ user: exec: apiVersion: client.authentication.k8s.io/v1beta1 args: - --region - us-west-2 - --profile - - eks - get-token - --cluster-name - command: aws env: null interactiveMode: IfAvailable provideClusterInfo: false ```

Van AWS na Kubernetes

Die skepper van die EKS cluster sal ALWAYS toegang hê tot die kubernetes cluster deel van die groep system:masters (k8s admin). Op die tyd van skrywe is daar no direct way om te vind wie die cluster geskep het (jy kan CloudTrail nagaan). En daar is no way om daardie privilege te remove.

Die manier om access to over K8s to more AWS IAM users or roles te verleen is deur die configmap aws-auth te gebruik.

Warning

Daarom sal enigiemand met write access oor die config map aws-auth in staat wees om die compromise the whole cluster.

Vir meer inligting oor hoe om extra voorregte aan IAM roles & users te verleen in die selfde of ander account en hoe om dit te abuse sien privesc check this page.

Kyk ook this awesome post to learn how the authentication IAM -> Kubernetes work.

Van Kubernetes na AWS

Dit is moontlik om OpenID authentication for kubernetes service account toe te laat sodat hulle rolle in AWS kan assume. Leer hoe this work in this page.

GET Api Server Endpoint from a JWT Token

Deur die JWT token te decodeer kry ons die cluster id & ook die region. image Wetende dat die standaard formaat vir EKS url is

https://<cluster-id>.<two-random-chars><number>.<region>.eks.amazonaws.com

Ek het geen dokumentasie gevind wat die kriteria vir die ‘two chars’ en die ‘number’ verduidelik nie. Maar nadat ek ’n paar toetse gedoen het, sien ek dat die volgende gereeld voorkom:

  • gr7
  • yl4

Dit is tog net 3 tekens; ons kan dit bruteforce. Gebruik die onderstaande script om die lys te genereer

from itertools import product
from string import ascii_lowercase

letter_combinations = product('abcdefghijklmnopqrstuvwxyz', repeat = 2)
number_combinations = product('0123456789', repeat = 1)

result = [
f'{''.join(comb[0])}{comb[1][0]}'
for comb in product(letter_combinations, number_combinations)
]

with open('out.txt', 'w') as f:
f.write('\n'.join(result))

Dan met wfuzz

wfuzz -Z -z file,out.txt --hw 0 https://<cluster-id>.FUZZ.<region>.eks.amazonaws.com

Warning

Onthou om & te vervang .

Bypass CloudTrail

As ’n aanvaller credentiale van ’n AWS-rekening met permission over an EKS bekom. As die aanvaller sy eie kubeconfig opstel (sonder om update-kubeconfig te roep) soos voorheen verduidelik, genereer get-token geen logs in Cloudtrail nie omdat dit nie met die AWS API kommunikeer nie (dit skep net die token lokaal).

Dus, wanneer die aanvaller met die EKS cluster kommunikeer, cloudtrail sal niks log wat verband hou met die gesteelde gebruiker en toegang daartoe nie.

Let wel dat die EKS cluster dalk logs geaktiveer het wat hierdie toegang sal log (alhoewel hulle standaard gedeaktiveer is).

EKS Ransom?

Per verstek sal die gebruiker of rol wat ’n cluster geskep het, ALTYD admin-regte oor die cluster hê. En dit is die enigste “secure” toegang wat AWS oor die Kubernetes cluster sal hê.

So, as ’n aanvaller ’n cluster kompromitteer wat fargate gebruik en al die ander admins verwyder en deleteer die AWS user/role wat die Cluster geskep het, die Cluster, die aanvaller kon die cluster losgekoop die kluster.

Tip

Let wel dat as die cluster EC2 VMs gebruik het, dit moontlik sou wees om Admin-regte van die Node te kry en die cluster te herstel.

Trouens, as die cluster Fargate gebruik, kan jy EC2 nodes skep of alles na EC2 skuif in die cluster en dit herstel deur toegang tot die tokens op die node.

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks