Quatre failles de sécurité non corrigées, dont trois critiques, ont été révélées dans le Gogs Service Git open source et auto-hébergé qui pourrait permettre à un attaquant authentifié de pénétrer dans des instances sensibles, de voler ou d’effacer le code source et même d’installer des portes dérobées.
Les vulnérabilités, selon les chercheurs de SonarSource Thomas Chauchefoin et Paul Gerste, sont répertoriées ci-dessous :
- CVE-2024-39930 (Score CVSS : 9,9) – Injection d’arguments dans le serveur SSH intégré
- CVE-2024-39931 (Score CVSS : 9,9) – Suppression des fichiers internes
- CVE-2024-39932 (Score CVSS : 9,9) – Injection d’arguments lors de l’aperçu des modifications
- CVE-2024-39933 (Score CVSS : 7,7) – Injection d’arguments lors du marquage des nouvelles versions
L’exploitation réussie des trois premières failles pourrait permettre à un attaquant d’exécuter des commandes arbitraires sur le serveur Gogs, tandis que la quatrième faille permet aux attaquants de lire des fichiers arbitraires tels que le code source et les secrets de configuration.
En d’autres termes, en abusant des problèmes, un acteur de menace pourrait lire le code source de l’instance, modifier n’importe quel code, supprimer tout le code, cibler les hôtes internes accessibles depuis le serveur Gogs et se faire passer pour d’autres utilisateurs et obtenir plus de privilèges.
Cela étant dit, les quatre vulnérabilités nécessitent que l’attaquant soit authentifié. De plus, le déclenchement de la vulnérabilité CVE-2024-39930 nécessite que le serveur SSH intégré soit activé, que la version du binaire env soit utilisée et que l’acteur de la menace soit en possession d’une clé privée SSH valide.
« Si l’instance Gogs a l’enregistrement activé, l’attaquant peut simplement créer un compte et enregistrer sa clé SSH », ont déclaré les chercheurs. dit« Sinon, ils devraient compromettre un autre compte ou voler la clé privée SSH d’un utilisateur. »
Les instances Gogs exécutées sous Windows ne sont pas exploitables, tout comme l’image Docker. Cependant, celles exécutées sous Debian et Ubuntu sont vulnérables en raison du fait que le binaire env prend en charge l’option « –split-string ».
Selon les données disponibles sur Shodan, environ 7 300 instances Gogs sont accessibles au public sur Internet, dont près de 60 % sont situées en Chine, suivies des États-Unis, de l’Allemagne, de la Russie et de Hong Kong.
On ne sait pas encore exactement combien de ces serveurs exposés sont vulnérables aux failles susmentionnées. SonarSource a déclaré ne pas avoir la moindre idée si ces problèmes sont exploités dans la nature.
L’entreprise suisse de cybersécurité a également souligné que les responsables du projet « n’ont pas mis en œuvre de correctifs et ont cessé de communiquer » après avoir accepté son rapport initial le 28 avril 2023.
En l’absence de mise à jour, il est recommandé aux utilisateurs de désactiver le serveur SSH intégré, de désactiver l’enregistrement des utilisateurs pour éviter une exploitation massive et d’envisager de passer à Gitea. SonarSource a également a publié un patch que les utilisateurs peuvent appliquer, mais il a été noté qu’il n’a pas été testé de manière approfondie.
Cette révélation intervient alors que la société de sécurité cloud Aqua a découvert que des informations sensibles telles que les jetons d’accès et les mots de passe, une fois codées en dur, pouvaient rester exposées en permanence même après leur suppression des systèmes de gestion de code source (SCM) basés sur Git.
Surnommés « secrets fantômes », le problème vient du fait qu’ils ne peuvent être découverts par aucune des méthodes d’analyse conventionnelles – dont la plupart recherchent des secrets à l’aide de la commande « git clone » – et que certains secrets ne sont accessibles que via « git clone –mirror » ou des vues en cache des plates-formes SCM, mettant en évidence les angles morts que ces outils d’analyse peuvent manquer.
« Les commits restent accessibles via des « vues de cache » sur le SCM », expliquent les chercheurs en sécurité Yakir Kadkoda et Ilay Goldman dit« Essentiellement, le SCM enregistre le contenu du commit pour toujours. »
« Cela signifie que même si un secret contenant un commit est supprimé des versions clonées et mises en miroir de votre référentiel, il est toujours accessible si quelqu’un connaît le hachage du commit. Il peut récupérer le contenu du commit via l’interface graphique de la plateforme SCM et accéder au secret divulgué. »