GCP - Container Privesc

Support HackTricks

container

container.clusters.get

Cette permission permet de rassembler des identifiants pour le cluster Kubernetes en utilisant quelque chose comme :

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

Sans autorisations supplémentaires, les identifiants sont assez basiques car vous pouvez juste lister certaines ressources, mais ils sont utiles pour trouver des erreurs de configuration dans l'environnement.

Notez que les clusters kubernetes peuvent être configurés pour être privés, ce qui interdisera l'accès au serveur Kube-API depuis Internet.

Si vous n'avez pas cette autorisation, vous pouvez toujours accéder au cluster, mais vous devez créer votre propre fichier de configuration kubectl avec les informations des clusters. Un nouveau généré ressemble à ceci :

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 par défaut empêche les principaux de pouvoir créer ou mettre à jour des Rôles et des ClusterRoles avec plus de permissions que celles que le principal possède. Cependant, un principal GCP avec ces permissions sera capable de créer/mettre à jour des Rôles/ClusterRoles avec plus de permissions que celles qu'il détenait, contournant ainsi la protection de Kubernetes contre ce comportement.

container.roles.create et/ou container.roles.update OU container.clusterRoles.create et/ou container.clusterRoles.update respectivement sont également nécessaires pour effectuer ces actions d'escalade de privilèges.

container.roles.bind | container.clusterRoles.bind

Kubernetes par défaut empêche les principaux de pouvoir créer ou mettre à jour des RoleBindings et des ClusterRoleBindings pour donner plus de permissions que celles que le principal possède. Cependant, un principal GCP avec ces permissions sera capable de créer/mettre à jour des RoleBindings/ClusterRoleBindings avec plus de permissions que celles qu'il a, contournant ainsi la protection de Kubernetes contre ce comportement.

container.roleBindings.create et/ou container.roleBindings.update OU container.clusterRoleBindings.create et/ou container.clusterRoleBindings.update respectivement sont également nécessaires pour effectuer ces actions d'escalade de privilèges.

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

Toutes ces permissions vont vous permettre de créer ou mettre à jour une ressource où vous pouvez définir un pod. En définissant un pod, vous pouvez spécifier le SA qui va être attaché et l'image qui va être exécutée, vous permettant ainsi d'exécuter une image qui va exfiltrer le token du SA vers votre serveur, vous permettant d'escalader vers n'importe quel compte de service. Pour plus d'informations, consultez :

Étant dans un environnement GCP, vous pourrez également obtenir le SA du nodepool GCP à partir du service metadata et escalader les privilèges dans GCP (par défaut, le SA de calcul est utilisé).

container.secrets.get | container.secrets.list

Comme expliqué sur cette page, avec ces permissions, vous pouvez lire les tokens de tous les SAs de kubernetes, vous permettant ainsi de vous y escalader.

container.pods.exec

Avec cette permission, vous serez capable de exec dans des pods, ce qui vous donne accès à tous les SAs Kubernetes exécutés dans des pods pour escalader les privilèges au sein de K8s, mais vous pourrez également voler le Compte de Service GCP du NodePool, escaladant les privilèges dans GCP.

container.pods.portForward

Comme expliqué sur cette page, avec ces permissions, vous pouvez accéder aux services locaux exécutés dans des pods qui pourraient vous permettre d'escalader les privilèges dans Kubernetes (et dans GCP si d'une manière ou d'une autre vous parvenez à communiquer avec le service metadata).

container.serviceAccounts.createToken

En raison du nom de la permission, il semble que cela vous permettra de générer des tokens des Comptes de Service K8s, vous permettant ainsi de privesc à n'importe quel SA à l'intérieur de Kubernetes. Cependant, je n'ai pas trouvé d'endpoint API pour l'utiliser, donc faites-moi savoir si vous le trouvez.

container.mutatingWebhookConfigurations.create | container.mutatingWebhookConfigurations.update

Ces permissions pourraient vous permettre d'escalader les privilèges dans Kubernetes, mais plus probablement, vous pourriez les abuser pour persister dans le cluster. Pour plus d'informations, suivez ce lien.

Support HackTricks

Last updated