GitLab exploite les adresses email pour des attaques de chaîne d'approvisionnement

Contexte et découverte

Une analyse récente d'Aikido a mis en évidence une fonctionnalité méconnue des adresses email entrantes de GitLab. Chaque adresse contient un jeton d’accès non expirant qui agit comme propriétaire du projet associé. Cette conception, prévue pour simplifier les flux de travail automatisés, a été détournée lorsqu’une adresse a fuité, ouvrant la porte à des actions non autorisées sur les dépôts.

Mécanisme d'exploitation des adresses email GitLab

Le jeton intégré permet à l’expéditeur d’interagir avec l’API GitLab comme s’il était le propriétaire du projet. Un acteur malveillant peut donc créer des merge requests, soumettre des correctifs ou pousser du code dans des projets privés, même après avoir modifié les identifiants du projet. En outre, l’accès par email contourne les restrictions d’IP, car l’authentification repose uniquement sur le jeton présent dans le message, rendant les filtres réseau inefficaces.

Impacts sur la chaîne d'approvisionnement et mesures d’atténuation

Ces capacités permettent d’injecter du code malveillant directement dans le pipeline de CI/CD, compromettant ainsi la chaîne d’approvisionnement logicielle. Les chercheurs recommandent trois actions concrètes : rotation proactive des jetons associés aux adresses email, scan systématique des dépôts et environnements de développement pour détecter la présence de ces adresses, et traitement des adresses comme des secrets sensibles, en les excluant des logs publics et en limitant leur exposition.

Autres vecteurs d’attaque récemment observés

Le même rapport recense d’autres campagnes, dont PhantomRaven, un voleur d’informations généré par LLM et distribué via des paquets npm typosquattés. Ce script JavaScript récupère les données d’OS, les identifiants Git/NPM et les variables d’environnement CI/CD, puis les transmet via des requêtes HTTP. La mitigation principale consiste à bloquer les scripts d’installation pré‑définis (npm 12+ le fait par défaut) ou à désactiver les scripts avec l’option --ignore‑scripts et à recourir à un registre privé.