GitLab : la seule sécurité du courrier électronique est l’obscurité

Lucas Morel

if ( !emtpy($headline_subheadline ) ) : ?>

Un jeton de longue durée intégré à l’adresse e-mail génératrice de problèmes de GitLab signifie que toute personne possédant l’adresse, et pas seulement le propriétaire du projet, peut envoyer du code et déclencher des tâches CI/CD sous réserve des autorisations existantes du compte.

endif; ?>

Il s’agissait de simplifier la vie : une adresse e-mail secrète à laquelle les développeurs peuvent envoyer un message et créer un problème dans leur projet GitLab. Mais de mauvais paramètres de sécurité par défaut et un jeton de longue durée intégré à l’adresse signifient que toute personne connaissant l’adresse peut potentiellement modifier les référentiels protégés. Si les propriétaires de projets publient ou divulguent ces adresses, comme certains l’ont fait, ils deviennent alors vulnérables.

L’adresse e-mail relative au projet fournie par GitLab sous la forme d’un bouton indiquant « Envoyer un élément de travail à ce projet » peut débloquer l’accès à l’échelle du compte sur des projets privés et publics, en plus de sa fonction prévue, a découvert Aikido Security. La fonctionnalité est activée pour chaque compte sur GitLab.com et ne peut pas être désactivée ; il peut également être activé pour les instances auto-hébergées de GitLab.

« Toute personne détenant cette adresse peut pousser du code et exécuter des tâches CI/CD dans chaque projet auquel votre compte peut accéder », a déclaré la société de sécurité des applications dans un article de blog décrivant ses conclusions.

Restrictions IP ignorées

GitLab permet aux utilisateurs de définir des restrictions sur les adresses IP pouvant accéder à leur compte, mais ces restrictions ne s’appliquent pas aux e-mails. « GitLab a bloqué notre navigateur et rejeté git clone. Il a accepté l’e-mail et le commit a atterri sur main », a déclaré Aikido.

Le comportement est intentionnel et non une vulnérabilité, selon GitLab. L’Aikido remet en question cette évaluation, arguant que « GitLab a créé un identifiant qui atteint chaque projet du compte et contourne les restrictions IP, puis l’a présenté comme une adresse e-mail ».

Les adresses vulnérables ont la forme incoming+project-id-glimt-XXXXXXXXXXXXXX-issue@incoming.gitlab.com

Le coupable est le jeton d’accès personnel (PAT) préfixé par « Glimt- » intégré dans l’adresse e-mail que GitLab souhaite garder privée. « Gardez ce jeton secret. Quiconque le possède peut créer des problèmes comme s’il était vous », prévient GitLab via une description de l’interface utilisateur du jeton.

Aikido a déclaré que la description ajoute que le jeton « ne peut pas être utilisé pour accéder à d’autres données », une affirmation qu’elle trouve fausse. Cinq projets différents appartenant au même compte fournissent cinq adresses e-mail privées différentes, mais le « jeton intégré dans chacun est identique », indique-t-il. Le même jeton est utilisé pour l’ensemble du compte, ce qui constitue un compromis accessible à chaque projet public ou privé au sein de ce compte.

Le jeton pourrait être utilisé pour faire plus que créer un problème GitLab, comme signaler un bug ou demander une fonctionnalité. En modifiant simplement un suffixe pour le jeton, GitLab pourrait être amené à ouvrir une demande de fusion.

Cela permettrait à l’attaquant de soumettre un correctif contrefait, un fichier avec un ensemble de modifications de code, et de permettre à GitLab d’exécuter du code contrôlé par l’attaquant dans l’environnement CI/CD du projet.

Et fusionner les demandes

Après qu’Aikido ait signalé cela à GitLab, la société a modifié la description de l’interface utilisateur pour refléter que le jeton permet de créer des problèmes « et de fusionner des demandes ».

Leon a ajouté que la probabilité que ces adresses e-mail soient divulguées est élevée. « J’en ai trouvé une douzaine en ligne après quelques heures de recherche. Certains appartenaient à des projets open source populaires comme wget2 », a-t-il déclaré.

La recommandation d’Aikido est de traiter ces adresses e-mail comme des informations d’identification plutôt que comme des points de terminaison de messagerie ordinaires. Les organisations doivent rechercher les adresses exposées dans les référentiels et la documentation publics et, si une exposition est suspectée, réinitialiser le jeton de courrier électronique pour invalider l’adresse existante.

Sécurité des codesSécuritéOutils de développementDéveloppement de logicielsVulnérabilitésSécurité du courrier électroniqueSécurité des communicationsSécurité du réseau