GCP - Container Privesc

Support HackTricks

contenedor

container.clusters.get

Este permiso permite reunir credenciales para el clúster de Kubernetes utilizando algo como:

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

Sin permisos adicionales, las credenciales son bastante básicas ya que solo puedes listar algunos recursos, pero son útiles para encontrar configuraciones incorrectas en el entorno.

Ten en cuenta que los clústeres de kubernetes pueden estar configurados para ser privados, lo que impedirá el acceso al servidor Kube-API desde Internet.

Si no tienes este permiso, aún puedes acceder al clúster, pero necesitas crear tu propio archivo de configuración kubectl con la información de los clústeres. Uno generado recientemente se ve así:

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 por defecto previene que los principales puedan crear o actualizar Roles y ClusterRoles con más permisos que los que el principal tiene. Sin embargo, un principal de GCP con esos permisos podrá crear/actualizar Roles/ClusterRoles con más permisos que los que posee, eludiendo efectivamente la protección de Kubernetes contra este comportamiento.

container.roles.create y/o container.roles.update O container.clusterRoles.create y/o container.clusterRoles.update respectivamente son también necesarios para realizar esas acciones de escalada de privilegios.

container.roles.bind | container.clusterRoles.bind

Kubernetes por defecto previene que los principales puedan crear o actualizar RoleBindings y ClusterRoleBindings para otorgar más permisos que los que el principal tiene. Sin embargo, un principal de GCP con esos permisos podrá crear/actualizar RoleBindings/ClusterRoleBindings con más permisos que los que tiene, eludiendo efectivamente la protección de Kubernetes contra este comportamiento.

container.roleBindings.create y/o container.roleBindings.update O container.clusterRoleBindings.create y/o container.clusterRoleBindings.update respectivamente también son necesarios para realizar esas acciones de escalada de privilegios.

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

Todos estos permisos te permitirán crear o actualizar un recurso donde puedes definir un pod. Al definir un pod puedes especificar el SA que va a ser adjunto y la imagen que va a ser ejecutada, por lo tanto puedes ejecutar una imagen que va a exfiltrar el token del SA a tu servidor, permitiéndote escalar a cualquier cuenta de servicio. Para más información consulta:

Como estamos en un entorno de GCP, también podrás obtener el SA del nodepool de GCP del servicio de metadata y escalar privilegios en GCP (por defecto se utiliza el SA de cómputo).

container.secrets.get | container.secrets.list

Como se explica en esta página, con estos permisos puedes leer los tokens de todos los SAs de kubernetes, por lo que puedes escalar a ellos.

container.pods.exec

Con este permiso podrás ejecutar comandos en pods, lo que te da acceso a todos los SAs de Kubernetes que se ejecutan en pods para escalar privilegios dentro de K8s, pero también podrás robar la Cuenta de Servicio de GCP del NodePool, escalando privilegios en GCP.

container.pods.portForward

Como se explica en esta página, con estos permisos puedes acceder a servicios locales que se ejecutan en pods que podrían permitirte escalar privilegios en Kubernetes (y en GCP si de alguna manera logras comunicarte con el servicio de metadata).

container.serviceAccounts.createToken

Debido al nombre del permiso, parece que te permitirá generar tokens de las Cuentas de Servicio de K8s, por lo que podrás escalar a cualquier SA dentro de Kubernetes. Sin embargo, no pude encontrar ningún endpoint de API para usarlo, así que házmelo saber si lo encuentras.

container.mutatingWebhookConfigurations.create | container.mutatingWebhookConfigurations.update

Estos permisos podrían permitirte escalar privilegios en Kubernetes, pero más probablemente, podrías abusar de ellos para persistir en el clúster. Para más información sigue este enlace.

Support HackTricks

Last updated