Deux mois après que Rapid7 ait découvert la faille dans le service Git, le responsable du projet n’a pas encore corrigé le bug.
Une vulnérabilité critique récemment découverte et jusqu’à présent non corrigée dans le service open source Gogs Git exige non seulement une action immédiate de la part des développeurs pour sécuriser leur code, mais elle met également en lumière les problèmes potentiels liés à l’utilisation de plates-formes de code auto-hébergées par de petits responsables.
Le trou est une vulnérabilité critique d’injection d’arguments, découverte par un chercheur de Rapid7, qui permet à tout utilisateur authentifié d’exécuter du code à distance sur un serveur Gogs en créant une pull request avec un nom de branche malveillant lors d’une opération de fusion.
Rapid7 a publié aujourd’hui une analyse de la vulnérabilité, après que le responsable de Gogs n’a pas répondu à une demande de mise à jour du statut ou à une offre de différer la divulgation après avoir signalé la faille pour la première fois il y a plus de deux mois.
« Il s’agit d’une vulnérabilité sérieuse dans les logiciels qui ne sont généralement pas exposés à l’Internet public », a déclaré Ryan Emmons, chercheur en sécurité chez Rapid7, dans un e-mail.
» Gogs est généralement utilisé à titre interne ; le modèle de menace le plus probable est un attaquant qui a déjà accédé à un environnement réseau interne en exploitant la vulnérabilité pour obtenir un accès en lecture/écriture aux référentiels de code source sur le serveur Gogs. Un attaquant pourrait exploiter cet accès pour falsifier silencieusement le code source et exfiltrer des informations sensibles, telles que les hachages de mots de passe des utilisateurs et les logiciels propriétaires. «
Une action défensive rapide est requise
David Shipley, responsable du fournisseur de sensibilisation à la sécurité Beauceron Security, a déclaré que le responsable de Gogs et les développeurs doivent prendre rapidement des mesures défensives, car avec la publication d’une vulnérabilité, « tous les attaquants qui ne le savaient pas vont s’en prendre violemment ».
« L’exploit ne nécessite aucun privilège d’administrateur ni aucune interaction avec d’autres utilisateurs », a déclaré Rapid7 dans son rapport. « Un attaquant opère entièrement au sein de son propre compte. Puisque Gogs est livré avec l’enregistrement ouvert activé par défaut (DISABLE_REGISTRATION = false) et aucune limite sur la création de référentiel (MAX_CREATION_LIMIT = -1), un attaquant non authentifié peut simplement créer un compte et un référentiel sur n’importe quelle instance configurée par défaut. Tout utilisateur enregistré qui crée un dépôt en est automatiquement le propriétaire. À partir de là, l’activation de la fusion de rebase est une simple bascule dans les paramètres, et l’ensemble de la chaîne d’exploitation peut être exploitée sans interaction. de tout autre utilisateur.
De plus, tout utilisateur disposant d’un accès en écriture à un référentiel où le rebase est déjà activé peut l’exploiter directement. Dans les cas où la création d’un référentiel est restreinte, un attaquant n’a toujours besoin que d’un accès en écriture à tout référentiel pour lequel la fusion de rebase est (ou peut avoir) activée.
Si elle est exploitée, la vulnérabilité pourrait non seulement conduire à une compromission du serveur Gogs, mais à partir de là, elle pourrait se transformer en une violation de données entre locataires, un vol d’informations d’identification, un mouvement latéral à travers un réseau informatique et des attaques de la chaîne d’approvisionnement logicielle via le code en cours de développement sur la plate-forme Gogs compromise.
Rapid7 décrit Gogs comme un service Git léger et auto-hébergé écrit en Go qui peut s’exécuter sur n’importe quelle plate-forme prise en charge par la chaîne d’outils Go, notamment Linux, macOS et Windows, ainsi que sur les systèmes basés sur ARM. Selon Rapid7, il s’agit de l’une des alternatives auto-hébergées les plus populaires à GitHub, propriété de Microsoft, et elle est couramment déployée par les entreprises, les universités et les projets open source.
D’autres services Git auto-hébergés pour les développeurs incluent GitLab Community Edition, Gitea, Forgejo (un fork de Gitea) et le Bitbucket Data Center d’Atlassian.
Avantages et inconvénients des Gogs
Dans un blog plus tôt ce mois-ci, Open Source Alternatives, qui se décrit comme un répertoire organisé d’outils auto-hébergés remplaçant les logiciels payants, a noté que les développeurs peuvent choisir d’auto-héberger un serveur Git pour éviter les pannes de GitHub, arguant que « vos référentiels restent en ligne lorsque GitHub tombe en panne, votre facture de minutes d’actions GitHub disparaît et votre code source ne quitte jamais votre propre serveur ».
Emmons a déclaré que Gogs est populaire car il s’agit d’une solution Git légère et autonome. Il est facile à déployer et à exécuter, a-t-il déclaré, contrairement à de nombreux autres serveurs Git qui nécessitent de lourdes dépenses opérationnelles et une gestion informatique. Il s’agit également d’un logiciel auto-hébergé sur site, qui, selon lui, est idéal pour les équipes qui ne stockent pas ou ne peuvent pas, pour une raison ou une autre, stocker le code source dans le cloud.
Le principal avantage, selon Emmons, est que Gogs est une solution attrayante du point de vue de la simplicité opérationnelle. Cela fonctionne bien pour ce qu’il fait, et cela ne demande pas beaucoup d’efforts de gestion pour le faire fonctionner. Mais, a-t-il ajouté, « un inconvénient majeur est ce que nous avons vu avec cette divulgation ; Gogs est un logiciel open source maintenu par des personnes aimables pendant leur temps libre, et les développeurs derrière lui n’ont pas le soutien d’une grande équipe de sécurité des informations d’entreprise. Cela signifie que les problèmes de sécurité peuvent parfois se présenter d’une manière qu’ils ne se présenteraient généralement pas pour un produit d’entreprise bien financé. «
