Alerte de sécurité : La vulnérabilité critique dans Gogs permet l'exécution de code à distance par git rebase --exec sans correctif officiel ou CVE disponible

Une vulnérabilité critique a été révélée dans Gogs, le service Git auto-organisé open source, qui permet l'exécution de code à distance (ERC) par des utilisateurs authentifiés dans des conditions relativement simples. Selon l'analyse publique de l'entreprise de sécurité qui l'a signalé, l'échec reçoit un score élevé dans le système CVSS et, pour l'instant, n'a pas d'identificateur CVE ni de correctif officiel disponible, laissant de nombreuses installations en danger immédiat.

Le problème profite d'une fonctionnalité Git légitime : la commande git rebase prend en charge l'option --exec, qui exécute une commande shell après application de chaque commit pendant une rebase. Dans Gogs, un attaquant peut insérer ce drapeau dans le nom d'une branche malveillante et, si l'instance est configurée pour permettre le fonctionnement de « Rebase avant fusion », inciter le serveur à exécuter le code arbitraire lors de l'exécution de la rebase. Ce qui est particulièrement inquiétant à propos de ce vecteur est qu'il ne nécessite pas de privilèges d'administrateur ou l'interaction d'autres utilisateurs: dans les installations avec configuration par défaut, tout compte enregistré peut créer un dépôt et sera son propriétaire, activer l'option de rebase sur l'interface et déclencher l'opération à partir de son propre dépôt.

Les implications opérationnelles sont graves. Un attaquant réussi peut obtenir l'exécution sur le serveur Gogs, exfilter des dépôts privés, retourner des identifiants, se déplacer latéralement sur le réseau et modifier le code stocké. Dans les environnements multi-utilisateurs ou multi-locataires, cela entraîne un risque de fuite entre locataires, avec une exposition des projets et des secrets de tiers logés dans la même machine. En outre, la facilité de fonctionnement et l'existence d'un module Metasploit qui automatise toute la chaîne augmentent la probabilité d'attaques réelles et massives contre des instances non protégées.

Tant qu'il n'y a pas de patch officiel, il est nécessaire d'agir d'urgence et d'appliquer des contre-mesures défensives qui réduisent la surface de l'attaque. Les mesures les plus directes et les plus pratiques comprennent la désactivation de l'enregistrement public des utilisateurs pour empêcher les agresseurs de créer de nouveaux comptes (par exemple en configurant DISABLE _ INSCRIPTION = true in app.ini), la restriction ou l'interdiction de la création de dépôts par les utilisateurs normaux (par exemple MAX _ CREATION _ LIMIT = 0), et la désactivation de l'option de rebase comme méthode de fusion jusqu'à ce qu'une correction soit disponible. Il est également prudent de vérifier tous les dépôts avec une base activée et d'examiner qui a écrit et les permissions de fusion.

La détection et la recherche devraient prioriser les signaux spécifiques : examiner les enregistrements du serveur Web et des Gogs à la recherche d'erreurs 500 correspondant à l'activité de création/élimination des dépôts, vérifier s'il y a des branches avec des noms qui incluent des caractères suspects ou des drapeaux intégrés, et rechercher des artefacts dans les dépôts exploités (dans certains cas, la création et la suppression du dépôt par l'attaquant laissent peu de traces à l'exception des entrées HTTP et métadonnées). Il prend le risque de détecter de nouveaux comptes avec l'activité de création de dépôt ou de fusionner avec des opérations de rebase inhabituelles. En cas de suspicion d'engagement, isoler l'instance, dresser un inventaire des accès et des clés, changer les lettres de créance et les clés administratives sensibles, et envisager la rotation des secrets qui ont pu être exposés.

Il est important de prévoir des mesures d'atténuation supplémentaires à moyen terme : appliquer la segmentation du réseau afin que le serveur Gogs n'ait pas directement accès aux systèmes critiques, resserrer les politiques de noms de branches et valider les entrées (si son déploiement le permet), limiter la capacité des utilisateurs à activer des opérations dangereuses et surveiller la publication d'un patch officiel par le projet. Tenir des copies vérifiées des dépôts hors de l'instance vulnérable et établir des procédures de réponse pour restaurer des sauvegardes si la manipulation malveillante est confirmée.

Pour approfondir la fonction Overbase et son option --exec, vous pouvez voir la documentation officielle de Git à https: / / git-scm.com / docs / git@-@ rebase. La page du projet Gogs et son code source sont disponibles à https: / / github.com / gogs / gogs, et quiconque veut revoir les outils d'exploitation publics peut consulter le dépôt de Metasploit à https: / / github.com / rapid7 / métasploit-cadre mais leur présence renforce l'urgence d'appliquer l'atténuation recommandée plutôt que d'essayer de reproduire l'attaque dans les environnements de production.

Bref, traiter cette vulnérabilité en priorité: bloquer l'enregistrement public et la création de dépôts si possible, désactiver la base en tant que méthode de fusion, autorisation d'audit et activité récente, et se préparer à appliquer le correctif officiel dès que possible. L'absence d'un CVE ou d'un arrangement ne réduit pas la gravité technique de la défaillance, et l'exposition des serveurs Gogs sur Internet rend la fenêtre d'exploitation réelle et actuellement active.