Español - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

GCP - Container Privesc

Aprende a hackear AWS de cero a héroe con htARTE (Experto en equipos rojos de HackTricks AWS)!

Otras formas de apoyar a HackTricks:

contenedor

container.clusters.get

Este permiso permite recopilar 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 enumerar algunos recursos, pero son útiles para encontrar configuraciones incorrectas en el entorno.

Ten en cuenta que los clústeres de Kubernetes pueden estar configurados como 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 recién generado 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 impide que los principios puedan crear o actualizar Roles y ClusterRoles con más permisos que los que el principio tiene. Sin embargo, un principio de GCP con esos permisos podrá crear/actualizar Roles/ClusterRoles con más permisos que los que tiene, evitando 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 también son necesarios para realizar esas acciones de escalada de privilegios.

container.roles.bind | container.clusterRoles.bind

Kubernetes por defecto impide que los principios puedan crear o actualizar RoleBindings y ClusterRoleBindings para otorgar más permisos que los que el principio tiene. Sin embargo, un principio de GCP con esos permisos podrá crear/actualizar RoleBindings/ClusterRolesBindings con más permisos que los que tiene, evitando 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 estar adjunto y la imagen que se va a ejecutar, por lo tanto puedes ejecutar una imagen que va a filtrar el token del SA a tu servidor permitiéndote escalar a cualquier cuenta de servicio. Para más información consulta:

Dado que estamos en un entorno de GCP, también podrás obtener el SA del nodepool de GCP desde el servicio de metadatos y escalar privilegios en GCP (por defecto se usa el SA de computación).

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 metadatos).

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 privilegios a cualquier SA dentro de Kubernetes. Sin embargo, no pude encontrar ningún punto de API para usarlo, así que avísame 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.

Aprende hacking en AWS desde cero hasta experto con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

AnteriorGCP - Composer PrivescSiguienteGCP - Deploymentmaneger Privesc

Última actualización