Italian - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

GCP - Container Privesc

Impara l'hacking di AWS da zero a esperto con htARTE (HackTricks AWS Red Team Expert)!

Altri modi per supportare HackTricks:

container

container.clusters.get

Questa autorizzazione consente di raccogliere le credenziali per il cluster Kubernetes utilizzando qualcosa come:

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

Senza permessi aggiuntivi, le credenziali sono piuttosto di base in quanto è possibile solo elencare alcune risorse, ma sono utili per individuare errori di configurazione nell'ambiente.

Nota che i cluster Kubernetes potrebbero essere configurati come privati, il che impedisce 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 del cluster. Uno nuovo generato 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

Di default, Kubernetes impedisce ai principali di poter creare o aggiornare Ruoli e ClusterRoles con più permessi di quelli che il principale possiede. Tuttavia, un principale di GCP con tali permessi sarà in grado di creare/aggiornare Ruoli/ClusterRoles con più permessi di quelli che possiede, eludendo efficacemente la protezione di Kubernetes contro questo comportamento.

È necessario anche avere i permessi container.roles.create e/o container.roles.update OPPURE container.clusterRoles.create e/o container.clusterRoles.update per eseguire queste azioni di escalation dei privilegi.

container.roles.bind | container.clusterRoles.bind

Di default, Kubernetes impedisce ai principali di poter creare o aggiornare RoleBindings e ClusterRoleBindings per concedere più permessi di quelli che il principale possiede. Tuttavia, un principale di GCP con tali permessi sarà in grado di creare/aggiornare RoleBindings/ClusterRoleBindings con più permessi di quelli che possiede, eludendo efficacemente la protezione di Kubernetes contro questo comportamento.

È necessario anche avere i permessi container.roleBindings.create e/o container.roleBindings.update OPPURE container.clusterRoleBindings.create e/o container.clusterRoleBindings.update 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 consentiranno di creare o aggiornare una risorsa in cui puoi definire un pod. Definendo un pod, puoi specificare l'account di servizio (SA) che verrà associato e l'immagine che verrà eseguita, quindi puoi eseguire un'immagine che esfiltrerà il token dell'account di servizio al tuo server, consentendoti di scalare a qualsiasi account di servizio. Per ulteriori informazioni, consulta:

Poiché ci troviamo in un ambiente GCP, sarai anche in grado di ottenere l'account di servizio GCP del nodepool dal servizio di metadati e aumentare i privilegi in GCP (di default viene utilizzato l'account di servizio di calcolo).

container.secrets.get | container.secrets.list

Con questi permessi, come spiegato in questa pagina, puoi leggere i token di tutti gli account di servizio di Kubernetes, quindi puoi aumentare i privilegi su di essi.

container.pods.exec

Con questo permesso sarai in grado di eseguire comandi nei pod, il che ti dà accesso a tutti gli account di servizio di Kubernetes in esecuzione nei pod per aumentare i privilegi all'interno di K8s, ma sarai anche in grado di rubare l'account di servizio GCP del NodePool, aumentando i 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 consentirti di aumentare i privilegi in Kubernetes (e in GCP se in qualche modo riesci a comunicare con il servizio di metadati).

container.serviceAccounts.createToken

A causa del nome del permesso, sembra che ti permetta di generare token degli account di servizio di K8s, quindi sarai in grado di aumentare i privilegi a qualsiasi SA all'interno di Kubernetes. Tuttavia, non ho trovato alcun endpoint API da utilizzare, quindi fammi sapere se lo trovi.

container.mutatingWebhookConfigurations.create | container.mutatingWebhookConfigurations.update

Questi permessi potrebbero consentirti di aumentare i privilegi in Kubernetes, ma più probabilmente potresti abusarne per persistere nel cluster. Per ulteriori informazioni, seguire questo link.

Impara l'hacking di AWS da zero a esperto con htARTE (HackTricks AWS Red Team Expert)!

Altri modi per supportare HackTricks:

PreviousGCP - Composer PrivescNextGCP - Deploymentmaneger Privesc

Last updated