hacktricks-cloud/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation/README.md

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 を確認できます (詳細)。

AWS Kubernetes Cluster に接続する

• Easy way:

# 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 を取得できた場合は ここ を参照）と cluster の name が必要です。

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

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 する方法の詳細は、こちらを参照してください。

また、authentication の IAM -> Kubernetes の仕組みを学ぶ ために、this awesome 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

この時点から、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。

GET Api Server Endpoint from a JWT Token

JWT token を decode すると、cluster id と region も取得できます。 EKS url の標準形式がであることを知っていれば、

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

'two chars' と 'number' の基準を説明する documentation は見つかりませんでした。ですが、自分でいくつか test したところ、以下のものが繰り返し出てきました:

• gr7
• yl4

いずれにせよ、たった 3 chars なので bruteforce できます。リストを生成するには以下の script を使ってください

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 を使って

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}}