GCP - Container Privesc

Unterstützen Sie HackTricks

container

container.clusters.get

Diese Berechtigung ermöglicht es, Anmeldeinformationen für den Kubernetes-Cluster zu sammeln, indem beispielsweise Folgendes verwendet wird:

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

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

Beachten Sie, dass Kubernetes-Cluster möglicherweise so konfiguriert sind, dass sie privat sind, was den Zugriff auf den Kube-API-Server aus dem Internet verhindert.

Wenn Sie diese Berechtigung nicht haben, können Sie dennoch auf den Cluster zugreifen, aber Sie müssen Ihre eigene kubectl-Konfigurationsdatei erstellen mit den Clusterinformationen. 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 Prinzipale Rollen und Cluster-Rollen mit mehr Berechtigungen erstellen oder aktualisieren können als die, die der Prinzipal hat. Ein GCP-Prinzipal mit diesen Berechtigungen kann jedoch Rollen/Cluster-Rollen mit mehr Berechtigungen erstellen/aktualisieren, als er besitzt, und somit den Schutz von Kubernetes gegen dieses Verhalten umgehen.

container.roles.create und/oder container.roles.update ODER container.clusterRoles.create und/oder container.clusterRoles.update sind ebenfalls erforderlich, um diese Eskalation von Berechtigungen durchzuführen.

container.roles.bind | container.clusterRoles.bind

Kubernetes verhindert standardmäßig, dass Prinzipale Rollenbindungen und Cluster-Rollenbindungen erstellen/aktualisieren, um mehr Berechtigungen zu vergeben, als der Prinzipal hat. Ein GCP-Prinzipal mit diesen Berechtigungen kann jedoch Rollenbindungen/Cluster-Rollenbindungen mit mehr Berechtigungen erstellen/aktualisieren, als er besitzt, und somit den Schutz von Kubernetes gegen dieses Verhalten umgehen.

container.roleBindings.create und/oder container.roleBindings.update ODER container.clusterRoleBindings.create und/oder container.clusterRoleBindings.update sind ebenfalls erforderlich, um diese Eskalation von Berechtigungen 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

Alle diese Berechtigungen ermöglichen es Ihnen, eine Ressource zu erstellen oder zu aktualisieren, in der Sie ein Pod definieren können. Durch die Definition eines Pods können Sie den SA angeben, der angehängt wird, und das Image, das ausgeführt wird. Dadurch können Sie ein Image ausführen, das das Token des SA auf Ihren Server extrahiert, was es Ihnen ermöglicht, zu einem beliebigen Dienstkontos zu eskalieren. Für weitere Informationen siehe:

Da wir uns in einer GCP-Umgebung befinden, können Sie auch den Nodepool GCP SA aus dem Metadatendienst abrufen und Berechtigungen in GCP eskalieren (standardmäßig wird der Compute SA verwendet).

container.secrets.get | container.secrets.list

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

container.pods.exec

Mit dieser Berechtigung können Sie in Pods ausführen, was Ihnen Zugriff auf alle in Pods laufenden Kubernetes SAs gibt, um Berechtigungen innerhalb von K8s zu eskalieren. Außerdem können Sie das GCP Servicekonto des NodePools stehlen, um Berechtigungen in GCP zu eskalieren.

container.pods.portForward

Wie auf dieser Seite erklärt, können Sie mit diesen Berechtigungen auf lokale Dienste in Pods zugreifen, die es Ihnen ermöglichen könnten, Berechtigungen in Kubernetes zu eskalieren (und in GCP, wenn Sie irgendwie mit dem Metadatendienst kommunizieren können).

container.serviceAccounts.createToken

Aufgrund des Namens der Berechtigung scheint es, dass Sie Tokens der K8s-Servicekonten generieren können, sodass Sie zu einem beliebigen SA innerhalb von Kubernetes eskaliert werden können. Ich konnte jedoch keinen API-Endpunkt finden, um dies zu verwenden. Lassen Sie mich wissen, wenn Sie ihn finden.

container.mutatingWebhookConfigurations.create | container.mutatingWebhookConfigurations.update

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

Unterstützen Sie HackTricks

Last updated