E-mails GitLab exposés : des attaquants poussent du code

Certains développeurs publient des adresses e-mail privées GitLab dans leurs README, leurs guides de contribution et leurs pages d'assistance pour recueillir des signalements de bugs. Selon les chercheurs de la société de sécurité applicative Aikido, ces adresses contiennent un identifiant que des attaquants peuvent utiliser pour agir sur GitLab à la place du développeur à qui elles appartiennent.

Ces adresses proviennent d'une fonctionnalité intégrée à GitLab appelée « Email work item to this project ». GitLab les génère automatiquement. Lorsque quelqu'un envoie un message à l'une d'elles, GitLab transforme l'e-mail en ticket ou en tâche dans le projet.

Le problème, c'est que chaque adresse contient un jeton à longue durée de vie lié au compte du développeur. Cette chaîne sert d'identifiant pour créer des éléments de travail par e-mail.

Un jeton caché dans l'adresse

Chaque adresse privée de ce type comporte une chaîne « glimt- » qui donne accès au projet. Cette même chaîne est utilisée dans toutes les adresses similaires générées pour ce projet.

Aikido a constaté que l'adresse ne se limite pas aux tickets. « Remplacez le suffixe -issue de l'adresse e-mail par -merge-request, et GitLab ouvrira une demande de fusion », expliquent les chercheurs.

GitLab ne vérifie pas non plus qui a envoyé le message. « En principe, vérifier que l'adresse de l'expéditeur correspond à l'e-mail du propriétaire du jeton ajouterait une couche de défense, mais GitLab ne le fait pas (même si l'entreprise l'envisage désormais) », précisent les chercheurs. « N'importe quelle boîte mail sur Internet peut écrire à cette adresse, et GitLab traite le message comme s'il venait du propriétaire du jeton. »

Les tests d'Aikido ont également montré que la technique contourne les restrictions par adresse IP.

Ce qu'un attaquant peut faire dépend des droits du compte associé au jeton. Selon Aikido, un compte compromis pourrait servir à :

• pousser du code sur des branches protégées de dépôts privés
• voler du code source
• récupérer des secrets stockés dans les variables CI/CD
• lire des tickets confidentiels

Les droits du compte ne peuvent pas être contournés. Un attaquant a aussi besoin du chemin et de l'identifiant du projet visé. Pour les projets publics, les deux sont faciles à trouver. Pour les projets privés, l'identifiant peut être obtenu par force brute, mais le chemin devrait avoir fuité.

Des adresses publiées délibérément

En un seul après-midi, Aikido a trouvé une douzaine d'adresses de réception GitLab actives dans de la documentation publique. Selon les chercheurs, les mainteneurs les avaient ajoutées volontairement, pour que les utilisateurs puissent envoyer des signalements de bugs.

Plusieurs de ces adresses appartenaient à des projets open source populaires. « Quelques-unes appartenaient à des projets open source très populaires », notent les chercheurs. Pour les projets comptant beaucoup d'utilisateurs, cela crée un risque pour la chaîne d'approvisionnement.

La documentation de GitLab elle-même indique que ces adresses sont privées et « générées rien que pour vous ». Elle avertit : « Gardez-la pour vous, car toute personne qui la connaît peut créer des tickets ou des demandes de fusion comme si elle était vous. Si vous pensez que cette adresse e-mail privée a fuité, réinitialisez immédiatement le jeton. »

La réponse de GitLab

Aikido a signalé le problème à GitLab en mai via HackerOne, une plateforme de bug bounty. GitLab a clos le signalement en le qualifiant de « comportement voulu ».

Aikido a envoyé une deuxième notification en juin. GitLab a ensuite apporté plusieurs modifications :

• son interface mentionne désormais les demandes de fusion
• l'entreprise a supprimé des affirmations erronées sur les données auxquelles le jeton peut accéder
• sa documentation précise désormais que les e-mails entrants contournent les restrictions par adresse IP

Les chercheurs conseillent aux mainteneurs de ne plus publier ces adresses dans leur documentation publique. Ceux qui l'ont déjà fait devraient réinitialiser les jetons des projets concernés.

Notre analyse

Cette affaire relève moins d'un bug logiciel classique que d'une fonctionnalité pratique dont les risques pouvaient facilement passer inaperçus. GitLab a bien demandé aux utilisateurs de garder ces adresses privées, mais des mainteneurs les ont tout de même publiées, visiblement en les considérant comme de simples boîtes de réception pour l'assistance. Le fait que la même adresse permette aussi d'ouvrir des demandes de fusion n'a été clairement documenté qu'après la deuxième intervention d'Aikido.

Cela s'inscrit dans une tendance plus large, où la documentation publique destinée aux développeurs devient un point d'entrée pour les attaques. Les secrets stockés dans les pipelines CI/CD ont de la valeur pour les attaquants, comme l'ont montré des cas précédents tels que la faille TeamCity exploitée par des gangs de rançongiciels. Un jeton qui donne ce type d'accès via une adresse e-mail mérite la même vigilance qu'une clé d'API.

Pour les lecteurs qui maintiennent des projets sur GitLab, la mesure concrète consiste à passer en revue les README, les guides de contribution et les pages d'assistance à la recherche d'adresses de réception, puis à réinitialiser tout jeton exposé. Il faudra suivre si GitLab va jusqu'au bout et vérifie l'adresse de l'expéditeur. Selon Aikido, l'entreprise l'envisage, ce qui comblerait la faille la plus évidente. D'ici là, le plus prudent est de partir du principe que toute adresse de ce type publiée a déjà été découverte.