GCP - Container Privesc

htARTE（HackTricks AWS Red Team Expert）を使用して、ゼロからヒーローまでAWSハッキングを学びましょう！

HackTricksをサポートする他の方法：

• HackTricksで企業を宣伝したい場合やHackTricksをPDFでダウンロードしたい場合は、SUBSCRIPTION PLANSをチェックしてください！

• 公式PEASS＆HackTricksのグッズを入手する

• The PEASS Familyを発見し、独占的なNFTsのコレクションを見つける

• 💬 Discordグループまたはtelegramグループに参加するか、Twitter 🐦 @hacktricks_liveでフォローする。

• HackTricksとHackTricks CloudのGitHubリポジトリにPRを提出して、あなたのハッキングテクニックを共有してください。

container

container.clusters.get

この権限を使用すると、次のような方法でKubernetesクラスターの資格情報を収集できます：

gcloud container clusters get-credentials <cluster_name> --zone <zone>

追加の権限がない場合、資格情報はかなり基本的ですが、いくつかのリソースをリストするだけできますが、環境の設定ミスを見つけるのに役立ちます。

kubernetesクラスターはプライベートに設定されている可能性があることに注意してください。これにより、インターネットからKube-APIサーバーへのアクセスが拒否されます。

この権限がない場合でも、クラスターにアクセスすることはできますが、クラスターの情報を含む独自のkubectl構成ファイルを作成する必要があります。新しく生成されたものは次のようになります：

apiVersion: v1
clusters:
- cluster:
certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUVMRENDQXBTZ0F3SUJBZ0lRRzNaQmJTSVlzeVRPR1FYODRyNDF3REFOQmdrcWhraUc5dzBCQVFzRkFEQXYKTVMwd0t3WURWUVFERXlRMk9UQXhZVEZoWlMweE56ZGxMVFF5TkdZdE9HVmhOaTAzWVdFM01qVmhNR05tTkdFdwpJQmNOTWpJeE1qQTBNakl4T1RJMFdoZ1BNakExTWpFeE1qWXlNekU1TWpSYU1DOHhMVEFyQmdOVkJBTVRKRFk1Ck1ERmhNV0ZsTFRFM04yVXROREkwWmkwNFpXRTJMVGRoWVRjeU5XRXdZMlkwWVRDQ0FhSXdEUVlKS29aSWh2Y04KQVFFQkJRQURnZ0dQQURDQ0FZb0NnZ0dCQU00TWhGemJ3Y3VEQXhiNGt5WndrNEdGNXRHaTZmb0pydExUWkI4Rgo5TDM4a2V2SUVWTHpqVmtoSklpNllnSHg4SytBUHl4RHJQaEhXMk5PczFNMmpyUXJLSHV6M0dXUEtRUmtUWElRClBoMy9MMDVtbURwRGxQK3hKdzI2SFFqdkE2Zy84MFNLakZjRXdKRVhZbkNMMy8yaFBFMzdxN3hZbktwTWdKVWYKVnoxOVhwNEhvbURvOEhUN2JXUTJKWTVESVZPTWNpbDhkdDZQd3FUYmlLNjJoQzNRTHozNzNIbFZxaiszNy90RgpmMmVwUUdFOG90a0VVOFlHQ3FsRTdzaVllWEFqbUQ4bFZENVc5dk1RNXJ0TW8vRHBTVGNxRVZUSzJQWk1rc0hyCmMwbGVPTS9LeXhnaS93TlBRdW5oQ2hnRUJIZTVzRmNxdmRLQ1pmUFovZVI1Qk0vc0w1WFNmTE9sWWJLa2xFL1YKNFBLNHRMVmpiYVg1VU9zMUZIVXMrL3IyL1BKQ2hJTkRaVTV2VjU0L1c5NWk4RnJZaUpEYUVGN0pveXJvUGNuMwpmTmNjQ2x1eGpOY1NsZ01ISGZKRzZqb0FXLzB0b2U3ek05RHlQOFh3NW44Zm5lQm5aVTFnYXNKREZIYVlZbXpGCitoQzFETmVaWXNibWNxOGVPVG9LOFBKRjZ3SURBUUFCbzBJd1FEQU9CZ05WSFE4QkFmOEVCQU1DQWdRd0R3WUQKVlIwVEFRSC9CQVV3QXdFQi96QWRCZ05WSFE0RUZnUVU5UkhvQXlxY3RWSDVIcmhQZ1BjYzF6Sm9kWFV3RFFZSgpLb1pJaHZjTkFRRUxCUUFEZ2dHQkFLbnp3VEx0QlJBVE1KRVB4TlBNbmU2UUNqZDJZTDgxcC9oeVc1eWpYb2w5CllkMTRRNFVlVUJJVXI0QmJadzl0LzRBQ3ZlYUttVENaRCswZ2wyNXVzNzB3VlFvZCtleVhEK2I1RFBwUUR3Z1gKbkJLcFFCY1NEMkpvZ29tT3M3U1lPdWVQUHNrODVvdWEwREpXLytQRkY1WU5ublc3Z1VLT2hNZEtKcnhuYUVGZAprVVl1TVdPT0d4U29qVndmNUsyOVNCbGJ5YXhDNS9tOWkxSUtXV2piWnZPN0s4TTlYLytkcDVSMVJobDZOSVNqCi91SmQ3TDF2R0crSjNlSjZneGs4U2g2L28yRnhxZWFNdDladWw4MFk4STBZaGxXVmlnSFMwZmVBUU1NSzUrNzkKNmozOWtTZHFBYlhPaUVOMzduOWp2dVlNN1ZvQzlNUk1oYUNyQVNhR2ZqWEhtQThCdlIyQW5iQThTVGpQKzlSMQp6VWRpK3dsZ0V4bnFvVFpBcUVHRktuUTlQcjZDaDYvR0xWWStqYXhuR3lyUHFPYlpNZTVXUDFOUGs4NkxHSlhCCjc1elFvanEyRUpxanBNSjgxT0gzSkxOeXRTdmt4UDFwYklxTzV4QUV0OWxRMjh4N28vbnRuaWh1WmR6M0lCRU8KODdjMDdPRGxYNUJQd0hIdzZtKzZjUT09Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
server: https://34.123.141.28
name: gke_security-devbox_us-central1_autopilot-cluster-1
contexts:
- context:
cluster: gke_security-devbox_us-central1_autopilot-cluster-1
user: gke_security-devbox_us-central1_autopilot-cluster-1
name: gke_security-devbox_us-central1_autopilot-cluster-1
current-context: gke_security-devbox_us-central1_autopilot-cluster-1
kind: Config
preferences: {}
users:
- name: gke_security-devbox_us-central1_autopilot-cluster-1
user:
auth-provider:
config:
access-token: <access token>
cmd-args: config config-helper --format=json
cmd-path: gcloud
expiry: "2022-12-06T01:13:11Z"
expiry-key: '{.credential.token_expiry}'
token-key: '{.credential.access_token}'
name: gcp

container.roles.escalate | container.clusterRoles.escalate

Kubernetesはデフォルトで、主体が持っている権限よりも多くの権限を持つRolesおよびClusterRolesを作成または更新することを防ぎます。しかし、その権限を持つGCPの主体は、この振る舞いに対するKubernetesの保護をバイパスして、より多くの権限を持つRoles/ClusterRolesを作成/更新することができます。

これらの特権昇格アクションを実行するには、それぞれ**container.roles.createおよび/またはcontainer.roles.updateまたはcontainer.clusterRoles.createおよび/またはcontainer.clusterRoles.updateも必要**です。

container.roles.bind | container.clusterRoles.bind

Kubernetesはデフォルトで、主体が持っている権限よりも多くの権限を持つRoleBindingsおよびClusterRoleBindingsを作成または更新することを防ぎます。しかし、その権限を持つGCPの主体は、この振る舞いに対するKubernetesの保護をバイパスして、より多くの権限を持つRolesBindings/ClusterRolesBindingsを作成/更新することができます。

これらの特権昇格アクションを実行するには、それぞれ**container.roleBindings.createおよび/またはcontainer.roleBindings.updateまたはcontainer.clusterRoleBindings.createおよび/またはcontainer.clusterRoleBindings.updateも必要**です。

container.cronJobs.create | container.cronJobs.update | container.daemonSets.create | container.daemonSets.update | container.deployments.create | container.deployments.update | container.jobs.create | container.jobs.update | container.pods.create | container.pods.update | container.replicaSets.create | container.replicaSets.update | container.replicationControllers.create | container.replicationControllers.update | container.scheduledJobs.create | container.scheduledJobs.update | container.statefulSets.create | container.statefulSets.update

これらの権限は、ポッドを定義できるリソースを作成または更新することを可能にします。ポッドを定義することで、アタッチされるSAと実行されるイメージを指定できます。したがって、SAのトークンをあなたのサーバーに漏洩させるイメージを実行することができ、任意のサービスアカウントに昇格することができます。 詳細については、以下を参照してください：

GCP環境にいるため、メタデータサービスからノードプールGCP SAを取得し、GCPで権限を昇格させることもできます（デフォルトではコンピュートSAが使用されます）。

container.secrets.get | container.secrets.list

これらの権限を持つと、このページで説明されているように、KubernetesのすべてのSAのトークンを読み取ることができるため、それらに昇格することができます。

container.pods.exec

この権限を持つと、ポッドにエグゼクティブできるため、K8s内で権限を昇格するために実行されているKubernetes SAにアクセスできますが、NodePoolのGCPサービスアカウントを盗むこともでき、GCPで権限を昇格させることができます。

container.pods.portForward

これらの権限を持つと、ポッドで実行されているローカルサービスにアクセスでき、それによりKubernetesで権限を昇格することができるかもしれません（そしてメタデータサービスに接続できればGCPで権限を昇格することができます）。

container.serviceAccounts.createToken

この権限の名前からすると、K8sサービスアカウントのトークンを生成できるように見えますので、Kubernetes内の任意のSAに特権昇格できるようになります。ただし、使用するAPIエンドポイントを見つけることができませんでしたので、見つけた場合はお知らせください。

container.mutatingWebhookConfigurations.create | container.mutatingWebhookConfigurations.update

これらの権限は、Kubernetesで権限を昇格させることができるかもしれませんが、より確実には、クラスターに永続化するためにそれらを悪用することができるかもしれません。 詳細については、このリンクを参照してください。