Italian - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

GCP - Container Privesc

Impara e pratica l'hacking su AWS: HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica l'hacking su GCP: HackTricks Training GCP Red Team Expert (GRTE)

Sostieni HackTricks

container

container.clusters.get

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

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 si dispone di questo permesso, è comunque possibile accedere al cluster, ma è necessario creare il proprio file di configurazione kubectl con le informazioni del cluster. Un file appena 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

Kubernetes di default 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 quei 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.

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

container.roles.bind | container.clusterRoles.bind

Kubernetes di default 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 quei permessi sarà in grado di creare/aggiornare RoleBindings/ClusterRolesBindings con più permessi di quelli che possiede, eludendo efficacemente 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 tali 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 in cui puoi definire un pod. Definendo un pod puoi specificare l'account di servizio 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 controlla:

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 escalare i privilegi in GCP (per impostazione predefinita viene utilizzato l'account di servizio di calcolo).

container.secrets.get | container.secrets.list

Come spiegato in questa pagina, con questi permessi puoi leggere i token di tutti gli account di servizio di Kubernetes, quindi puoi scalare a 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 scalare i privilegi all'interno di K8s, ma sarai anche in grado di rubare l'Account di servizio GCP del NodePool, escalando 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 scalare 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 permetterà di generare token degli Account di servizio di K8s, quindi sarai in grado di escalare a qualsiasi SA all'interno di Kubernetes. Tuttavia, non ho trovato nessun endpoint API da utilizzare, quindi fammi sapere se lo trovi.

container.mutatingWebhookConfigurations.create | container.mutatingWebhookConfigurations.update

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

Impara e pratica l'hacking su AWS:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica l'hacking su GCP: HackTricks Training GCP Red Team Expert (GRTE)

Supporta HackTricks
PreviousGCP - Composer PrivescNextGCP - Deploymentmaneger Privesc

Last updated