GCP - Container Privesc

Tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

container

container.clusters.get

Esta permissão permite obter credenciais do cluster Kubernetes usando algo como:

Obter credenciais do cluster Kubernetes ```bash gcloud container clusters get-credentials --zone ```

Sem permissões extras, as credenciais são bastante básicas, pois você pode apenas listar algum recurso, mas são úteis para encontrar misconfigurações no ambiente.

Note

Note que kubernetes clusters podem estar configurados como privados, o que impedirá o acesso ao servidor Kube-API a partir da Internet.

Se você não tiver essa permissão, ainda pode acessar o cluster, mas precisa criar seu próprio arquivo de configuração kubectl com as informações do cluster. Um arquivo recém-gerado fica assim:

Exemplo de arquivo de configuração kubectl para cluster GKE ```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: 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 padrão impede que principals consigam criar ou atualizar Roles e ClusterRoles com mais permissões do que as que o principal possui. No entanto, um principal do GCP com essa permissão será capaz de criar/atualizar Roles/ClusterRoles com mais permissões do que as que ele detinha, efetivamente contornando a proteção do Kubernetes contra esse comportamento.

container.roles.create and/or container.roles.update OR container.clusterRoles.create and/or container.clusterRoles.update respectivamente são também necessárias para realizar essas ações de escalonamento de privilégios.

container.roles.bind | container.clusterRoles.bind

Kubernetes por padrão impede que principals consigam criar ou atualizar RoleBindings e ClusterRoleBindings para conceder mais permissões do que as que o principal possui. No entanto, um principal do GCP com essa permissão será capaz de criar/atualizar RolesBindings/ClusterRolesBindings com mais permissões do que as que ele tem, efetivamente contornando a proteção do Kubernetes contra esse comportamento.

container.roleBindings.create and/or container.roleBindings.update OR container.clusterRoleBindings.create and/or container.clusterRoleBindings.update respectivamente são também necessárias para realizar essas ações de escalonamento de privilégios.

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

Todas essas permissões vão permitir que você crie ou atualize um recurso onde você pode definir um pod. Ao definir um pod você pode especificar a SA que será anexada e a image que será executada, portanto você pode executar uma image que vai exfiltrate the token of the SA to your server permitindo que você escale para qualquer service account.
Para mais informações verifique:

Como estamos em um ambiente GCP, você também poderá obter o nodepool GCP SA a partir do metadata service e escalar privilégios no GCP (por padrão o compute SA é usado).

container.secrets.get | container.secrets.list

Como explicado nesta página, com essas permissões você pode ler os tokens de todas as SAs do kubernetes, então você pode escalar para elas.

container.pods.exec

Com essa permissão você poderá exec into pods, o que lhe dá acesso a todas as SAs do Kubernetes em execução em pods para escalar privilégios dentro do K8s, e também permitirá roubar o GCP Service Account do NodePool, escalando privilégios no GCP.

container.pods.portForward

Como explicado nesta página, com essas permissões você pode acessar serviços locais executando em pods que podem permitir que você escalar privilégios no Kubernetes (e no GCP se de alguma forma você conseguir falar com o serviço de metadata).

container.serviceAccounts.createToken

Por causa do nome da permissão, parece que ela permitiria gerar tokens das K8s Service Accounts, então você seria capaz de privesc to any SA dentro do Kubernetes. No entanto, não consegui encontrar nenhum endpoint de API para usá-la, então me avise se você encontrar.

container.mutatingWebhookConfigurations.create | container.mutatingWebhookConfigurations.update

Essas permissões podem permitir que você escale privilégios no Kubernetes, mas, mais provavelmente, você poderia abusar delas para persistir no cluster.
Para mais informações follow this link.

Tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks