Kubernetes Network Attacks
Introduction
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 l'espace de noms. Cette connectivité s'étend jusqu'au niveau 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 de détournement ARP contre d'autres conteneurs situés sur le même nœud. Pendant une telle attaque, le conteneur malveillant peut intercepter ou modifier de manière trompeuse le trafic réseau destiné à d'autres conteneurs.
Les attaques de détournement ARP impliquent que l'attaquant envoie de faux messages ARP (protocole de résolution d'adresse) sur un réseau local. Cela entraîne la liaison 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, voire arrêter des données en transit. L'attaque est exécutée au niveau 2 du modèle OSI, c'est pourquoi la connectivité par défaut dans Kubernetes à ce niveau soulève des préoccupations en matière 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 l'espace de noms par défaut
ubuntu-victim : Machine victime dans l'espace de noms kube-system
mysql : Machine victime dans l'espace de noms par défaut
Réseau de base de Kubernetes
Si vous souhaitez obtenir plus de détails sur les sujets de réseau introduits ici, consultez les références.
ARP
En règle générale, le réseau de pod à pod à l'intérieur du nœud est disponible via un pont qui connecte tous les pods. Ce pont est appelé "cbr0". (Certains plugins réseau installeront leur propre pont.) Le cbr0 peut également gérer la résolution ARP (protocole de résolution d'adresses). 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 pourra 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.
DNS
Dans les environnements Kubernetes, vous trouverez généralement 1 (ou plus) 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 traduite 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 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 pourra intercepter le trafic entre chaque pod dans le sous-réseau et le pont et modifier les réponses DNS du serveur DNS (Spoofing DNS).
De plus, si le serveur DNS est dans le même nœud que l'attaquant, l'attaquant pourra 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.
ARP Spoofing dans les pods dans le même nœud
Notre objectif est de voler au moins la communication de ubuntu-victim vers mysql.
Scapy
ARPSpoof
DNS Spoofing
Comme cela a déjà été mentionné, si vous compromettez un pod dans le même nœud du pod serveur DNS, vous pouvez faire une attaque de l'homme du milieu (MitM) avec ARPSpoofing sur le pont et le pod DNS et modifier toutes les réponses DNS.
Vous avez un outil et un tutoriel très utiles pour tester cela sur https://github.com/danielsagi/kube-dnsspoof/
Dans notre scénario, téléchargez l'outil dans le pod de l'attaquant et créez un fichier nommé hosts
avec les domaines que vous souhaitez faire du spoofing comme suit :
Effectuer l'attaque sur la machine ubuntu-victim :
Si vous essayez de créer votre propre script de détournement DNS, si vous modifiez simplement la réponse DNS, cela ne fonctionnera pas, car la réponse aura une IP source l'adresse IP du pod malveillant et ne sera pas acceptée. Vous devez générer un nouveau paquet DNS avec l'IP source du DNS où la victime envoie la requête DNS (qui ressemble à 172.16.0.2, pas 10.96.0.10, c'est l'IP du service DNS de K8s et non l'IP du serveur DNS, plus d'informations à ce sujet dans l'introduction).
Capture du trafic
L'outil Mizu est un visualiseur de trafic API simple mais puissant pour Kubernetes vous permettant de visualiser toutes les communications 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, collectera leurs informations de trafic et vous les montrera dans un serveur web. Cependant, vous aurez besoin de permissions élevées pour K8s pour cela (et ce n'est pas très discret).
Références
Last updated