GCP - Container Privesc

Support HackTricks

container

container.clusters.get

Questo permesso consente di raccogliere credenziali per il cluster Kubernetes utilizzando qualcosa come:

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

Senza permessi extra, le credenziali sono piuttosto basilari poiché puoi solo elencare alcune risorse, ma sono utili per trovare configurazioni errate nell'ambiente.

Nota che i cluster kubernetes potrebbero essere configurati per essere privati, il che impedirà l'accesso al server Kube-API da Internet.

Se non hai questo permesso, puoi comunque accedere al cluster, ma devi creare il tuo file di configurazione kubectl con le informazioni sui cluster. Uno generato di recente appare così:

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 per impostazione predefinita previene i principi dal poter creare o aggiornare Ruoli e ClusterRuoli con più permessi di quelli che il principio ha. Tuttavia, un principio GCP con quei permessi sarà in grado di creare/aggiornare Ruoli/ClusterRuoli con più permessi di quelli che detiene, bypassando effettivamente la protezione di Kubernetes contro questo comportamento.

container.roles.create e/o container.roles.update O container.clusterRoles.create e/o container.clusterRoles.update rispettivamente sono anche necessari per eseguire queste azioni di escalation dei privilegi.

container.roles.bind | container.clusterRoles.bind

Kubernetes per impostazione predefinita previene i principi dal poter creare o aggiornare RoleBindings e ClusterRoleBindings per dare più permessi di quelli che il principio ha. Tuttavia, un principio GCP con quei permessi sarà in grado di creare/aggiornare RoleBindings/ClusterRoleBindings con più permessi di quelli che ha, bypassando effettivamente la protezione di Kubernetes contro questo comportamento.

container.roleBindings.create e/o container.roleBindings.update O container.clusterRoleBindings.create e/o container.clusterRoleBindings.update rispettivamente sono anche necessari per eseguire queste azioni di escalation dei privilegi.

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

Tutti questi permessi ti permetteranno di creare o aggiornare una risorsa dove puoi definire un pod. Definendo un pod puoi specificare il SA che sarà allegato e l'immagine che sarà eseguita, quindi puoi eseguire un'immagine che esfiltra il token del SA al tuo server, permettendoti di escalare a qualsiasi account di servizio. Per ulteriori informazioni controlla:

Poiché siamo in un ambiente GCP, sarai anche in grado di ottenere il SA del nodepool GCP dal servizio metadata e escalare privilegi in GCP (per impostazione predefinita viene utilizzato il SA di calcolo).

container.secrets.get | container.secrets.list

Come spiegato in questa pagina, con questi permessi puoi leggere i token di tutti i SA di kubernetes, quindi puoi escalare a loro.

container.pods.exec

Con questo permesso sarai in grado di eseguire comandi nei pod, il che ti dà accesso a tutti i SA di Kubernetes in esecuzione nei pod per escalare privilegi all'interno di K8s, ma sarai anche in grado di rubare il GCP Service Account del NodePool, escalando privilegi in GCP.

container.pods.portForward

Come spiegato in questa pagina, con questi permessi puoi accedere ai servizi locali in esecuzione nei pod che potrebbero permetterti di escalare privilegi in Kubernetes (e in GCP se in qualche modo riesci a comunicare con il servizio metadata).

container.serviceAccounts.createToken

A causa del nome del permesso, sembra che ti permetterà di generare token degli K8s Service Accounts, quindi sarai in grado di escalare a qualsiasi SA all'interno di Kubernetes. Tuttavia, non sono riuscito a trovare alcun endpoint API da utilizzare, quindi fammi sapere se lo trovi.

container.mutatingWebhookConfigurations.create | container.mutatingWebhookConfigurations.update

Questi permessi potrebbero permetterti di escalare privilegi in Kubernetes, ma più probabilmente, potresti abusarne per persistere nel cluster. Per ulteriori informazioni segui questo link.

Support HackTricks

Last updated