Une vulnérabilité critique dans Git permettant des attaques RCE (exécution de code à distance) a été récemment divulguée, impactant plusieurs versions de Git et Microsoft Visual Studio 2017. La vulnérabilité permet aux attaquants de manipuler les référentiels Git à l'aide de submodules, en exploitant un bug dans Git qui permet d'écrire des fichiers en dehors de l'arbre de travail du submodule et dans le répertoire .git/. Ce bogue permet l'exécution d'un hook malveillant alors qu'une opération de clonage de référentiel est toujours en cours [1].
La vulnérabilité CVE-2024-32002 affecte Microsoft Visual Studio 2017 version 15.9 et les versions de Git antérieures à 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2 et 2.39.4. Elle peut être exploitée dans les environnements où la prise en charge des liens symboliques est activée sur les systèmes d'exploitation insensibles à la casse.
Comprendre Git
Git est un système de contrôle de version distribué, libre et gratuit, conçu pour aider les développeurs de logiciels à gérer leurs bases de code rapidement et efficacement. Il améliore la collaboration entre les membres de l'équipe de développement en organisant et en suivant les modifications apportées aux fichiers et aux répertoires d'une manière standardisée et structurée.
Git est largement utilisé dans le développement de logiciels. Des plateformes telles que GitHub, GitLab et Bitbucket sont construites sur la base de Git pour améliorer la collaboration entre les développeurs grâce à ses puissantes fonctionnalités :
- Enregistrement des modifications traçables apportées aux fichiers de code, connues sous le nom de " commits".
- Revenir, si nécessaire, sur les versions antérieures des codes édités.
- Combiner efficacement les modifications provenant de différentes branches ou contributeurs.
- Garder une trace de l'historique des personnes qui ont apporté des modifications et de leurs dates.
Crochets Git
Lorsqu'un dépôt Git est créé ou cloné à l'aide des commandes git init ou git clone, un répertoire .gitest généré à la racine de l'arbre de travail. La structure du répertoire .git ressemble initialement à ceci :
Les hooks Git sont des scripts exécutables, situés soit dans le répertoire .git/hooks, soit dans le répertoire .git/modules/module_type/module_name/hooks. Les hooks sont automatiquement déclenchés lorsque des événements spécifiques se produisent dans un dépôt Git.
Lorsqu'un fichier du répertoire hooks n'a pas de suffixe .sample, les commandes de ce fichier seront exécutées avant ou après une action Git particulière incluse dans le nom du fichier, telle que pre-commit, post-commit, et post-checkout.
Sous-modules Git
Un sous-module Git est un enregistrement dans un dépôt Git qui fait référence à un commit spécifique dans un dépôt externe. Lorsqu'un sous-module est ajouté à un dépôt, un nouveau fichier dans le répertoire .gitmodules est créé avec les métadonnées de correspondance entre l'URL du sous-module et son répertoire local. Lorsqu'un dépôt contient plusieurs sous-modules, le fichier .gitmodules contient une entrée pour chacun d'entre eux. [3]
Liens symboliques (Symlinks)
Un lien symbolique, également appelé lien symbolique ou lien logiciel, est un fichier qui pointe vers un autre fichier ou répertoire (appelé "cible") en spécifiant son chemin d'accès. Si un lien symbolique est supprimé, sa cible n'est pas affectée. [4]
Dans Git, un lien symbolique est créé sous la forme d'un fichier avec des métadonnées qui lui permettent de fonctionner comme une référence ou un raccourci vers un autre fichier. Les liens symboliques peuvent être utilisés pour créer plusieurs références à un fichier sans en reproduire le contenu.
Analyse des vulnérabilités de sécurité de GIT
Analyse des correctifs
Pour mieux comprendre les failles de sécurité, les spécialistes de la sécurité procèdent souvent à une analyse des correctifs. Il s'agit d'une technique qui permet d'identifier les fonctions vulnérables et les vecteurs d'attaque potentiels. Les membres d'OPSWAT ont examiné les modifications apportées à la version corrigée pour remédier à la vulnérabilité CVE-2024-32002, et ils ont constaté que deux fichiers avaient été mis à jour pour remédier à cette vulnérabilité.
L'un des fichiers mis à jour est le fichier submodule--helper.c, qui inclut le code qui gère le clonage des submodules Git. Le nouveau commit dans la version corrigée incluait les deux suivants :
- Ajout de la fonction dir_contains_only_dotgit pour s'assurer que le répertoire des sous-modules ne contient aucun fichier ou répertoire .git.
- Des modifications ont été apportées à la fonction clone_submodule() afin d'inclure une condition permettant de vérifier si le répertoire du sous-module existe et s'il est vide. Si le répertoire n'est pas vide, le processus de clonage est interrompu.
La deuxième mise à jour du nouveau commit se trouve dans le fichier t/t7406-submodule-update.sh, ajoutant un script de test pour vérifier que la vulnérabilité de sécurité a été résolue.
De l'analyse à l'exploitation
En plus des informations recueillies lors de l'analyse des correctifs et de la description de la vulnérabilité CVE-2024-32002, les boursiers OPSWAT ont travaillé sur l'étude du flux de travail des liens symboliques et des sous-modules dans Git. Ils ont décomposé la séquence d'événements qui se produit lorsqu'un utilisateur clone un dépôt :
- Git commence par télécharger les fichiers et les répertoires du dépôt principal.
- Il utilise les définitions spécifiées dans les fichiers de liens symboliques pour recréer les liens symboliques correspondants dans le système de fichiers local.
- Si le lien symbolique pointe vers un fichier existant, il sera fonctionnel ; sinon, il restera inopérant jusqu'à ce que la cible soit restaurée.
- Si le dépôt est cloné avec l'option --recursive, Git clone les sous-modules (dépôts externes) et les place dans les répertoires indiqués dans le fichier .gitmodules.
- Si un lien symbolique fait partie du chemin du sous-module (par exemple, util/module/test, où util est un lien symbolique pointant vers un autre répertoire, tel que symlink_folder), Git stockera le contenu du sous-module dans le répertoire référencé par le lien symbolique (par exemple, symlink_folder/module/test), tout en autorisant l'accès par le chemin original du lien symbolique.
Comprendre la vulnérabilité de sécurité CVE-2024-32002 de Git
Création de dépôts malveillants
Les membres d'OPSWAT ont examiné plus en détail la création de dépôts malveillants sur la base des mises à jour effectuées pour le fichiert/t7406-submodule-update.sh et ont décomposé ce processus en plusieurs étapes :
- Création d'un référentiel contenant un crochet de post-contrôle
- Création d'un autre référentiel comprenant un sous-module, situé dans le chemin A/modules/x. Le nouveau sous-module fait référence au référentiel créé précédemment.
- Création d'un lien symbolique nommé a, pointant vers le dossier .git dans l'index Git.
Comprendre la faille de sécurité
Lorsqu'un utilisateur clone un dépôt malveillant, créé à l'étape précédente, à l'aide de l'option --recursive, le script malveillant du crochet post-checkout est déclenché, ce qui permet à l'attaquant de compromettre l'appareil de l'utilisateur.
Cette exécution de code à distance se produit parce que le dépôt principal détecte un lien symbolique nommé a qui pointe vers le répertoire .git lorsqu'il est cloné. Avec le mode récursif activé, les sous-modules sont également tirés dans le dépôt cloné. Ce dépôt contient un dossier hooks, qui contient le script de hook post-contrôle, et son répertoire local est dans A/modules/x.
Puisque a pointe vers le répertoire.git et que le système de fichiers n'est pas sensible à la casse, A est interprété comme équivalent à a. Git est induit en erreur en écrivant le script de crochet post-contrôle dans le répertoire .git/modules/query/fast/hooks/. Si un script de crochet de post-contrôle est trouvé dans le répertoire . git/modules/{module_type}/{nom_du_module}/hooks, il sera déclenché lorsque le référentiel principal est cloné avec l'option --recursive. En conséquence, les attaquants peuvent compromettre avec succès l'appareil de l'utilisateur en exécutant du code à distance.
Simulation de l'exploitation de la vulnérabilité de Git
Sur la base des résultats précédents, OPSWAT Fellows a créé un dépôt principal et un crochet pour simuler la création d'un dépôt malveillant :
- Initialement, il est recommandé de configurer Git pour qu'il autorise toujours le fichier protocol.file, qu'il active les liens symboliques core.symlinks et qu'il fixe le nom de la branche par défaut à main (pour éviter le message d'avertissement).
- Un script malveillant de type " postcheckout hook" est ajouté au répertoire "hooks". Pour s'assurer que le script de post-contrôle peut être exécuté sur l'appareil de l'utilisateur, le script bash qui crée ce crochet inclut la commande chmod +x fast/hooks/post-checkout.
- Un lien symbolique est créé dans le dépôt principal, pointant vers le répertoire .git.
Le dossier /hooks avec un crochet de post-contrôle
Remédiation
Pour neutraliser la menace, les utilisateurs peuvent désinstaller Git ou appliquer le dernier correctif de sécurité. Sinon, une solution comme MetaDefender Endpoint peut avertir rapidement l'utilisateur et afficher toutes les CVE connues dans l'environnement grâce à son interface intuitive. MetaDefender Endpoint peut détecter et atténuer les dernières CVE en tirant parti de ses capacités avec plus de 3 millions de points de données et plus de 30 000 CVE associées avec des informations sur la gravité. En mettant en œuvre l'une ou l'autre des contre-mesures, le CVE sera entièrement contenu, éliminant ainsi le risque d'une cyberattaque dévastatrice.
Êtes-vous prêt à mettre MetaDefender Endpoint en première ligne de votre stratégie de cybersécurité ?
