# AWS - EKS Post Exploitation

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

## EKS

詳細については以下を確認してください

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

### Enumerate the cluster from the AWS Console

もし権限 **`eks:AccessKubernetesApi`** を持っている場合、AWS EKS コンソール経由で **Kubernetes objects を表示できます**（[Learn more](https://docs.aws.amazon.com/eks/latest/userguide/view-workloads.html)）。

### Connect to AWS Kubernetes Cluster

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

もし **`aws eks get-token --name <cluster_name>`** で **トークンを取得できる** が、クラスタ情報（describeCluster）を取得する権限がなければ、**独自に `~/.kube/config` を用意する**ことができます。ただしトークンを持っていても、接続するための **URL エンドポイント**（pod から JWT token を入手できた場合は [here](aws-eks-post-exploitation/README.md#get-api-server-endpoint-from-a-jwt-token) を参照）と **クラスタの名前** が必要です。

私の場合、CloudWatch ログでは情報は見つかりませんでしたが、**LaunchTemaplates userData で見つけました**し、**EC2 マシンの userData にもありました**。この情報は **userData** に簡単に表示されます。例えば次の例（クラスタ名は 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>

### AWSからKubernetesへ

**作成者** は **EKS cluster** の kubernetes クラスタ部分の **`system:masters`** グループ（k8s admin）に**常に**アクセスできる。執筆時点ではクラスタを**誰が作成したか**を特定する**直接的な方法はない**（CloudTrail を確認することはできる）。また、その**権限を取り消す方法**は**存在しない**。

**K8s へのアクセスをより多くの AWS IAM ユーザーやロールに付与する方法** は、**configmap** **`aws-auth`** を使用することです。

> [!WARNING]
> したがって、config map **`aws-auth`** に対する **write access** を持つ者は誰でも、**compromise the whole cluster** ことができる。

同一または別のアカウントの **IAM roles & users に追加権限を付与する方法** と、それを **悪用** する方法の詳細は [**privesc check this page**](../../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/index.html#aws-eks-aws-auth-configmaps) を参照してください。

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

### KubernetesからAWSへ

kubernetes service account に対する **OpenID authentication for kubernetes service account** を許可して、それらが AWS のロールを引き受けられるようにすることが可能です。仕組みは [**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 をデコードすると 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`' の基準を説明するドキュメントは見つかりませんでした。ただ、自分でいくつかテストしたところ、以下のものが繰り返し見られました:

- gr7
- yl4

いずれにせよ3文字に過ぎないのでbruteforceで総当たりできます。以下のスクリプトを使ってリストを生成してください。
```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]
> 置換することを忘れないでください & .

### Bypass CloudTrail

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

したがって、攻撃者が EKS クラスターとやり取りしても、cloudtrail は盗まれたユーザーによるアクセスに関連するログを何も記録しません。

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

### EKS Ransom?

デフォルトでは、クラスターを作成したユーザーまたはロールは常にクラスターに対して管理者権限を持ちます。そして、それが AWS が Kubernetes クラスターに対して持つ唯一の「安全な」アクセスです。

したがって、**攻撃者が fargate を使ってクラスターを乗っ取り**、**他のすべての管理者を排除し**、**クラスターを作成した AWS ユーザー/ロールを削除した**場合、~~the attacker could have **ransomed the cluste**~~**r**。

> [!TIP]
> クラスターが **EC2 VMs** を使用している場合、**Node** から管理者権限を取得してクラスターを回復できる可能性がある点に注意してください。
>
> 実際には、クラスターが Fargate を使用している場合でも、EC2 ノードを用意するかすべてを EC2 に移行してノード上のトークンにアクセスすることでクラスターを回復できる可能性があります。

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