RetourDeVulnérabilité#1 - Un bounty Gitlab à 9.500$ (FR)
mer. 24 avril 2019 Dan Lousqui
Avant-propos
Ce billet est le premier d'une série que j'espère longue. Il s'agit ici de faire des retours sur des vulnérabilités présentes dans l'actualité cyber. Cette série est nommée Retour de vulnérabilité. Le but de ces billets est principalement de faire de la veille en sécurité, aussi bien pour les personnes ayant des appétences en offensif (pentesteurs, red team, auditeurs), qu'en défensif (développeurs, RSSI, blue team).
Ces billets seront tous au même format :
- Contexte -- présentation du produit, ou de l'entreprise, vulnérable ainsi que de la fonctionnalité en question.
- Implémentation -- comment la fonctionnalité est conçue.
- Exploitation -- explication de pourquoi l'implémentation est vulnérable et comment l'exploiter.
- Remédiation -- Ce qu'il faut faire pour corriger la vulnérabilité.
Les vulnérabilités traitées seront celles que je trouverais personnellement "hors du commun", soit par leur technicité, soit par leur originalité, toujours dans le but de découvrir des choses "inhabituelles".
Pour ce premier billet, nous allons traiter d'une vulnérabilité trouvée par rijalrojan (@uraniumhacker) le 21 février 2019 et diffusée le 19 avril 2019.
1. Contexte
Gitlab est l'entreprise qui édite un clone open-source de GitHub. La vulnérabilité en question ne concerne pas le produit Gitlab, mais plutôt l'écosystème d'outillage interne à l'entreprise.
En particulier, les éléments suivants seront ciblés :
- Annuaire des employés / collaborateurs
- Outil de ticketing
- Single Sign-On / Identify Provider (c'est-à-dire les mécanismes de centralisation des comptes au travers des différentes applications internes)
2. Implémentation
a. Annuaire des employés / collaborateurs
Pour gérer les comptes (et probablement les droits) sur ses outils, Gitlab utilise les Google Account.
Chaque employé / collaborateur possédant un email en @gitlab.com peut créer un compte Google (qui n'est pas forcément un compte utilisant Gmail, il est possible d'avoir un compte Google foo@bar.com sans que Google gère les emails du domaine bar.com)
Pour créer un compte, il suffit :
- d'aller sur
https://accounts.google.com; - de renseigner email, nom et prénom ;
- de cliquer sur un lien de validation dans un email de confirmation.
b. Outil de ticketing
Un outil de ticketing est une plateforme qui permet aux utilisateurs d'un service de pouvoir contacter l'entreprise facilement, afin de faire un suivi sur une discussion. Pour ce faire, l'entreprise Gitlab utilise les services de Zendesk.
Zendesk fournis plusieurs moyens de créer des tickets. L'un d'entre eux est le support par email : l'envoi d'un email à support@gitlab.com générera la création d'un ticket.
Une fois le ticket crée, pour assurer le suivi du ticket (c'est-à-dire le fait de lier plusieurs échanges d'email au même ticket), un hash est généré à la création du ticket. Dans le cadre des échanges par email, lors de la création du ticket, une réponse automatique est envoyée au créateur du ticket contenant ce hash dans le titre de l'email. Ainsi, si l'utilisateur répond à ce message, le hash sera inclus dans le message, et la plateforme pourra lier la réponse au ticket.
Il est également possible pour le créateur d'un ticket de lire l'ensemble des échanges effectués dans ce ticket.
c. Single Sign-On / Identify Provider
Les applications internes de Gitlab utilisent Google Auth pour identifier les utilisateurs. Ainsi, quiconque avec un compte Google dans le contexte de Gitlab pourra s'authentifier sur l'application. Parmi les applications utilisant ce mécanisme, on peut trouver :
prometheus.gitlab.comredash.gitlab.comdashboards.gitlab.comalerts.gitlab.com
3. Exploitation
Vous la voyez l'exploitation ? Quand on présente les éléments comme ça, cela semble trivial :
1. Mise en place d'un "hook" d'email en @gitlab.com
Rien de plus simple, il suffit d'envoyer un email à support@gitlab.com. Un email sera retourné, contenant un hash, ainsi :
- tout email envoyé à
support@gitlab.comcontenant ce hash (que ce soit dans le titre, ou tout autre champ, tel que nom ou corp) sera lié au ticket ; - une mesure de sécurité existe néanmoins, si la personne envoyant un email avec le hash n'est pas autorisée à contribuer au ticket, cela ne marchera pas. Pour autoriser quelqu'un, il suffit que quelqu'un de préalablement autorisé l'ajoute en
CCdans un message de suivi du ticket ; - d'aller sur la page de récapitulatif du ticker (sur Zendesk) pour lire les emails.
2. Création d'un compte Google en @gitlab.com
Lors de la création d'un compte Google, l'email contenant le lien de validation est envoyé de la part de noreply@google.com. Il faut donc ajouter cette adresse aux utilisateurs autorisé dans le ticket. Pour cela, il suffit de faire une réponse à l'email de confirmation de création du ticket, avec noreply@google.com en copie.
Ensuite, il suffit d'aller sur https://accounts.google.com, de créer un compte pour support@gitlab.com, avec comme prénom le hash (afin qu'il soit présent dans l'email de validation de lien).
En allant sur le récapitulatif du ticket, l'email de confirmation de création de compte est visible, et il est possible de finaliser la création de compte.
3. Accéder aux applications internes de l'entreprise
Il suffit simplement d'utiliser le compte crée pour accéder aux applications internes.
Pour trouver une liste d'application interne, rien de plus simple, on peut utiliser la fonctionnalité de Certificate Transparancy pour les retrouver, en recherchant %.gitlab.com sur https://crt.sh
4. Remédiation
Je trouve ce type d'exploitation très élégante. De nombreuses entreprises / freelanceurs / bounty-hunters sont déjà passés maintes et maintes fois sur Gitlab, et aucune n'ont trouvé ce défaut.
De plus, il s'agit là d'un problème dans le workflow de plusieurs fonctionnalités qui ne sont pas compatibles :
- Permettre une manipulation du ticketing par email ;
- Identifier (et permettre la création de compte) un collaborateur uniquement par le domaine d'un d'email et un secret envoyé dessus.
Il faut donc être extrêmement vigilant sur ces deux fonctionnalités. De plus, lors des remédiations, il faut garder en tête que de nombreux fournisseurs d'email permettent d'utiliser l'astuce du "+" pour dupliquer des adresses emails (et donc des comptes).
Certains éléments de remédiations évidents peuvent être effectués pour cette vulnérabilité:
- Enlever l'auto enrollment d'un compte Google (uniquement par l'email) ;
- Gérer les droits dans les applications en "liste blanche".
La vulnérabilité est très loin d'être technique, et pourtant, le bounty hunter s'est fait récompenser de 9.500$, ça donne envie, n'est-ce pas ?