GCP - Container Privesc
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
container.clusters.getCette permission permet de rassembler des identifiants pour le cluster Kubernetes en utilisant quelque chose comme :
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 :
container.roles.escalate | container.clusterRoles.escalateKubernetes 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 pourra 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.bindKubernetes 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 pourra 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.updateToutes ces permissions vous permettront 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.listComme 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.execAvec cette permission, vous pourrez exécuter des commandes 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.portForwardComme 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.createTokenEn 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 vous escalader à 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.updateCes 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.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
