# AWS - EKS Post Exploitation

{{#include ../../../../banners/hacktricks-training.md}}

## EKS

Vir meer inligting sien

{{#ref}}
../../aws-services/aws-eks-enum.md
{{#endref}}

### 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](https://docs.aws.amazon.com/eks/latest/userguide/view-workloads.html)).

### Koppel aan AWS Kubernetes-kluster

- Maklike manier:
```bash
# 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](aws-eks-post-exploitation/README.md#get-api-server-endpoint-from-a-jwt-token)) 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):
```bash
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
```
<details>

<summary>kube config</summary>
```yaml
describe-cache-parametersapiVersion: v1
clusters:
- cluster:
certificate-authority-data:  
server: https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-west-2.eks.amazonaws.com
name: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
contexts:
- context:
cluster: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
user: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
name: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
current-context: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
kind: Config
preferences: {}
users:
- name: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
user:
exec:
apiVersion: client.authentication.k8s.io/v1beta1
args:
- --region
- us-west-2
- --profile
- <profile>
- eks
- get-token
- --cluster-name
- <cluster-name>
command: aws
env: null
interactiveMode: IfAvailable
provideClusterInfo: false
```
</details>

### 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**](../../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/index.html#aws-eks-aws-auth-configmaps).

Kyk ook [ **this awesome**](https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator) **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**](../../../kubernetes-security/kubernetes-pivoting-to-clouds.md#workflow-of-iam-role-for-service-accounts-1).

### GET Api Server Endpoint from a JWT Token

Deur die JWT token te decodeer kry ons die cluster id & ook die region. ![image](https://github.com/HackTricks-wiki/hacktricks-cloud/assets/87022719/0e47204a-eea5-4fcb-b702-36dc184a39e9) Wetende dat die standaard formaat vir EKS url is
```bash
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
```python
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
```bash
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 d**eleteer die AWS user/role wat die Cluster geskep het**, die Cluster, ~~die aanvaller kon die cluster **losgekoop die kluste**~~**r**.

> [!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.

{{#include ../../../../banners/hacktricks-training.md}}
