GCP - Container Privesc

Erlernen Sie AWS-Hacking von Grund auf mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

container

container.clusters.get

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

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, und somit die Kubernetes-Schutzmaßnahmen umgehen.

container.roles.create und/oder container.roles.update ODER container.clusterRoles.create und/oder container.clusterRoles.update sind ebenfalls erforderlich, um diese Privilegien-Eskalationsaktionen durchzuführen.

container.roles.bind | container.clusterRoles.bind

Kubernetes verhindert standardmäßig, dass Prinzipale Rollenbindungen und Cluster-Rollenbindungen erstellen oder aktualisieren, um mehr Berechtigungen zu vergeben als die, die der Prinzipal hat. Ein GCP-Prinzipal mit diesen Berechtigungen kann jedoch Rollenbindungen/Cluster-Rollenbindungen mit mehr Berechtigungen erstellen/aktualisieren, und somit die Kubernetes-Schutzmaßnahmen umgehen.

container.roleBindings.create und/oder container.roleBindings.update ODER container.clusterRoleBindings.create und/oder container.clusterRoleBindings.update sind ebenfalls erforderlich, um diese Privilegien-Eskalationsaktionen 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. Somit können Sie ein Image ausführen, das das Token des SA auf Ihren Server exfiltriert, 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 das 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

Mit diesen Berechtigungen können Sie, wie auf dieser Seite erklärt, die Token aller SAs von Kubernetes lesen, und somit zu ihnen eskalieren.

container.pods.exec

Mit dieser Berechtigung können Sie in Pods eintreten, was Ihnen Zugriff auf alle in den Pods ausgeführten Kubernetes-SAs gibt, um Privilegien innerhalb von K8s zu eskalieren. Außerdem können Sie das GCP-Dienstkonto 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, Privilegien in Kubernetes (und in GCP, wenn Sie irgendwie mit dem Metadatendienst kommunizieren können) zu eskalieren.

container.serviceAccounts.createToken

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

container.mutatingWebhookConfigurations.create | container.mutatingWebhookConfigurations.update

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

Erlernen Sie AWS-Hacking von Null auf Held mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

Last updated