GCP - Container Privesc

Reading time: 5 minutes

container

container.clusters.get

Diese Berechtigung ermöglicht es, Anmeldeinformationen für den Kubernetes-Cluster zu sammeln mit etwas wie:

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

Ohne zusätzliche Berechtigungen sind die Anmeldeinformationen ziemlich grundlegend, da Sie einige Ressourcen auflisten können, aber sie sind nützlich, um Fehlkonfigurationen in der Umgebung zu finden.

Wenn Sie diese Berechtigung nicht haben, können Sie dennoch auf den Cluster zugreifen, müssen jedoch Ihre eigene kubectl-Konfigurationsdatei mit den Clusterinformationen erstellen. Eine neu generierte sieht so aus:

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 verhindert standardmäßig, dass Principals Rollen und ClusterRollen mit mehr Berechtigungen erstellen oder aktualisieren, als die, die der Principal hat. Ein GCP-Principal mit diesen Berechtigungen wird jedoch in der Lage sein, Rollen/ClusterRollen mit mehr Berechtigungen zu erstellen/aktualisieren, als er besitzt, und damit den Kubernetes-Schutz gegen dieses Verhalten zu umgehen.

container.roles.create und/oder container.roles.update ODER container.clusterRoles.create und/oder container.clusterRoles.update sind ebenfalls notwendig, um diese Privilegieneskalationsaktionen durchzuführen.

container.roles.bind | container.clusterRoles.bind

Kubernetes verhindert standardmäßig, dass Principals RoleBindings und ClusterRoleBindings erstellen oder aktualisieren, um mehr Berechtigungen zu vergeben, als die, die der Principal hat. Ein GCP-Principal mit diesen Berechtigungen wird jedoch in der Lage sein, RoleBindings/ClusterRoleBindings mit mehr Berechtigungen zu erstellen/aktualisieren, als er hat, und damit den Kubernetes-Schutz gegen dieses Verhalten zu umgehen.

container.roleBindings.create und/oder container.roleBindings.update ODER container.clusterRoleBindings.create und/oder container.clusterRoleBindings.update sind ebenfalls notwendig, um diese Privilegieneskalationsaktionen durchzuführen.

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

All diese Berechtigungen ermöglichen es Ihnen, eine Ressource zu erstellen oder zu aktualisieren, bei der Sie einen Pod definieren können. Indem Sie einen Pod definieren, können Sie die SA angeben, die angehängt wird, und das Image, das ausgeführt wird. Daher können Sie ein Image ausführen, das das Token der SA an Ihren Server exfiltriert, wodurch Sie auf jedes Dienstkonto eskalieren können.
Für weitere Informationen siehe:

Da wir uns in einer GCP-Umgebung befinden, werden Sie auch in der Lage sein, die Nodepool GCP SA vom Metadaten-Dienst abzurufen und Privilegien in GCP zu eskalieren (standardmäßig wird die Compute SA verwendet).

container.secrets.get | container.secrets.list

Wie auf dieser Seite erklärt, können Sie mit diesen Berechtigungen die Tokens aller SAs von Kubernetes lesen, sodass Sie zu ihnen eskalieren können.

container.pods.exec

Mit dieser Berechtigung können Sie in Pods ausführen, was Ihnen Zugriff auf alle Kubernetes SAs, die in Pods ausgeführt werden, gibt, um Privilegien innerhalb von K8s zu eskalieren. Sie werden auch in der Lage sein, die GCP Service Account des NodePools zu stehlen, wodurch Sie die Privilegien in GCP eskalieren.

container.pods.portForward

Wie auf dieser Seite erklärt, können Sie mit diesen Berechtigungen auf lokale Dienste zugreifen, die in Pods ausgeführt werden und Ihnen möglicherweise ermöglichen, Privilegien in Kubernetes (und in GCP, wenn Sie es schaffen, mit dem Metadaten-Dienst zu kommunizieren) zu eskalieren.**

container.serviceAccounts.createToken

Aufgrund des Namens der Berechtigung sieht es so aus, als würde es Ihnen erlauben, Tokens der K8s Service Accounts zu generieren, sodass Sie zu jedem SA innerhalb von Kubernetes eskalieren können. Ich konnte jedoch keinen API-Endpunkt finden, um ihn zu verwenden, lassen Sie es mich wissen, wenn Sie ihn finden.

container.mutatingWebhookConfigurations.create | container.mutatingWebhookConfigurations.update

Diese Berechtigungen könnten Ihnen ermöglichen, Privilegien in Kubernetes zu eskalieren, aber wahrscheinlicher ist, dass Sie sie missbrauchen könnten, um im Cluster persistent zu bleiben.
Für weitere Informationen folgen Sie diesem Link.