Une vulnérabilité critique dans Git, permettant des attaques de type RCE (exécution de code à distance), a récemment été révélée. Elle affecte plusieurs versions de Git ainsi que Microsoft Visual Studio 2017. Cette vulnérabilité permet aux attaquants de manipuler des dépôts Git à l'aide de sous-modules, en exploitant un bug de Git qui autorise l'écriture de fichiers en dehors de l'arborescence de travail du sous-module, dans le répertoire .git/. Ce bug permet l'exécution d'un hook malveillant alors qu'une opération de clonage du dépôt est encore 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 `.git` est généré à la racine de l'arborescence de travail. La structure du répertoire ` .git ` se présente initialement comme suit :
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 en 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 de l’ OPSWAT ont examiné les modifications apportées à la version corrigée pour remédier à la faille CVE-2024-32002, et ils ont constaté que deux fichiers avaient été mis à jour pour corriger cette faille.
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
Analyse du flux de travail des liens symboliques et des sous-modules dans Git
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.
Comme « a » pointe vers le répertoire.git et que le système de fichiers ne fait pas la distinction entre majuscules et minuscules, « A » est interprété comme équivalent à « a ». Git est ainsi induit en erreur et écrit le script du hook « post-checkout » dans le répertoire .git/modules/query/fast/hooks/. Si un script de hook post-checkout est détecté dans le dossier .git/modules/{module_type}/{module_name}/hooks, il sera déclenché lorsque le dépôt principal sera cloné avec l'option --recursive. Par conséquent, des attaquants peuvent compromettre 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 :
- Dans un premier temps, il est recommandé de configurer Git pour qu'il autorise systématiquement le protocole « protocol.file », d'activer « core.symlinks » et de définir « main » comme nom de branche par défaut (afin d'éviter l'affichage d'un 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.
Remédiation
Pour neutraliser cette menace, les utilisateurs peuvent désinstaller Git ou appliquer le dernier correctif de sécurité. Sinon, une solution telle que MetaDefender Endpoint peut alerter rapidement l'utilisateur et afficher toutes les vulnérabilités CVE connues au sein de l'environnement grâce à son interface intuitive. MetaDefender Endpoint permet de détecter et d'atténuer les dernières vulnérabilités CVE en tirant parti de ses capacités, avec plus de 3 millions de points de données et plus de 30 000 vulnérabilités CVE associées, accompagnées d'informations sur leur gravité. En mettant en œuvre l'une ou l'autre de ces contre-mesures, la vulnérabilité CVE sera entièrement maîtrisée, é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é ?
Références
(1) https://nvd.nist.gov/vuln/detail/CVE-2024-32002
(3) https://www.atlassian.com/git/
(4) Lien symbolique - Wikipédia
(5) https://www.vicarius.io/vsociety/posts/exploiting-git-rce-cve-2024-32002
