For the complete documentation index, see llms.txt. This page is also available as Markdown.

Kubernetes

Kubehound

Kubehound est un outil permettant de créer des graghiques de chemins d'attaque pour les clusters Kubernetes.

ressource: https://github.com/DataDog/KubeHound

Recon

Ouvrir un terminal dans un Pod:

kubectl exec -it <name> -- sh

Lister les permissions d'un Pod:

kubectl auth can-i --list

RCE via permission nodes/proxy

Description

la permission Kubernetes nodes/proxy GET, ressemblant d'apparence à une permission "read-only" peut être détournée pour exécuter des commandes à distance dans n’importe quel Pod accessible sur les nœuds du cluster.

Prérequis

  • Un service account avec la permission RBAC :

    • nodes/proxy avec le verbe GET

  • Une connectivité réseau vers le Kubelet (port 10250) des nœuds

  • Accès à un Pod ou un environnement où ce token est utilisable

  • Des outils capables de parler WebSocket (ex : websocat)

Détails techniques

1. Mauvaise interprétation RBAC

  • Kubernetes mappe les permissions RBAC selon la méthode HTTP.

  • GET autorise nodes/proxy GET, considéré comme lecture.

2. Problème avec WebSockets

  • L’endpoint /exec du Kubelet utilise WebSockets.

  • Une connexion WebSocket commence par un HTTP GET (upgrade handshake).

Résultat :

  • Le Kubelet valide uniquement le GET initial

  • Il ne revalide pas l’opération réelle (exec) après upgrade

3. Contournement

  • L’attaquant initie une connexion WebSocket vers /exec

  • L’autorisation est validée sur le GET du handshake

  • Puis la connexion est utilisée pour exécuter des commandes dans le conteneur

4. Impact

  • Exécution de commandes dans n’importe quel Pod accessible

  • Accès à des Pods système

  • Possibilité d’extraction de secrets et pivot dans le cluster

  • Potentiellement prise de contrôle complète du cluster

Proof Of Concept (PoC)

Sources

Mis à jour