mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-06-12 19:11:44 -07:00
Translated ['', 'src/pentesting-cloud/aws-security/aws-post-exploitation
This commit is contained in:
Translator
+48
-28
@@ -1,31 +1,31 @@
|
||||
# AWS - EKS Post Exploitation
|
||||
# AWS - EKS ポストエクスプロイテーション
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## EKS
|
||||
|
||||
詳細については以下を確認してください
|
||||
詳細は以下を確認
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-eks-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Enumerate the cluster from the AWS Console
|
||||
### AWS Console から cluster を列挙する
|
||||
|
||||
もし権限 **`eks:AccessKubernetesApi`** を持っている場合、AWS EKS コンソール経由で **Kubernetes objects を表示できます**（[Learn more](https://docs.aws.amazon.com/eks/latest/userguide/view-workloads.html)）。
|
||||
権限 **`eks:AccessKubernetesApi`** があれば、AWS EKS console から **Kubernetes objects を表示**できます ([Learn more](https://docs.aws.amazon.com/eks/latest/userguide/view-workloads.html))。
|
||||
|
||||
### Connect to AWS Kubernetes Cluster
|
||||
### 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) を参照）と **クラスタの名前** が必要です。
|
||||
**`aws eks get-token --name <cluster_name>`** で **token** を取得できても、cluster info を取得する権限（describeCluster）がない場合は、**自分で `~/.kube/config` を作成**できます。ただし、token があっても、接続先の **url endpoint**（pod から JWT token を取得できた場合は [here](aws-eks-post-exploitation/README.md#get-api-server-endpoint-from-a-jwt-token) を参照）と **cluster 名** は依然として必要です。
|
||||
|
||||
私の場合、CloudWatch ログでは情報は見つかりませんでしたが、**LaunchTemaplates userData で見つけました**し、**EC2 マシンの userData にもありました**。この情報は **userData** に簡単に表示されます。例えば次の例（クラスタ名は cluster-name）:
|
||||
私の場合、CloudWatch logs では情報を見つけられませんでしたが、**LaunchTemaplates の userData** と **EC2 machines の userData** で見つけました。たとえば次の例のように、**userData** でこの情報を簡単に確認できます（cluster 名は cluster-name でした）:
|
||||
```bash
|
||||
API_SERVER_URL=https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-east-1.eks.amazonaws.com
|
||||
|
||||
@@ -72,33 +72,53 @@ provideClusterInfo: false
|
||||
|
||||
### AWSからKubernetesへ
|
||||
|
||||
**作成者** は **EKS cluster** の kubernetes クラスタ部分の **`system:masters`** グループ（k8s admin）に**常に**アクセスできる。執筆時点ではクラスタを**誰が作成したか**を特定する**直接的な方法はない**（CloudTrail を確認することはできる）。また、その**権限を取り消す方法**は**存在しない**。
|
||||
**EKS cluster** の **creator** は **ALWAYS** `system:masters` グループ（k8s admin）の kubernetes cluster 部分に入ることができます。執筆時点では、**誰が** cluster を作成したかを直接特定する方法は**ありません**（CloudTrail を確認できます）。また、その **privilege** を**削除**する方法も**ありません**。
|
||||
|
||||
**K8s へのアクセスをより多くの AWS IAM ユーザーやロールに付与する方法** は、**configmap** **`aws-auth`** を使用することです。
|
||||
#### configmap の abuse
|
||||
|
||||
より多くの AWS IAM users や roles に **K8s への access** を付与する従来の方法は、**configmap** `aws-auth` を使うことです。
|
||||
|
||||
> [!WARNING]
|
||||
> したがって、config map **`aws-auth`** に対する **write access** を持つ者は誰でも、**compromise the whole cluster** ことができる。
|
||||
> したがって、config map `aws-auth` への **write access** を持つ者は、**cluster 全体を compromise** できます。
|
||||
|
||||
同一または別のアカウントの **IAM roles & users に追加権限を付与する方法** と、それを **悪用** する方法の詳細は [**privesc check this page**](../../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/index.html#aws-eks-aws-auth-configmaps) を参照してください。
|
||||
同じ account または別の account において、IAM roles & users に**追加の privileges を付与**する方法、およびこれを [**privesc に abuse する方法はこちら**](../../../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** も確認してください。
|
||||
**authentication IAM -> Kubernetes がどのように動作するかを学ぶ**には、[**この素晴らしい**](https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator) **post** も確認してください。
|
||||
|
||||
### KubernetesからAWSへ
|
||||
#### Access Entries の abuse
|
||||
|
||||
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) を参照してください。
|
||||
AWS は、access entries を通じて IAM users に Kubernetes cluster への access を付与する追加の方法を実装しています。`eks:CreateAccessEntry` と `eks:AssociateAccessPolicy` の permissions があれば、自分の user または特定の role に Kubernetes administrator role を割り当てられる可能性があります。
|
||||
|
||||
まず、**自分の user または role 用の access entry を作成**します:
|
||||
```
|
||||
aws eks create-access-entry --cluster-name <cluster_name> --region <region> --principal-arn <arn_from_your_user_or_role> --type STANDARD
|
||||
```
|
||||
そのエントリを作成したら、直接ポリシーを割り当てられるようになるかもしれません。*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
|
||||
```
|
||||
AWS公式ドキュメントでこのポリシーを[**here**](https://docs.aws.amazon.com/eks/latest/userguide/access-policy-permissions.html#access-policy-permissions-amazoneksclusteradminpolicy)で確認できます
|
||||
|
||||
この時点から、*k8s* tokenを要求し、administratorとしてclusterと対話できる可能性があります:
|
||||
```
|
||||
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 できるようにすることが可能です。[**この仕組みの詳細はこちらのページで学べます**](../../../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 が得られます。  EKS url の標準フォーマットは
|
||||
JWT token をデコードすると、cluster id と region も取得できます。 EKS url の標準フォーマットがであることを知っていると
|
||||
```bash
|
||||
https://<cluster-id>.<two-random-chars><number>.<region>.eks.amazonaws.com
|
||||
```
|
||||
'`two chars`' と '`number`' の基準を説明するドキュメントは見つかりませんでした。ただ、自分でいくつかテストしたところ、以下のものが繰り返し見られました:
|
||||
'two chars' と 'number' の基準を説明するドキュメントは見つけられなかった。だが、自分でいくつかテストしてみると、よく出てくるのは次のものだった:
|
||||
|
||||
- gr7
|
||||
- yl4
|
||||
|
||||
いずれにせよ3文字に過ぎないのでbruteforceで総当たりできます。以下のスクリプトを使ってリストを生成してください。
|
||||
いずれにせよ、たった 3 文字なので bruteforce できる。リスト生成には以下のスクリプトを使う。
|
||||
```python
|
||||
from itertools import product
|
||||
from string import ascii_lowercase
|
||||
@@ -114,30 +134,30 @@ for comb in product(letter_combinations, number_combinations)
|
||||
with open('out.txt', 'w') as f:
|
||||
f.write('\n'.join(result))
|
||||
```
|
||||
次に wfuzz を使って
|
||||
wfuzz を使って次に
|
||||
```bash
|
||||
wfuzz -Z -z file,out.txt --hw 0 https://<cluster-id>.FUZZ.<region>.eks.amazonaws.com
|
||||
```
|
||||
> [!WARNING]
|
||||
> 置換することを忘れないでください & .
|
||||
> Remember to replace & .
|
||||
|
||||
### Bypass CloudTrail
|
||||
### CloudTrail バイパス
|
||||
|
||||
攻撃者が EKS に対する権限を持つ AWS の資格情報を入手した場合、攻撃者が前述のように自分の **`kubeconfig`**（**`update-kubeconfig`** を呼び出さずに）を設定すると、**`get-token`** は AWS API とやり取りしないため Cloudtrail にログを生成しません（ローカルでトークンを作成するだけです）。
|
||||
攻撃者が **EKS に対する権限** を持つ AWS の認証情報を入手した場合、攻撃者が前述のように **`update-kubeconfig`** を呼ばずに自分の **`kubeconfig`** を設定すると、**`get-token`** は AWS API とやり取りしないため、CloudTrail にログを生成しません（ローカルでトークンを作成するだけです）。
|
||||
|
||||
したがって、攻撃者が EKS クラスターとやり取りしても、cloudtrail は盗まれたユーザーによるアクセスに関連するログを何も記録しません。
|
||||
そのため、攻撃者が EKS クラスターと通信しても、**cloudtrail には、侵害されたユーザーがアクセスしたことに関連する何も記録されません**。
|
||||
|
||||
ただし、EKS クラスターでログが有効になっている場合は、このアクセスが記録される可能性があることに注意してください（デフォルトでは無効になっています）。
|
||||
ただし、**EKS クラスター側でログが有効**になっている場合、このアクセスは記録される可能性があります（ただし、デフォルトでは無効です）。
|
||||
|
||||
### EKS Ransom?
|
||||
|
||||
デフォルトでは、クラスターを作成したユーザーまたはロールは常にクラスターに対して管理者権限を持ちます。そして、それが AWS が Kubernetes クラスターに対して持つ唯一の「安全な」アクセスです。
|
||||
デフォルトでは、クラスターを作成した**ユーザーまたは role** は、**常に**そのクラスターに対する admin 権限を持ちます。そして、それが Kubernetes クラスターに対して AWS が持つ唯一の「安全な」アクセスです。
|
||||
|
||||
したがって、**攻撃者が fargate を使ってクラスターを乗っ取り**、**他のすべての管理者を排除し**、**クラスターを作成した AWS ユーザー/ロールを削除した**場合、~~the attacker could have **ransomed the cluste**~~**r**。
|
||||
そのため、**攻撃者が fargate を使用するクラスターを侵害し**、**他のすべての admins を削除し、クラスターを作成した AWS の user/role を削除**した場合、~~攻撃者は **cluste**~~**r** をランサムできた可能性があります。
|
||||
|
||||
> [!TIP]
|
||||
> クラスターが **EC2 VMs** を使用している場合、**Node** から管理者権限を取得してクラスターを回復できる可能性がある点に注意してください。
|
||||
> クラスターが **EC2 VMs** を使用していた場合、**Node** から Admin 権限を取得してクラスターを復旧できる可能性があります。
|
||||
>
|
||||
> 実際には、クラスターが Fargate を使用している場合でも、EC2 ノードを用意するかすべてを EC2 に移行してノード上のトークンにアクセスすることでクラスターを回復できる可能性があります。
|
||||
> 実際、クラスターが Fargate を使っている場合でも、EC2 nodes を使うか、すべてを EC2 に移して、node 内の token にアクセスしてクラスターを復旧できるかもしれません。
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user