# AWS - EKS Post Exploitation

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

## EKS

詳細は以下を確認

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

### AWS Console から cluster を列挙する

**`eks:AccessKubernetesApi`** 権限があれば、AWS EKS console から **Kubernetes objects** を確認できます ([詳細](https://docs.aws.amazon.com/eks/latest/userguide/view-workloads.html))。

### AWS Kubernetes Cluster に接続する

- Easy way:
```bash
# Generate kubeconfig
aws eks update-kubeconfig --name aws-eks-dev
```
- それほど簡単ではない方法:

もし **`aws eks get-token --name <cluster_name>`** で **token** を取得できるが、cluster info（describeCluster）を取得する権限がない場合、**自分の `~/.kube/config`** を用意できます。ただし、token を持っていても、接続先の **url endpoint**（pod から JWT token を取得できた場合は [ここ](aws-eks-post-exploitation/README.md#get-api-server-endpoint-from-a-jwt-token) を参照）と **cluster の name** が必要です。

私の場合、その情報は CloudWatch logs では見つかりませんでしたが、**LaunchTemaplates の userData** と **EC2 machines の userData** にありました。例えば次の例のように、**userData** でこの情報を簡単に確認できます（cluster name は 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: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUMvakNDQWVhZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJeU1USXlPREUyTWpjek1Wb1hEVE15TVRJeU5URTJNamN6TVZvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTDlXCk9OS0ZqeXZoRUxDZGhMNnFwWkMwa1d0UURSRVF1UzVpRDcwK2pjbjFKWXZ4a3FsV1ZpbmtwOUt5N2x2ME5mUW8KYkNqREFLQWZmMEtlNlFUWVVvOC9jQXJ4K0RzWVlKV3dzcEZGbWlsY1lFWFZHMG5RV1VoMVQ3VWhOanc0MllMRQpkcVpzTGg4OTlzTXRLT1JtVE5sN1V6a05pTlUzSytueTZSRysvVzZmbFNYYnRiT2kwcXJSeFVpcDhMdWl4WGRVCnk4QTg3VjRjbllsMXo2MUt3NllIV3hhSm11eWI5enRtbCtBRHQ5RVhOUXhDMExrdWcxSDBqdTl1MDlkU09YYlkKMHJxY2lINjYvSTh0MjlPZ3JwNkY0dit5eUNJUjZFQURRaktHTFVEWUlVSkZ4WXA0Y1pGcVA1aVJteGJ5Nkh3UwpDSE52TWNJZFZRRUNQMlg5R2c4Q0F3RUFBYU5aTUZjd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0hRWURWUjBPQkJZRUZQVXFsekhWZmlDd0xqalhPRmJJUUc3L0VxZ1hNQlVHQTFVZEVRUU8KTUF5Q0NtdDFZbVZ5Ym1WMFpYTXdEUVlKS29aSWh2Y05BUUVMQlFBRGdnRUJBS1o4c0l4aXpsemx0aXRPcGcySgpYV0VUSThoeWxYNWx6cW1mV0dpZkdFVVduUDU3UEVtWW55eWJHbnZ5RlVDbnczTldMRTNrbEVMQVE4d0tLSG8rCnBZdXAzQlNYamdiWFovdWVJc2RhWlNucmVqNU1USlJ3SVFod250ZUtpU0J4MWFRVU01ZGdZc2c4SlpJY3I2WC8KRG5POGlHOGxmMXVxend1dUdHSHM2R1lNR0Mvd1V0czVvcm1GS291SmtSUWhBZElMVkNuaStYNCtmcHUzT21UNwprS3VmR0tyRVlKT09VL1c2YTB3OTRycU9iSS9Mem1GSWxJQnVNcXZWVDBwOGtlcTc1eklpdGNzaUJmYVVidng3Ci9sMGhvS1RqM0IrOGlwbktIWW4wNGZ1R2F2YVJRbEhWcldDVlZ4c3ZyYWpxOUdJNWJUUlJ6TnpTbzFlcTVZNisKRzVBPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
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>

### AWS から Kubernetes へ

歴史的に、**EKS cluster** の **creator** は、`aws-auth` からは見えない hidden な Kubernetes admin access を受け取っていました。現在の EKS clusters では、これは cluster access configuration に依存します。`bootstrapClusterCreatorAdminPermissions` は、creation 時に creator を cluster-admin access entry として追加するかどうかを制御し、EKS access entries によってその admin path は EKS API 経由で可視化され、取り消し可能になります。古い clusters、またはまだ `aws-auth` に依存している clusters では、legacy な creator behavior が残っている可能性があるため、creator が常に取り消し不能な `system:masters` を持つと決めつけずに、`accessConfig` を確認し、access entries を列挙し、CloudTrail を review してください。

#### configmap の abuse

**K8s への access をより多くの AWS IAM users や roles に付与する** 伝統的な方法は、**configmap** **`aws-auth`** を使うことです。

> [!WARNING]
> したがって、config map **`aws-auth`** に **write access** を持つ anyone は、**cluster 全体を compromise** できます。

**同じ account または別の account** にある IAM roles & users に **追加権限を付与** する方法、およびこれを **abuse** して [**privesc についてはこの page を check**](../../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/index.html#aws-eks-aws-auth-configmaps) する方法の詳細は、こちらを参照してください。

また、**authentication の IAM -> Kubernetes の仕組みを学ぶ** ために、[**this awesome**](https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator) **post** も check してください。

#### Access Entries の abuse

AWS は、access entries を通じて IAM users に Kubernetes cluster への access を付与する追加の方法を実装しています。`eks:CreateAccessEntry` と `eks:AssociateAccessPolicy` の permissions があれば、user 自身または特定の role に Kubernetes administrator role を割り当てられる可能性もあります。

まず、**user または role の access entry を create します**:
```
aws eks create-access-entry --cluster-name <cluster_name> --region <region> --principal-arn <arn_from_your_user_or_role> --type STANDARD
```
そのエントリが作成されたことで、これに直接 policy を割り当てられるようになるかもしれません。*AmazonEKSClusterAdminPolicy* という組み込みの AWS policy があり、これを直接使用できる場合があります。環境に、EKS での権限昇格を許可する他の custom policies があるなら、`--policy-arn` をそれらのいずれかに変更してもかまいません：
```
aws eks associate-access-policy --cluster-name <cluster_name> --region <region> --principal-arn <arn_from_your_user_or_role> --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy --access-scope type=cluster
```
You can search for this policy in AWS official documentation [**here**](https://docs.aws.amazon.com/eks/latest/userguide/access-policy-permissions.html#access-policy-permissions-amazoneksclusteradminpolicy)

この時点から、*k8s* token を request して、administrator として cluster と interact できるようになる場合があります:
```
aws eks get-token --cluster-name <cluster_name> --output json | jq -r '.status.token'
```
### From Kubernetes to AWS

**kubernetes service account** に対して **OpenID authentication** を許可し、AWS で role を assume できるようにすることが可能です。これがどのように動作するかは、このページで学べます: [**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

JWT token を decode すると、cluster id と region も取得できます。 ![image](https://github.com/HackTricks-wiki/hacktricks-cloud/assets/87022719/0e47204a-eea5-4fcb-b702-36dc184a39e9) EKS url の標準形式がであることを知っていれば、
```bash
https://<cluster-id>.<two-random-chars><number>.<region>.eks.amazonaws.com
```
'two chars' と 'number' の基準を説明する documentation は見つかりませんでした。ですが、自分でいくつか test したところ、以下のものが繰り返し出てきました:

- gr7
- yl4

いずれにせよ、たった 3 chars なので bruteforce できます。リストを生成するには以下の script を使ってください
```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))
```
それから wfuzz を使って
```bash
wfuzz -Z -z file,out.txt --hw 0 https://<cluster-id>.FUZZ.<region>.eks.amazonaws.com
```
> [!WARNING]
> Remember to replace & .

### Bypass CloudTrail

攻撃者が **EKS への権限** を持つ AWS の認証情報を取得した場合。攻撃者が前述のように、自分の **`kubeconfig`** を **`update-kubeconfig`** を呼ばずに設定すると、**`get-token`** は AWS API とやり取りしないため、Cloudtrail にログを生成しません（ローカルでトークンを作成するだけです）。

そのため、攻撃者が EKS クラスターと通信しても、**cloudtrail には盗まれたユーザーがアクセスしたことに関連するものは何も記録されません**。

ただし、**EKS クラスター側でログが有効** になっている場合は、このアクセスが記録される可能性があります（ただし、デフォルトでは無効です）。

### EKS Ransom?

デフォルトでは、クラスターを作成した **user or role** は **必ず** クラスターに対して admin 権限を持ちます。これは、Kubernetes クラスターに対して AWS が持つ唯一の「安全な」アクセスです。

そのため、**攻撃者が fargate を使うクラスターを侵害し**、**他のすべての admins を削除し**、クラスターを作成した **AWS user/role を削除** すると、~~攻撃者はそのクラスターを **ransom** できる~~**可能性があります**。

> [!TIP]
> クラスターが **EC2 VMs** を使用していた場合、**Node** から Admin 権限を取得してクラスターを復旧できる可能性があります。
>
> 実際、クラスターが Fargate を使っている場合は、EC2 nodes を使うか、すべてを EC2 に移して、Node 上の tokens にアクセスしてクラスターを復旧できるかもしれません。

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