Service Hacktion - Notes attachées au balado S01E04 - Analyse de la vulnérabilité Gitlab CVE-2023-7028

Saison Épisode
1 4

Notes#

Gitlab en bref :

  • forge logicielle (gestion du code source, intégration et déploiement continue, collaboration, etc.)
  • beaucoup déployé en interne dans les entreprises

La vulnérabilité en bref :

  • Risque : Critique (CVSS v3 7.5 selon le NIST, 10.0 selon le CNA (Gitlab))
  • Cible : large spectre de versions de l'édition communautaire (CE) et entreprise (EE)
  • Impact : Permet de prendre le contrôle arbitrairement de comptes utilisateurs (sans authentification et sans interaction)
  • Fonctionnement : L'attaquant fournit 2 adresses dans la requête de réinitialisation (la sienne et celle de la victime), il reçoit le lien de réinitialisation de la victime
  • Cause : les courriels de réinitialisation du mot de passe d'un compte d'utilisateur peuvent être envoyés à une adresse non vérifiée
  • Identifiée par asterion04 lors d'un programme de prime aux bogues
  • Versions affectées :
    • 16.1.0 à 16.1.5
    • 16.2.0 à 16.2.8
    • 16.3.0 à 16.3.6
    • 16.4.0 à 16.4.4
    • 16.5.0 à 16.5.5
    • 16.6.0 à 16.6.3
    • 16.7.0 à 16.7.1
  • Correction :
    • MAJ vers version non vulnérable
    • Activer l'authentification à deux facteurs
    • Par mesure de sécurité, réinitialiser tous les secrets (comptes, jetons d'API, certificats, etc.)

Détails :

  • HTTP POST sur /users/password
  • Charge utile (exemple) : authenticity_token=<auto_generated_token>&user%5Bemail%5D%5B%5D=victim%40example.org&user%5Bemail%5D%5B%5D=attacker%40example.org
  • authenticity_token = jeton anti-CSRF (obtenable sur /users/password/new)
  • user[email] x1 ➡️ user[email][] x2 (passage en tableau)
  • user[email][]=victim@example.org&user[email][]=attacker@example.org doit être URL encodé sinon l'attaque ne fonctionne pas
  • besoin de connaitre l'adresse de courriel (pas le nom de compte)
  • impact variable selon que des projets sont exposés publiquement ou non

Plus-value pour l'attaquant :

  • Très répendu
  • Facile à exploiter
  • Peut donner des accès privilégiés
  • Attaque non authentifiée
  • Vulnérable par défaut (sans changement de configuration)
  • Donne accès à des données sensibles et permet de rebondir

Recherche de compromission :

  • Vérifiez la présence de requêtes HTTP vers le chemin /users/password avec params.value.email dans le journal d'évènements gitlab-rails/production_json.log comprenant un tableau JSON avec plusieurs adresses de courriel.
  • Vérifier la présence d'entrées avec meta.caller_id de PasswordsController#create et target_details dans le journal d'évènements gitlab-rails/audit_json.log comprenant un tableau JSON avec plusieurs adresses de courriel.

L'introduction dans le code source :

  • En 16.1.0, le 1er mai 2023
  • Un changement qui permettait aux utilisateurs de réinitialiser leur mot de passe via une adresse de courriel secondaire
  • Bogue dans le procès de vérification de l'adresse de courriel
  • diff du correctif

Par défaut, la gemme devise autorise la réinitialisation du mot de passe à partir d'un courriel primaire non confirmé. Lorsque le compte d'un utilisateur a une adresse primaire non confirmée, cela signifie que le compte n'est pas confirmé. La réinitialisation du mot de passe par le courriel primaire non confirmé est très utile du point de vue de la sécurité. Exemple : Une personne malveillante crée un compte utilisateur sur GitLab avec l'adresse courriel de quelqu'un. Si le propriétaire de l'adresse confirme le courriel pour le compte nouvellement créé, la personne malveillante pourra se connecter au compte avec le mot de passe qu'elle a fourni lors de l'inscription au compte. La personne malveillante peut configurer 2FA pour le compte utilisateur, après quoi le propriétaire de l'adresse ne pourra plus accéder à ce compte utilisateur même après avoir réinitialisé le mot de passe. Déni de service, plus personne ne peut utiliser le compte, cette adresse est bloquée sur un compte inutilisable.

Pour traiter ce cas en toute sécurité, le propriétaire de l'adresse doit d'abord réinitialiser le mot de passe du compte utilisateur (au moment de la confirmation ?). Cela permettra de s'assurer qu'une fois le compte utilisateur confirmé, la personne malveillante ne pourra pas se connecter avec le mot de passe qu'elle a fourni lors de l'inscription au compte. Ensuite, le propriétaire du courriel peut se connecter au compte, il verra une invitation à confirmer le courriel du compte pour continuer. Il peut alors confirmer le courriel en toute sécurité et prendre le contrôle du compte. C'est l'une des raisons pour lesquelles la réinitialisation du mot de passe par un courriel primaire non confirmé devrait être autorisée.

Alors que les courriels primaires non confirmés sont liés aux comptes des utilisateurs, les courriels secondaires non confirmés ne devraient pas être liés aux utilisateurs jusqu'à ce qu'ils soient confirmés. Dans le #367823, il est envisagé d'empêcher la réservation de courriels sur Gitlab par des courriels secondaires non confirmés. Selon ce problème, il pourrait y avoir des cas où il y a plusieurs utilisateurs avec les mêmes courriels secondaires non confirmés. Il serait impossible d'identifier pour quel compte utilisateur la réinitialisation du mot de passe est demandée si la réinitialisation du mot de passe était autorisée par des courriels secondaires non confirmés. Notez également qu'il n'est pas possible de demander une confirmation par courriel pour les courriels secondaires non confirmés sans avoir accès au compte d'utilisateur.

  • ✅ courriel primaire confirmé ➡️ envoi à cette adresse uniquement
  • ✅ courriel primaire non confirmé (cf. explication précédente) ➡️ envoi à cette adresse uniquement
  • ✅ courriel secondaire confirmé (cf. explication précédente) ➡️ envoi à cette adresse uniquement
  • ❌ courriel secondaire non confirmé (cf. explication précédente) ➡️ n'envoi rien à personne
  • ❌ courriel inconnu ➡️ n'envoi rien à personne
  • ❌ plusieurs courriels ➡️ n'envoi rien à personne

Ressources :

Partager