GCP - Container Privesc
Tip
Impara e pratica il hacking AWS:
HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP:HackTricks Training GCP Red Team Expert (GRTE)
Impara e pratica il hacking Azure:
HackTricks Training Azure Red Team Expert (AzRTE)
Supporta HackTricks
- Controlla i piani di abbonamento!
- Unisciti al 💬 gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @hacktricks_live.
- Condividi trucchi di hacking inviando PR ai HackTricks e HackTricks Cloud repos su github.
container
container.clusters.get
Questa autorizzazione consente di raccogliere le credenziali del cluster Kubernetes usando ad esempio:
Get Kubernetes cluster credentials
```bash gcloud container clusters get-credentialsSenza permessi aggiuntivi, le credenziali sono piuttosto basilari poiché puoi semplicemente elencare qualche risorsa, ma sono utili per trovare misconfigurazioni nell’ambiente.
Note
Nota che kubernetes clusters potrebbero essere configurati come privati, il che impedirà l’accesso al Kube-API server da Internet.
Se non hai questo permesso puoi comunque accedere al cluster, ma devi creare il tuo kubectl config file con le informazioni del cluster. Uno appena generato appare così:
Esempio di kubectl config file per 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:container.roles.escalate | container.clusterRoles.escalate
Kubernetes di default impedisce ai soggetti di poter creare o aggiornare Roles e ClusterRoles con più permessi rispetto a quelli che il soggetto possiede. Tuttavia, un soggetto GCP con tali permessi sarà in grado di creare/aggiornare Roles/ClusterRoles con più permessi rispetto a quelli che aveva, bypassando di fatto la protezione di Kubernetes contro questo comportamento.
container.roles.create e/o container.roles.update oppure 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 di default impedisce ai soggetti di poter creare o aggiornare RoleBindings e ClusterRoleBindings per concedere più permessi rispetto a quelli che il soggetto possiede. Tuttavia, un soggetto GCP con tali permessi sarà in grado di creare/aggiornare RoleBindings/ClusterRoleBindings con più permessi rispetto a quelli che possiede, bypassando di fatto la protezione di Kubernetes contro questo comportamento.
container.roleBindings.create e/o container.roleBindings.update oppure 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 la SA che verrà attachata e l’image che verrà eseguita, quindi puoi eseguire un’immagine che esfiltrerà il token della SA al tuo server permettendoti di escalare a qualsiasi service account.
Per maggiori informazioni check:
Poiché siamo in un ambiente GCP, potrai anche ottenere la GCP SA del nodepool dal servizio di metadata e escalare i privilegi in GCP (di default viene usata la compute SA).
container.secrets.get | container.secrets.list
As explained in this page, con questi permessi puoi leggere i token di tutte le SAs di kubernetes, quindi puoi escalare a loro.
container.pods.exec
Con questo permesso sarai in grado di eseguire exec nei pod, il che ti dà accesso a tutte le SA Kubernetes in esecuzione nei pod per escalare i privilegi all’interno di K8s, ma potrai anche rubare la GCP Service Account del NodePool, escalare 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 permetterti di escalare i privilegi in Kubernetes (e in GCP se in qualche modo riesci a parlare con il metadata service).
container.serviceAccounts.createToken
A causa del nome del permesso, sembra che ti permetta di generare token delle Service Account di K8s, quindi saresti in grado di privesc to any SA all’interno di Kubernetes. Tuttavia, non sono riuscito a trovare alcun endpoint API per usarlo, fammi sapere se lo trovi.
container.mutatingWebhookConfigurations.create | container.mutatingWebhookConfigurations.update
Questi permessi potrebbero permetterti di scalare i privilegi in Kubernetes, ma più probabilmente potresti abusarne per persistere nel cluster.
Per maggiori informazioni follow this link.
Tip
Impara e pratica il hacking AWS:
HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP:HackTricks Training GCP Red Team Expert (GRTE)
Impara e pratica il hacking Azure:
HackTricks Training Azure Red Team Expert (AzRTE)
Supporta HackTricks
- Controlla i piani di abbonamento!
- Unisciti al 💬 gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @hacktricks_live.
- Condividi trucchi di hacking inviando PR ai HackTricks e HackTricks Cloud repos su github.
HackTricks Cloud

