Quatre failles de sécurité non corrigées, dont trois critiques, ont été révélées dans le service Git open source et auto-hébergé de Gogs, qui pourraient permettre à un attaquant authentifié de violer 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 permettrait aux attaquants de lire des fichiers arbitraires tels que le code source et les secrets de configuration.
En d’autres termes, en abusant de ces problèmes, un acteur malveillant 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, se faire passer pour d’autres utilisateurs et obtenir plus de privilèges.
Cela dit, les quatre vulnérabilités nécessitent que l’attaquant soit authentifié. De plus, le déclenchement de 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 menaçant soit en possession d’une clé privée SSH valide.
“Si l’enregistrement est activé sur l’instance Gogs, l’attaquant peut simplement créer un compte et enregistrer sa clé SSH”, ont indiqué les chercheurs. “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, ceux fonctionnant sur Debian et Ubuntu sont vulnérables 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 par les États-Unis, l’Allemagne, la Russie et Hong Kong.
On ne sait actuellement pas exactement combien de ces serveurs exposés sont vulnérables aux failles susmentionnées. SonarSource a déclaré qu’elle n’avait aucune visibilité quant à savoir si ces problèmes étaient exploités dans la nature.
La société 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 empêcher une exploitation massive et d’envisager de passer à Gitea. SonarSource a également publié un correctif que les utilisateurs peuvent appliquer, mais a noté qu’il n’a pas été testé de manière approfondie.
Cette divulgation 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 de manière permanente 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 ». miroir” ou des vues mises 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”, ont déclaré les chercheurs en sécurité Yakir Kadkoda et Ilay Goldman. “Essentiellement, le SCM enregistre le contenu du commit pour toujours.”
“Cela signifie que même si un secret contenant une validation est supprimé des versions clonées et miroir de votre référentiel, il est toujours accessible si quelqu’un connaît le hachage de la validation. Il peut récupérer le contenu de la validation via l’interface graphique de la plate-forme SCM et accéder au divulgué. secrète.”
