GCP - Container Privesc

Aprenda hacking na AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras maneiras de apoiar o HackTricks:

contêiner

container.clusters.get

Essa permissão permite coletar credenciais para o cluster Kubernetes usando algo como:

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

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

Observe que os clusters Kubernetes podem ser configurados para serem privados, o que impedirá o acesso ao servidor Kube-API pela Internet.

Se você não tiver essa permissão, ainda poderá acessar o cluster, mas precisará criar seu próprio arquivo de configuração kubectl com as informações do cluster. Um novo arquivo gerado se parece com isso:

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 padrão impede que os princípios consigam criar ou atualizar Funções e Funções de Cluster com mais permissões do que as que o princípio possui. No entanto, um princípio do GCP com essas permissões será capaz de criar/atualizar Funções/Funções de Cluster com mais permissões do que as que ele possui, efetivamente contornando a proteção do Kubernetes contra esse comportamento.

container.roles.create e/ou container.roles.update OU container.clusterRoles.create e/ou container.clusterRoles.update respectivamente também são necessários para realizar essas ações de escalonamento de privilégios.

container.roles.bind | container.clusterRoles.bind

Kubernetes por padrão impede que os princípios consigam criar ou atualizar Vinculações de Funções e Vinculações de Funções de Cluster para conceder mais permissões do que as que o princípio possui. No entanto, um princípio do GCP com essas permissões será capaz de criar/atualizar Vinculações de Funções/Vinculações de Funções de Cluster com mais permissões do que as que ele possui, efetivamente contornando a proteção do Kubernetes contra esse comportamento.

container.roleBindings.create e/ou container.roleBindings.update OU container.clusterRoleBindings.create e/ou container.clusterRoleBindings.update respectivamente também são necessários 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 o SA que será anexado e a imagem que será executada, portanto você pode executar uma imagem que vai extrair o token do SA para o seu servidor permitindo que você escale para qualquer conta de serviço. Para mais informações, consulte:

Como estamos em um ambiente do GCP, você também será capaz de obter o SA do nodepool do GCP do serviço de metadados e escalar privilégios no GCP (por padrão, o SA de computação é usado).

container.secrets.get | container.secrets.list

Como explicado nesta página, com essas permissões você pode ler os tokens de todos os SAs do Kubernetes, então você pode escalar para eles.

container.pods.exec

Com essa permissão, você será capaz de executar em pods, o que lhe dá acesso a todos os SAs do Kubernetes em execução nos pods para escalar privilégios dentro do K8s, mas também será capaz de roubar a Conta de Serviço do GCP 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 em pods que podem permitir que você escale privilégios no Kubernetes (e no GCP se de alguma forma você conseguir se comunicar com o serviço de metadados).

container.serviceAccounts.createToken

Devido ao nome da permissão, parece que ela permitirá que você gere tokens das Contas de Serviço do K8s, então você será capaz de escalar para qualquer SA dentro do Kubernetes. No entanto, não consegui encontrar nenhum endpoint de API para usá-lo, 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 siga este link.

Aprenda hacking AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras formas de apoiar o HackTricks:

Última actualización