GCP - Container Privesc
Last updated
Last updated
AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE)
container.clusters.getこの権限は、次のような方法でKubernetesクラスターの資格情報を収集することを許可します：
追加の権限がなくても、資格情報は非常に基本的で、いくつかのリソースをリストすることができますが、環境内の設定ミスを見つけるのに役立ちます。
Kubernetesクラスターはプライベートに設定されている可能性があるため、インターネットからKube-APIサーバーへのアクセスが禁止されます。
この権限がない場合でもクラスターにアクセスできますが、クラスターの情報を含む独自のkubectl設定ファイルを作成する必要があります。新しく生成されたものは次のようになります：
container.roles.escalate | container.clusterRoles.escalateKubernetes はデフォルトで、プリンシパルが自分が持っている権限よりも 多くの権限 を持つ Roles と ClusterRoles を 作成 または 更新 できないように 防止 します。しかし、権限を持つ GCP プリンシパルは、自分が持っている権限よりも 多くの権限 を持つ Roles/ClusterRoles を 作成/更新 でき、実質的にこの動作に対する Kubernetes の保護を回避します。
container.roles.create および/または container.roles.update または container.clusterRoles.create および/または container.clusterRoles.update は、それらの特権昇格アクションを実行するために 必要 です。
container.roles.bind | container.clusterRoles.bindKubernetes はデフォルトで、プリンシパルが自分が持っている権限よりも 多くの権限 を与える RoleBindings と ClusterRoleBindings を 作成 または 更新 できないように 防止 します。しかし、権限を持つ GCP プリンシパルは、自分が持っている権限よりも 多くの権限 を持つ RolesBindings/ClusterRolesBindings を 作成/更新 でき、実質的にこの動作に対する Kubernetes の保護を回避します。
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この権限を持つことで、ポッドに exec でき、Kubernetes のポッドで実行されているすべての SA に アクセス して K8s 内で権限を昇格させることができますが、ノードプールの GCP サービスアカウント を 盗む こともでき、GCP で権限を昇格させることができます。
container.pods.portForwardこのページで説明されているように、これらの権限を使用すると、ポッド で実行されている ローカルサービス に アクセス でき、Kubernetes で権限を昇格させることができるかもしれません（そして、GCP でも、何らかの方法でメタデータサービスにアクセスできれば）。
container.serviceAccounts.createToken権限の名前 から判断すると、K8s サービスアカウントのトークンを生成することを許可する ように見え、Kubernetes 内の任意の SA に 昇格 できるようになります。しかし、使用する API エンドポイントを見つけることができなかったので、見つけたら教えてください。
container.mutatingWebhookConfigurations.create | container.mutatingWebhookConfigurations.updateこれらの権限は、Kubernetes で権限を昇格させることを可能にするかもしれませんが、より可能性が高いのは、クラスターに持続する ためにそれらを悪用できることです。 詳細については、このリンクをフォローしてください。
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
