La société de sécurité applicative Aikido a révélé que les adresses e-mail de la fonctionnalité Email work item to this project de GitLab apparaissent parfois dans des fichiers README, des guides de contribution et des pages d’assistance publiques. Ces adresses contiennent un jeton à longue durée associé au compte du développeur, ce qui fait de leur publication davantage une exposition d’identifiants qu’une simple publication d’un moyen de recevoir des rapports de bogues.
La fonctionnalité permet à toute personne envoyant un message à l’adresse de créer un ticket ou une tâche dans un projet GitLab. Cependant, les tests menés par Aikido ont montré que l’attaquant peut modifier le suffixe -issue de l’adresse en -merge-request, afin que GitLab accepte le message et crée une demande de fusion dans le projet.
Que peut-il se produire concrètement ?
L’étendue de l’impact dépend des autorisations du compte associé au jeton. Les conséquences potentielles peuvent inclure l’introduction de modifications dans le code, l’exécution de tâches CI/CD, l’accès à des dépôts privés ou l’extraction de secrets stockés dans des variables CI/CD, ainsi que la consultation de tickets confidentiels. Dans les projets open source, les adresses exposées peuvent devenir un risque pour la chaîne d’approvisionnement si elles sont utilisées pour introduire des modifications dans des projets dont dépendent un grand nombre d’utilisateurs.
Les chercheurs d’Aikido ont trouvé, au cours d’un seul après-midi, environ 12 adresses actives publiées dans des documents publics, et ont indiqué que certaines appartenaient à des projets open source largement utilisés. L’attaquant n’a pas besoin d’usurper l’adresse e-mail du propriétaire du jeton : GitLab traite le message comme s’il provenait du propriétaire du jeton, et les tests ont également montré un contournement des restrictions d’adresses IP.
Limites de l’exploitation et responsabilité des administrateurs
L’exposition de l’adresse ne signifie pas que les autorisations du compte sont contournées : les autorisations de l’utilisateur restent une restriction essentielle. L’attaquant doit également connaître le chemin et l’identifiant du projet. Ces informations sont disponibles dans les projets publics, tandis que le ciblage d’un projet privé nécessite une fuite du chemin, même s’il est possible de deviner l’identifiant par force brute.
La documentation de GitLab elle-même met en garde contre le partage de ces adresses et les décrit comme privées et générées pour l’utilisateur concerné, en précisant que toute personne les connaissant peut créer des tickets ou des demandes de fusion comme si elle en était le propriétaire. La plateforme recommande de réinitialiser le jeton dès qu’une fuite est suspectée.
Qu’est-ce que cela signifie pour les projets ?
Aikido a signalé le problème à GitLab via HackerOne en mai, mais le rapport a été clôturé au motif que le comportement était intentionnel. Après une seconde notification en juin, GitLab a mis à jour son interface afin de mentionner la possibilité de créer des demandes de fusion, supprimé des formulations inexactes concernant l’accès aux données du jeton et documenté que la réception des messages par e-mail contourne les restrictions d’adresses IP.
La mesure pratique la plus importante incombe aux administrateurs des projets : supprimer ces adresses des documents publics et réinitialiser les jetons des projets qui ont déjà été publiés. Les questions ouvertes concernent la mesure dans laquelle GitLab s’appuiera à l’avenir sur la correspondance entre l’adresse de l’expéditeur et l’adresse e-mail du propriétaire du jeton comme couche de défense supplémentaire, un mécanisme que, selon Aikido, la plateforme étudie actuellement.