Gogs menacés : Injection d'arguments facilitant l'exécution de code à distance dans les instances publiques

Un échec d'injection d'argument dans Gogs- la plate-forme Git auto-organisée écrite sur Go - permet l'exécution à distance de code (ERC) dans des instances accessibles sur Internet sans patch officiel disponible à ce jour. Bien que l'exploitation technique exige que l'attaquant soit un utilisateur enregistré, les paramètres par défaut de Gogs (enregistrement ouvert et illimité dans la création de dépôts) font de ce défaut une menace pratique pour tout organisme public.

En termes techniques, la vulnérabilité profite de la possibilité d'injecter des paramètres dans des appels vers des outils système (dans ce cas, git) à travers des noms contrôlés par l'utilisateur - en particulier, le nom d'une branche utilisée dans une requête de tirage - pour forcer git rebase à recevoir un drapeau malveillant de type --exec. Cela vous permet d'exécuter des commandes arbitraires avec les mêmes privilèges que le processus Gogs lorsqu'un dépôt est fusionné avec l'option "rebase before trading" activée.

La chaîne d'exploitation est courte et automatisée: un attaquant crée un compte (si l'instance permet l'enregistrement ouvert), crée un propre dépôt - automatiquement son propre avec la configuration par défaut - active l'option de rebase dans la configuration repo et envoie ensuite une requête avec une branche dont le nom contient la charge utile. De là, l'opération de fusion déclenche l'exécution de la commande malveillante.

L'impact potentiel est large: de compromettre le serveur Gogs et d'accéder à tous les dépôts hébergés (y compris privés), au dumping des identifiants, jetons et clés SSH, se déplaçant latéralement dans les réseaux internes et modifiant le code source publié. Cette portée fait de toute instance vulnérable une porte d'entrée critique pour les attaquants qui cherchent un accès persistant ou une distribution malveillante de code.

Le nombre de cas exposés est important : les organisations qui surveillent Internet trouvent des milliers de serveurs Gogs accessibles au public. Shadowserver enregistre plus de 2400 instances sur son panel public, avec des concentrations en Asie et en Europe, et les recherches sur les moteurs d'impression comme Shodan montrent également plus de mille PI avec l'impression de Gogs. Pour consulter ces sources, vous pouvez évaluer le risque d'exposition d'une organisation : Serveur d'ombres - Gogs exposés et l'analyse de la recherche originale publiée par Rapid7 fournit des détails plus techniques sur le test de concept et la chaîne d'attaque: Rapid7 - URCE authentifiée par injection d'argument dans Gogs.

La vulnérabilité a été signalée aux responsables de Gogs en mars et, bien que reconnue, il n'y a pas encore de correction officielle pour la route touchée. Les Gogs ont déjà souffert des vulnérabilités des URCE exploitées par le passé et il y a eu des patchs pour les défaillances antérieures, ce qui souligne l'importance de mesures d'atténuation immédiates lorsque le patch n'est pas disponible.

Atténuation immédiate recommandée: désactive le registre ouvert (put DISABLE _ REGISTRATION = true), fixe une limite à la création de dépôts (MAX _ CREATION _ LIMIT à une valeur raisonnable ou 0), désactive l'option "rebase before trading" dans la configuration globale ou dans les dépôts critiques, et limite l'accès administratif et fusionné aux utilisateurs de confiance. En outre, envisagez de placer les instances de Gogs derrière un VPN ou un bastion, limitant l'accès par les pare-feu à des plages IP connues et appliquant une forte authentification et vérification d'identité pour de nouveaux comptes.

Parallèlement aux mesures de configuration, il est essentiel de renforcer le confinement et la détection: surveiller les processus git invoqués par le service web, vérifier les journaux à la recherche de champignons qui incluent des décalages inhabituels, examiner la création massive de dépôts ou comptes récents, analyser les changements dans les dépôts qui ne correspondent pas aux flux de travail normaux et détecter le trafic sortant inhabituel du serveur qui pourrait indiquer une infiltration. Si l'engagement est suspecté, isoler l'instance, recueillir des dispositifs pour l'analyse médico-légale (logs, images sur disque, processus), retirer immédiatement les jetons et les clés affectées et reconstruire des copies propres si nécessaire.

Recommandations pour la stratégie à moyen terme: tenir à jour l'inventaire de tous les Gogs de l'organisation (y compris ceux créés par des équipes en dehors des TI), planifier des analyses régulières de l'exposition du public, mettre en œuvre des politiques qui empêchent les paramètres dangereux par défaut et la migration de valeur vers des plates-formes de maintenance actives ou des services gérés si la capacité de grille et d'audit n'est pas garantie en interne. Envisagez également l'isolement des services de gestion de code dans les conteneurs ou les machines avec des privilèges minimums pour réduire le rayon de souffle en cas de panne.

Enfin, et bien qu'il n'y ait pas de patch pour cette route spécifique aujourd'hui, les administrateurs ne devraient pas attendre: prendre la configuration et les mesures de contrôle susmentionnées réduit considérablement l'exposition et le risque immédiat. Gardez un œil sur les canaux officiels de Gogs et de la communauté de sécurité pour appliquer toute mise à jour de sécurité dès qu'elle est publiée et évaluer l'impact de cette vulnérabilité sur votre chaîne d'approvisionnement logiciel.