Logo Zéphyrnet

Patch maintenant : la faille Kubernetes RCE permet la prise en charge complète des nœuds Windows

Date :

Un bug de sécurité dans le système de gestion de conteneurs Kubernetes, largement utilisé, permet aux attaquants d'exécuter du code à distance avec les privilèges système sur les points de terminaison Windows, ce qui pourrait conduire à une prise de contrôle complète de tous les nœuds Windows au sein d'un système. Cluster Kubernetes.

Tomer Peled, chercheur en sécurité d'Akamai, a découvert la faille, identifiée comme CVE-2023-5528 et présentant un score CVSS de 7.2. L'exploitation réside dans la manipulation des volumes Kubernetes, une fonctionnalité visant à prendre en charge le partage de données entre les pods d'un cluster, ou à les stocker de manière persistante en dehors du cycle de vie d'un pod, a-t-il expliqué. dans un billet de blog publié le 13 mars.

En tant que vecteur d'attaque, les attaquants auraient besoin pour créer des pods et des volumes persistants sur les nœuds Windows, ce qui leur permettrait d'accéder aux privilèges d'administrateur sur ces nœuds, selon une liste GitHub de la faille.

"Il est très facile d'exploiter cette vulnérabilité car un attaquant n'aurait qu'à modifier un paramètre et à appliquer 3 fichiers YAML pour obtenir du RCE sur les points de terminaison Windows", explique Peled à Dark Reading. Le cadre Kubernetes "utilise les fichiers YAML pour pratiquement tout", a-t-il écrit dans le message.

Clusters Kubernetes ne sont concernés que s'ils utilisent un plugin de stockage dans l'arborescence pour Windows ; Cependant, « il existe de nombreux types de volumes différents que les développeurs peuvent utiliser », créant différents scénarios d'attaque, a observé Peled dans le message.

Les installations par défaut de Kubernetes antérieures à la version 1.28.4 exécutant à la fois des déploiements sur site et Azure Kubernetes Service sont vulnérables. L'équipe Kubernetes a été alertée de la faille et un correctif est disponible pour la correction, ce qui est fortement recommandé.

"Étant donné que le problème réside dans le code source, cette menace restera active et son exploitation augmentera probablement. C'est pourquoi nous vous conseillons fortement de patcher votre cluster même s'il ne possède aucun nœud Windows", a écrit Peled.

Suivre les défauts

Peled a découvert la faille après une enquête sur une autre vulnérabilité partageant la même cause fondamentale : un appel de fonction non sécurisé et un manque de vérification des entrées utilisateur dans Kubernetes. Ce défaut était CVE-2023-3676, une vulnérabilité d'injection de commande qui pourrait être exploitée en appliquant un fichier YAML malveillant sur le cluster. La découverte de cette vulnérabilité a conduit à la découverte de deux autres qui sont également causées par le manque de nettoyage du paramètre subPath dans les fichiers YAML, ce qui crée des pods avec des volumes et ouvre la possibilité d'une injection de code malveillant.

"À la fin de cette recherche, nous avons remarqué un endroit potentiel dans le code qui semblait pouvoir conduire à une autre vulnérabilité d'injection de commandes", qui est finalement devenue CVE-2023-5528, a expliqué Peled.

"Après plusieurs essais, nous avons réussi à obtenir un résultat similaire : exécuter des commandes en tant que service kubelet (privilèges SYSTÈME)", a-t-il écrit.

Exploitation et correctifs

La preuve de concept exécutée par les chercheurs s'est concentrée sur les volumes locaux, l'un des types de volumes au sein de Kubernetes. Lors de la création d'un pod comprenant un volume local, le service kubelet finira par atteindre une fonction avec un appel de ligne cmd à « exec.command », créant un lien symbolique entre l'emplacement du volume sur le nœud et l'emplacement à l'intérieur du pod.

Comme de nombreux terminaux, l'invite de commande (cmd) de Windows permet d'exécuter deux ou plusieurs commandes l'une après l'autre, ainsi que plusieurs commandes dans la même ligne de commande. "Le fait que nous puissions contrôler l'un des paramètres lors de l'exécution de cmd signifie que nous pouvons utiliser l'injection de commandes", a expliqué Peled.

Il existe des conditions préalables pour y parvenir sur des volumes locaux, notamment la nécessité de spécifier ou de créer un persistentVolume, entre autres. Cependant, une fois ce volume créé, « un utilisateur peut demander de l'espace de stockage à l'aide d'un persistantVolumeClaim », a-t-il écrit. "C'est ici que l'injection peut être placée."

Le correctif créé pour la faille supprime la possibilité d'injection en supprimant l'appel cmd et en le remplaçant par une fonction GO native qui effectuera la même opération pour créer le lien symbolique. "Désormais, la bibliothèque GO 'os' effectuera uniquement une opération de lien symbolique, comme prévu initialement", a-t-il expliqué.

Votre système est-il vulnérable ?

Kubernetes est devenu l'un des systèmes open source les plus utilisés pour les conteneurs ; cependant, c'est aussi devenu une cible privilégiée pour les acteurs de la menace en raison de son vaste potentiel pour l’exploitation et l’accès aux données organisationnelles. De plus, la configuration de Kubernetes elle-même crée souvent une installation vulnérable, offrant une large surface d’attaque aux acteurs malveillants.

« Kubernetes est un outil très complexe et robuste », explique Peled. « D'une part, sa robustesse permet aux utilisateurs d'adapter leur expérience aux besoins de leur organisation, mais d'autre part, elle rend très difficile la sécurisation de tous ses aspects, tant du point de vue du développeur que de l'utilisateur.

En effet, la découverte de CVE-2023-5528 et de ses failles associées met en évidence pour les entreprises déployant Kubernetes « à quel point il est crucial de vérifier les YAML de configuration de Kubernetes, car la vérification des entrées fait défaut dans plusieurs zones de code de Kubernetes lui-même et de ses projets annexes », a écrit Peled. .

Suivre les meilleures pratiques telles que le contrôle d'accès basé sur les rôles (RBAC) et s'assurer que les clusters sont à jour « devrait également atténuer une grande partie des menaces connues », explique-t-il à Dark Reading.

Un environnement d'entreprise exécutant Kubernetes n'est vulnérable à l'exploitation de la faille que si une version du système est antérieure à 1.28.4 et que le système exécute des nœuds Windows. Si tel est le cas, Akamai a fourni une commande que les administrateurs peuvent exécuter pour déterminer si le système doit être corrigé. Si tel est le cas, les correctifs doivent être prioritaires.  

"Si votre cluster Kubernetes ne possède aucun nœud Windows, vous n'avez pas besoin de vous précipiter pour corriger cette vulnérabilité spécifique", a noté Peled. "Mais il est important de le patcher quand vous en avez le temps."

Si l'application immédiate de correctifs n'est pas une option, Akamai fournit une règle Open Policy Agent (OPA) pour aider à détecter et bloquer ce type de comportement. OPA est un agent open source qui permet aux utilisateurs de recevoir des données sur le trafic entrant et sortant des nœuds et de prendre des actions basées sur des politiques sur les données reçues.

spot_img

Dernières informations

spot_img