Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Dans Kubernetes, il est observé qu'un comportement par défaut permet l'établissement de connexions entre tous les conteneurs résidant sur le même nœud. Cela s'applique indépendamment des distinctions de namespace. Une telle connectivité s'étend jusqu'à la couche 2 (Ethernet). Par conséquent, cette configuration expose potentiellement le système à des vulnérabilités. Plus précisément, elle ouvre la possibilité pour un conteneur malveillant d'exécuter une attaque par spoofing ARP contre d'autres conteneurs situés sur le même nœud. Lors d'une telle attaque, le conteneur malveillant peut tromper pour intercepter ou modifier le trafic réseau destiné à d'autres conteneurs.
Les attaques par spoofing ARP impliquent que l'attaquant envoie des messages ARP falsifiés (Address Resolution Protocol) sur un réseau local. Cela entraîne le lien de l'adresse MAC de l'attaquant avec l'adresse IP d'un ordinateur ou serveur légitime sur le réseau. Après l'exécution réussie d'une telle attaque, l'attaquant peut intercepter, modifier ou même arrêter des données en transit. L'attaque est exécutée sur la couche 2 du modèle OSI, c'est pourquoi la connectivité par défaut dans Kubernetes à cette couche soulève des préoccupations de sécurité.
Dans le scénario, 4 machines vont être créées :
ubuntu-pe : Machine privilégiée pour s'échapper vers le nœud et vérifier les métriques (non nécessaire pour l'attaque)
ubuntu-attack : Conteneur malveillant dans le namespace par défaut
ubuntu-victim : Machine victime dans le namespace kube-system
mysql : Machine victime dans le namespace par défaut
Si vous souhaitez plus de détails sur les sujets de réseau introduits ici, consultez les références.
En général, le réseau pod-à-pod à l'intérieur du nœud est disponible via un pont qui connecte tous les pods. Ce pont s'appelle “cbr0”. (Certains plugins réseau installeront leur propre pont.) Le cbr0 peut également gérer ARP (Address Resolution Protocol) résolution. Lorsqu'un paquet entrant arrive à cbr0, il peut résoudre l'adresse MAC de destination en utilisant ARP.
Ce fait implique que, par défaut, chaque pod s'exécutant dans le même nœud sera capable de communiquer avec tout autre pod dans le même nœud (indépendamment de l'espace de noms) au niveau ethernet (couche 2).
Par conséquent, il est possible d'effectuer des attaques de spoofing ARP entre les pods dans le même nœud.
Dans les environnements kubernetes, vous trouverez généralement 1 (ou plusieurs) services DNS en cours d'exécution généralement dans l'espace de noms kube-system :
Dans les informations précédentes, vous pouvez voir quelque chose d'intéressant, l'IP du service est 10.96.0.10 mais l'IP du pod exécutant le service est 172.17.0.2.
Si vous vérifiez l'adresse DNS à l'intérieur de n'importe quel pod, vous trouverez quelque chose comme ceci :
Cependant, le pod ne sait pas comment accéder à cette adresse car la plage de pods dans ce cas est 172.17.0.10/26.
Par conséquent, le pod enverra les requêtes DNS à l'adresse 10.96.0.10 qui sera traduit par le cbr0 en 172.17.0.2.
Cela signifie qu'une requête DNS d'un pod va toujours passer par le pont pour traduire l'IP du service en l'IP de l'endpoint, même si le serveur DNS est dans le même sous-réseau que le pod.
Sachant cela, et sachant que les attaques ARP sont possibles, un pod dans un nœud sera capable de intercepter le trafic entre chaque pod dans le sous-réseau et le pont et modifier les réponses DNS du serveur DNS (DNS Spoofing).
De plus, si le serveur DNS est dans le même nœud que l'attaquant, l'attaquant peut intercepter toutes les requêtes DNS de n'importe quel pod dans le cluster (entre le serveur DNS et le pont) et modifier les réponses.
Notre objectif est de voler au moins la communication de l'ubuntu-victime au mysql.
Comme déjà mentionné, si vous compromettez un pod dans le même nœud que le pod serveur DNS, vous pouvez MitM avec ARPSpoofing le bridge et le pod DNS et modifier toutes les réponses DNS.
Vous avez un très bon outil et tutoriel pour tester cela sur https://github.com/danielsagi/kube-dnsspoof/
Dans notre scénario, téléchargez l'outil dans le pod attaquant et créez un **fichier nommé hosts ** avec les domaines que vous souhaitez spoof comme :
Effectuez l'attaque sur la machine ubuntu-victim :
Si vous essayez de créer votre propre script de spoofing DNS, si vous modifiez simplement la réponse DNS cela ne fonctionnera pas, car la réponse aura une src IP l'adresse IP du pod malveillant et ne sera pas acceptée. Vous devez générer un nouveau paquet DNS avec la src IP du DNS où la victime envoie la requête DNS (qui est quelque chose comme 172.16.0.2, pas 10.96.0.10, c'est l'IP du service DNS K8s et non l'IP du serveur DNS, plus d'informations à ce sujet dans l'introduction).
L'outil Mizu est un visualiseur de trafic API simple mais puissant pour Kubernetes vous permettant de voir toute la communication API entre les microservices pour vous aider à déboguer et à résoudre les régressions. Il installera des agents dans les pods sélectionnés et rassemblera leurs informations de trafic pour vous les montrer sur un serveur web. Cependant, vous aurez besoin de permissions K8s élevées pour cela (et ce n'est pas très furtif).
Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE) Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE)
