La synchronisation de dépôts git en difficulté : Exploration des failles d'injection de commandes dans Kubernetes
Synthèse
Tomer Peled, chercheur chez Akamai, a découvert un défaut de conception dans le projet d'extension de Kubernetes git-sync qui permet une injection de commande potentielle. Il présentera ces résultats au DEF CON 2024.
Ce défaut de conception peut provoquer l'exfiltration de données de n'importe quel fichier du pod (y compris les jetons du compte de service ) ou l'exécution de commandes avec les privilèges utilisateur git_sync .
Pour exploiter cette faille, il suffit à un attaquant d'appliquer un fichier YAML sur le cluster, ce qui est une opération à faible privilège.
Cette vulnérabilité peut être exploitée sur les installations par défaut de Kubernetes sur toutes les plateformes (y compris Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE) et Linode).
Dans cet article de blog, nous fournissons un fichier YAML de démonstration (PoC), ainsi que des démonstrations qui indiquent l'impact potentiel.
Comme aucune CVE n'a été attribuée à ce défaut de conception, il n'y a pas de correctif pour celui-ci : elle reste exploitable.
L'équipe de Kubernetes nous a encouragés à partager cette recherche pour sensibiliser à ces vecteurs d'attaque.
Introduction
Les vulnérabilités liées à l'injection de commandes ne sont pas étrangères à Kubernetes. Rien qu'en 2023, 7 vulnérabilités de ce type ont été découvertes, dont plusieurs que nous avons détectées. Les problèmes liés à la sécurisation des saisies nous ont incités à examiner de plus près les vecteurs d'attaque auxiliaires : Ce vecteur d'attaque est-il unique au projet principal de Kubernetes ou est-il plus répandu ? Il existe plusieurs projets d'extension associés à Kubernetes dans lesquels des vulnérabilités peuvent se cacher, notamment git-sync.
Le projet git-sync est destiné à connecter un pod et un dépôt git pour synchroniser automatiquement les modifications entre leur site/serveur au lieu d'effectuer des modifications manuellement via une solution CI/CD. Par exemple, les utilisateurs pourraient utiliser cette fonctionnalité pour lier leur pod nginx à un dépôt contenant les fichiers qu'ils veulent exposer par le biais d'un pod nginx.
Dans cet article de blog, nous allons passer en revue les détails du défaut de conception, les problèmes dans le code source Kubernetes qui le permettent, et quelques solutions d'atténuation. Nous aborderons également la réponse de Kubernetes à nos conclusions.
Détails du vecteur d'attaque
En examinant la page d'utilisation de git-sync, nous pouvons voir qu'elle prend en charge de nombreux paramètres de configuration possibles afin qu'un utilisateur puisse personnaliser git-sync en fonction de ses besoins. Cela représente une surface d'attaque potentiellement importante qu'un attaquant pourrait exploiter (Figure 1).
Figure 1 : Certains des paramètres de git-sync
Le cadre Kubernetes utilise des fichiers YAML pour pratiquement tout, de la configuration de l'interface réseau des conteneurs à la gestion des pods et même à la gestion des secrets, de sorte qu'une vulnérabilité dans YAML peut s'avérer tout à fait désastreuse. Dans ce cas, il est possible de créer un pod qui utilise git-sync pour se connecter à un dépôt distant (ou à un attaquant).
La Figure 2 présente un exemple de fichier YAML de configuration qui déploie un pod avec git-sync.
Figure 2 : Fichier YAML de configuration qui déploie un pod avec git-sync
Les deux paramètres qui ressortent le plus comme vecteurs d'attaque potentiels sont GITSYNC_GIT et GITSYNC_PASSWORD.
Selon les documents git-sync officiels, GITSYNC_PASSWORD_FILE est « le fichier à partir duquel le mot de passe ou le jeton d'accès personnel (voir la documentation github) à utiliser pour l'authentification git (voir --username) sera lu. » Cela laisse présager une possibilité d'exfiltration des données de l'« accesstoken » ou d'autres fichiers sur le pod.
GITSYNC_GIT est (encore une fois, d'après la documentation officielle) « la commande git à exécuter (sujette à la recherche dans PATH , principalement pour les tests). La valeur par défaut est "git," ce qui signifie que nous pouvons choisir un binaire qui sera exécuté à la place de git, et l'utiliser pour l'exécution de code sur le cluster.
Chaîne d'attaque proposée
Sur la base de ces informations, nous avons entrepris de prouver nos théories. Nous pensons qu'il existe quelques vecteurs d'attaque exploitables par les attaquants.
Exécution furtive de code
Un attaquant disposant de privilèges faibles (privilèges Create) sur le cluster ou l'espace de noms peut appliquer un fichier YAML malveillant contenant un chemin vers son binaire, provoquant son exécution sous le nom git-sync.
Le fichier binaire doit se trouver à l'intérieur du pod, ce qui peut être réalisé de différentes manières, notamment via des sondes Kubernetes, des volumes Kubernetesou des LOLBins fournis avec le pod git-sync (Figure 3).
Figure 3 : Exemple de YAML utilisant des LOLBins
Après avoir appliqué le fichier YAML, aux yeux du personnel de l'équipe bleue, git-sync est celui qui communique avec un serveur distant, et il est donc raisonnable de supposer qu'on lui fait confiance pour communiquer avec l'extérieur. Cela permet aux attaquants de contourner les mesures de sécurité en complément de l'exécution de la commande.
La Figure 4 est une démonstration de faisabilité (PoC) d'une attaque potentielle démarrant un cryptomineur XMrig sous l'utilisateur git-sync.
Figure 4 : Démonstration de faisabilité (PoC) du cryptomineur potentiel XMRig
Désormais, lorsqu'un administrateur réseau effectue un audit des pods existants et de leur communication en dehors du réseau de l'entreprise, il verra très probablement l'utilisateur git-sync communiquer avec un serveur extérieur.
Exfiltration de données
Un attaquant disposant de privilèges d'édition peut modifier un déploiement git-sync pour modifier ou ajouter le paramètre GITSYNC_PASSWORD_FILE et le faire pointer vers n'importe quel fichier du pod. Ainsi, git-sync enverra le fichier comme moyen d'authentification lors de sa prochaine connexion au dépôt git.
Si l'attaquant modifie également l'emplacement du dépôt git, et met en place un pseudo serveur de dépôt, le prochain déploiement du processus git-sync à l'intérieur du pod enverra le fichier dans le paramètre GITSYNC_PASSWORD_FILE du pod à leur machine. Il n'y a pas de restrictions sur les chemins d'accès aux fichiers ou les permissions requises pour le paramètre GITSYNC_PASSWORD_FILE.
Il n'est donc pas difficile d'imaginer une exfiltration à haut risque. Et cela, à juste titre : Les attaquants peuvent utiliser cette technique pour récupérer le jeton d'accès du pod, ce qui leur permettrait d'interagir avec le cluster sous l'apparence du pod git-sync (Figure 5).
Figure 5 : Démonstration de faisabilité (PoC) d'une attaque GITSYNC_PASSWORD_FILE potentielle
Divulgation et réponse de Kubernetes
Nous avons initialement communiqué nos conclusions à l'équipe Kubernetes en décembre 2023. Après quelques discussions avec l'équipe Kubernetes, il a été décidé que la modification de YAML est considérée comme une opération à privilège élevé, de sorte que nos conclusions ne franchissent pas un seuil de sécurité. De notre point de vue, cependant, bien que les opérations de modification sur un pod soient considérées comme faisant l'objet de privilèges, un mouvement latéral reste possible avec cette technique. La perte d'intégrité était également un sujet de préoccupation : L'attaquant serait capable de dérober des informations comme s'il était un utilisateur légitime de git-sync.
À propos de GITSYNC_GIT, l'équipe Kubernetes a reconnu que les privilèges requis pour ce type d'action sont faibles, mais n'a pas pensé que les opérations à faible privilège conduiraient à un comportement nuisible. Cependant, nous pensons que le défaut de conception que nous avons décrit permettrait aux attaquants d'exécuter des commandes tout en usurpant leur identité, et que le seul obstacle à un comportement nuisible est un faible niveau de privilèges sur le cluster. Ce flux d'attaque est particulièrement dangereux dans les organisations qui ont préautorisé la communication git-sync dans leur cluster.
Dans les deux cas, Kubernetes nous a encouragés à partager cette recherche très utile en ligne, car elle « permet de rappeler aux administrateurs de réfléchir attentivement à la surface qu'ils exposent aux utilisateurs ».
Atténuations
Les techniques d'attaque décrites dans cet article de blog n'étant pas considérées comme des vulnérabilités par l'équipe Kubernetes, elles ne feront pas l'objet d'un correctif. Par conséquent, pour réduire la surface d'attaque que ces « fonctionnalités » permettent, nous recommandons quelques mesures d'atténuation potentielles.
Tout d'abord, augmentez la surveillance des communications qui quittent l'organisation, en particulier à partir des pods Kubernetes. Portez une attention particulière aux pods git-sync si cette granularité est possible.
Deuxièmement, nous recommandons d'auditer les pods git-sync pour connaître la commande qu'ils exécutent. Cette vérification peut être effectuée à l'aide de la commande suivante :
kubectl describe pod <git-sync-pod>
Par exemple, en exécutant cette commande sur le cryptomineur illustré à la Figure 4, nous pouvons voir l'argument –git qui aurait soulevé un signal d'alerte en cas de détection, en particulier lorsque la valeur de l'argument n'est pas « git » (Figure 6).
Figure 6 : Exécution de cette commande d'audit sur le cryptomineur de la Figure 4
Cet audit est une bonne pratique de sécurité générale, c'est pourquoi nous recommandons d'exécuter cette commande sur tous les pods, et pas seulement sur les pods git-sync.
Nous avons également rédigé une règle OPA qui peut détecter l'un des vecteurs d'attaque que nous proposons, dans lequel les attaques remplacent le binaire git par une charge utile malveillante :
package kubernetes.admission
deny[msg] {
input.request.kind.kind == "<Deployment/Pod>"
path := input.request.object.spec.env.name
contains(path, "GITSYNC_GIT")
msg := sprintf("Gitsync binary parameter detected, possible payload alteration, verify new binary ", [path])
}
Conclusion
Dans cet article de blog, nous avons montré deux vecteurs d'attaque dans le projet d'extension git-sync Kubernetes. Ces deux vecteurs sont dus à un manque de sécurisation des saisies utilisateur, ce qui met en évidence la nécessité d'une défense robuste dans ce domaine. Ces problèmes de sécurisation Kubernetes ne sont pas uniques à git-sync, comme nous l'avons vu précédemment .
Les membres de l'équipe bleue doivent être à l'affût de tout comportement inhabituel provenant de l'utilisateur gitsync au sein de leur organisation. Nous estimons que ces vecteurs d'attaque peuvent avoir un impact très important sur les entreprises ; il est donc important pour nous de sensibiliser et d'aider les administrateurs de sécurité à appréhender ce danger potentiel.
Le groupe Security Intelligence d'Akamai continuera à étudier ces menaces et à les signaler auprès de nos clients et de l'ensemble de la communauté de la sécurité. Pour connaître les dernières informations en temps réel nos travaux, suivez-nous sur X (anciennement Twitter).
Malgré notre désaccord sur le résultat, nous tenons à remercier l'équipe Kubernetes pour sa réponse et son argumentation.