GCP - Container Privesc

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

container

container.clusters.get

Diese Berechtigung erlaubt es, Zugangsdaten für den Kubernetes-Cluster zu sammeln, z. B. mit:

Kubernetes-Cluster-Zugangsdaten abrufen ```bash gcloud container clusters get-credentials --zone ```

Ohne zusätzliche Berechtigungen sind die credentials ziemlich eingeschränkt, da du nur einige Ressourcen auflisten kannst, aber sie sind nützlich, um Fehlkonfigurationen in der Umgebung zu finden.

Note

Beachte, dass kubernetes clusters möglicherweise als privat konfiguriert sind, wodurch der Zugriff auf den Kube-API server aus dem Internet verhindert wird.

Wenn du diese Berechtigung nicht hast, kannst du trotzdem auf den Cluster zugreifen, musst jedoch deine eigene kubectl config file mit den Cluster-Infos erstellen. Eine neu generierte sieht so aus:

Beispiel kubectl config file für GKE cluster ```yaml 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: 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 Roles und ClusterRoles erstellen oder aktualisieren können, die über mehr Berechtigungen verfügen als der principal selbst. Ein GCP principal mit diesen Berechtigungen wird jedoch in der Lage sein, Roles/ClusterRoles mit mehr Berechtigungen zu erstellen/aktualisieren, als er zuvor besaß, und damit die Kubernetes-Schutzmechanismen effektiv umgehen.

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

container.roles.bind | container.clusterRoles.bind

Kubernetes verhindert standardmäßig, dass principals RoleBindings und ClusterRoleBindings erstellen oder aktualisieren können, um mehr Berechtigungen zu vergeben, als der principal hat. Ein GCP principal mit diesen Rechten kann jedoch RoleBindings/ClusterRoleBindings mit mehr Berechtigungen erstellen/aktualisieren, als er besitzt, und damit die Kubernetes-Schutzmaßnahmen umgehen.

container.roleBindings.create und/oder container.roleBindings.update ODER container.clusterRoleBindings.create und/oder container.clusterRoleBindings.update sind ebenfalls notwendig, um diese Privilegieneskalationen 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 erlauben es dir, eine Ressource zu erstellen oder zu aktualisieren, in der du einen Pod definieren kannst. Wenn du einen Pod definierst, kannst du das SA angeben, das angehängt wird, und das Image, das ausgeführt wird; dadurch kannst du ein Image starten, das das Token des SA an deinen Server exfiltriert, sodass du zu jedem Service Account eskalieren kannst.
Für weitere Informationen siehe:

Da wir uns in einer GCP-Umgebung befinden, kannst du außerdem das Nodepool-GCP-SA vom metadata service abrufen und Privilegien in GCP eskalieren (standardmäßig wird das Compute-SA verwendet).

container.secrets.get | container.secrets.list

Wie auf dieser Seite erklärt, kannst du mit diesen Berechtigungen die Tokens aller SAs von Kubernetes lesen, sodass du zu ihnen eskalieren kannst.

container.pods.exec

Mit dieser Berechtigung kannst du in Pods execen, was dir Zugriff auf alle Kubernetes SAs, die in Pods laufen, gibt, um innerhalb von K8s Privilegien zu eskalieren. Außerdem kannst du das GCP Service Account des NodePool stehlen und damit Privilegien in GCP eskalieren.

container.pods.portForward

Wie auf dieser Seite erklärt, ermöglichen dir diese Berechtigungen den Zugriff auf lokale Dienste, die in Pods laufen und dir möglicherweise erlauben, Privilegien in Kubernetes zu eskalieren (und in GCP, falls du es schaffst, mit dem metadata service zu kommunizieren).

container.serviceAccounts.createToken

Aufgrund des Namens der Berechtigung sieht es so aus, als würde sie dir erlauben, Tokens von K8s Service Accounts zu erzeugen, sodass du auf jeden SA innerhalb von Kubernetes eskalieren könntest. Allerdings konnte ich keinen API-Endpunkt finden, um sie zu nutzen — sag mir Bescheid, wenn du einen findest.

container.mutatingWebhookConfigurations.create | container.mutatingWebhookConfigurations.update

Diese Berechtigungen könnten dir erlauben, Privilegien in Kubernetes zu eskalieren; wahrscheinlicher ist jedoch, dass du sie missbrauchen könntest, um im Cluster persistiert zu bleiben.
Für weitere Informationen folge diesem Link.

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks