- La vulnérabilité CVE-2023-7028 de GitLab reste présente sur 5 379 serveurs dans le monde environ deux semaines après la publication du correctif, avec un risque de compromission à distance de comptes de développeurs
- Le problème se situe dans le flux de réinitialisation de mot de passe du système de connexion, et permet à un attaquant de faire envoyer un lien de réinitialisation à sa propre adresse e-mail non vérifiée, sans interaction de la victime
- GitLab a publié le 11 janvier 2024 cette vulnérabilité notée CVSS 10 et a fourni des mises à jour de sécurité pour les versions 16.5.6, 16.6.4, 16.7.2 ainsi que des versions rétroportées 16.1.6~16.4.5
- La Shadowserver Foundation a détecté 5 379 instances vulnérables le 23 janvier, avec les plus fortes concentrations aux États-Unis (964) et en Allemagne (730), avant un recul à 4 652 le 24 janvier
- Les administrateurs de GitLab Community Edition et Enterprise Edition en self-managed doivent vérifier dans les logs les requêtes de réinitialisation sous forme de tableau multi-e-mails et activer la 2FA pour réduire le risque de prise de contrôle de compte
Risque lié à CVE-2023-7028
- CVE-2023-7028 est une vulnérabilité du système de connexion GitLab pouvant mener à une prise de contrôle de compte à distance sur des serveurs GitLab non corrigés
- GitLab a divulgué et corrigé cette vulnérabilité pour la première fois le 11 janvier 2024
- Le score CVSS de la vulnérabilité est de 10, soit le niveau de gravité maximal
- Un attaquant peut, via une requête HTTP spécialement conçue, faire envoyer un e-mail de réinitialisation de mot de passe à sa propre adresse e-mail non vérifiée sans interaction de la victime
- Un chercheur l’ayant testée sur GitLab Community Edition 16.6.1 a estimé sur AttackerKB que CVE-2023-7028 était « très efficace et facile à exploiter »
Versions affectées et correctifs
- GitLab a fourni des mises à jour de sécurité pour les versions suivantes
- 16.5.6
- 16.6.4
- 16.7.2
- Les correctifs ont aussi été rétroportés vers les versions suivantes
- 16.1.6
- 16.2.9
- 16.3.7
- 16.4.5
Résultats de détection de Shadowserver
- Environ deux semaines après la publication du correctif, le 23 janvier, la Shadowserver Foundation a détecté 5 379 instances GitLab vulnérables dans le monde
- Par pays, les États-Unis et l’Allemagne comptaient le plus grand nombre d’instances vulnérables
- États-Unis : 964
- Allemagne : 730
- Le 24 janvier, le tableau de bord Shadowserver faisait état d’une baisse à 4 652 instances vulnérables
- Shadowserver a indiqué que cette baisse était positive en soi, mais qu’il faudrait plus de temps pour déterminer s’il s’agit d’une véritable tendance ou d’une fluctuation temporaire liée au scan
Comment vérifier les indicateurs de compromission
- Les clients utilisant GitLab Community Edition et GitLab Enterprise Edition en self-managed doivent vérifier dans les logs les traces d’exploitation de CVE-2023-7028
- Les logs à examiner et les conditions sont les suivants
gitlab-rails/production_json.log: parmi les requêtes HTTP vers le chemin/users/password, lorsqueparams.value.emailest un tableau JSON contenant plusieurs adresses e-mailgitlabs-rails/audit_json.log: lorsquemeta.caller.idvautPasswordsController#createet quetarget_Detailsest un tableau JSON contenant plusieurs adresses e-mail
Impact sur GitLab.com, GitLab Dedicated et la 2FA
- GitLab a déclaré n’avoir détecté aucun cas d’exploitation de ce bug sur des instances GitLab.com ou GitLab Dedicated
- Il est recommandé aux clients d’activer la 2FA
- La 2FA empêche la prise de contrôle de compte via CVE-2023-7028, mais sur des instances non corrigées, un attaquant peut tout de même réinitialiser le mot de passe et verrouiller l’utilisateur hors de son compte
1 commentaires
Avis de Hacker News
Je trouve vraiment effrayantes les fonctionnalités qui permettent de lier des adresses e-mail à un compte dans les applis web basées sur des comptes.
Je ne connais pas l’historique de ce bug, mais c’est une zone que les pentesters testent immédiatement, et c’est un vieux type de faille qui remonte même aux vulnérabilités du début des années 2000 où l’on pouvait tromper les implémentations standard des MTA Unix pour qu’elles envoient les e-mails de réinitialisation de mot de passe à plusieurs adresses.
Avec GitLab, on dirait qu’un framework web riche en fonctionnalités a ressuscité cette surface d’attaque ; les lecteurs ordinaires de HN que cela intrigue feraient bien de vérifier les fonctions de réinitialisation de mot de passe, en particulier la logique d’association des e-mails.
Même si, à ma connaissance, l’équipe sécurité de GitLab est plutôt excellente, le fait qu’un tel bug soit apparu montre à quel point il est difficile d’éviter cette famille de bugs.
Avec un langage à typage statique, il aurait été difficile qu’il apparaisse sans le faire exprès, et il aurait tellement sauté aux yeux en revue de code qu’on aurait pu soupçonner un collègue d’essayer d’implanter une porte dérobée.
La fonctionnalité d’association d’adresses e-mail secondaires a été ajoutée récemment et n’existait pas à l’origine ; on dirait donc qu’ils ont pris un raccourci sans tester correctement les abus possibles d’une nouvelle fonctionnalité liée à la sécurité des comptes.
En plus, il semble qu’il y ait aussi eu une CVE avec un score CVSS de 9,6 permettant à une fonctionnalité d’intégration d’exécuter des commandes avec les droits d’un autre utilisateur.
Vu de l’extérieur, le rythme de sortie des fonctionnalités semble dépasser celui auquel elles peuvent être testées en toute sécurité, peut-être parce que la monétisation est difficile.
D’un point de vue business, cela peut se comprendre, mais si le cœur d’une solution Git auto-hébergée est en pratique la gestion des comptes, ce type de problème de sécurité peut faire s’effondrer l’activité elle-même.
À quoi faudrait-il les lier, sinon à une adresse e-mail ? J’ai exploité pendant plus de 20 ans des sites avec de grosses bases d’utilisateurs ; au début, on utilisait des noms d’utilisateur et ça a été une catastrophe.
Tout le monde connaissait les noms d’utilisateur des autres, ce qui rendait les tentatives de brute force ou de réinitialisation de mot de passe faciles.
Le problème n’est pas l’usage de l’e-mail en soi, mais le fait de rendre la logique de connexion et de récupération de mot de passe excessivement complexe, d’abuser des abstractions, de surconcevoir, et de pousser du code dans des zones sensibles pour la sécurité sans vérification correcte.
Il faut aussi regarder l’historique de sécurité de GitLab. Plusieurs fois par an, des exploits critiques obligeaient à mettre à jour en urgence les déploiements GitLab ; côté sécurité, GitLab est le pire produit que j’aie utilisé.
Ça ne m’est encore jamais arrivé, mais comme le montre ce cas, c’est malheureusement tout à fait possible.
Si vous voulez voir, dans la base de code Rails, la partie qui a mené à cet exploit, le commit de correction est ici :
https://gitlab.com/gitlab-org/gitlab/-/commit/c571840ba2f0e9...
La correction semble être ici : https://gitlab.com/gitlab-org/gitlab/-/commit/abe79e4ec43798...
recoverable.send_reset_password_instructions(to: email) if recoverable&.persisted?est devenurecoverable.send_reset_password_instructions if recoverable&.persisted?# Concern that overrides the Devise methods/# to send reset password instructions to any verified user email/module RecoverableByAnyEmail… donc c’était une fonctionnalité ?Pourtant, même dans la version corrigée, le nom
RecoverableByAnyEmailest toujours utilisé. Les gens ne lisent-ils pas le code autour de ce qu’ils modifient ?Nous avons aussi subi cette attaque, et nous avons vu qu’elle était utilisée avec une deuxième « fonctionnalité » qui augmentait encore l’exposition.
En gros, pour cette attaque, il faut connaître l’e-mail de l’utilisateur dont on veut réinitialiser le mot de passe, mais il existe une adresse e-mail masquée liée à l’ID utilisateur GitLab. Cet ID est un nombre qui augmente à partir de 1.
Les ID 1 ou 2 ont de fortes chances d’être des administrateurs, ce qui en fait de bonnes cibles, et l’e-mail est de la forme
1-user@mail.noreply...C’était vraiment mauvais, et ça semblait automatisé. Ici, c’est la 2FA qui nous a sauvés.
La réinitialisation de mot de passe par e-mail est un cauchemar de sécurité, même quand elle est correctement implémentée.
Pire encore, la plupart des services ne permettent pas de la désactiver, et le seul contournement est généralement un SSO Enterprise.
Certains services permettent de définir un numéro de téléphone pour les jetons SMS, mais je n’ai jamais vu de système exigeant à la fois l’e-mail et le jeton SMS.
Ça me rappelle un bug où l’on pouvait brute-forcer un compte en mettant un tableau de mots de passe dans le formulaire de connexion.
C’était justement l’interface web bricolée d’un équipement antispam, et je ne sais pas si c’était intentionnel ou du code écrit par un débutant en PHP.
C’est un utilisateur dont le mot de passe contenait un caractère spécial, rare à l’époque, qui l’avait découvert.
.where(...)dans l’ORM comme une condition OR entre les valeurs du tableau.Donc si le code ressemblait à
User.where(name: name, password: password), on peut tout à fait imaginer que cela arrive.Pour des services internes comme GitLab, c’est un bon rappel : il faut les placer derrière un VPN, accessibles uniquement aux utilisateurs de confiance
C’est précisément à ça que sert un VPN
Je travaille chez un grand opérateur télécom public, et les responsables réseau sont vraiment excellents. Ils veillent à ce que les administrateurs serveurs ne dépassent pas les limites
Nous avons bien exposé GitLab dans une certaine mesure pour certains projets externes et consultants, mais il n’est toujours pas librement accessible depuis Internet
Les utilisateurs sont aussi gérés dans AD, donc il n’y a même pas de connexion SMTP pour la réinitialisation des mots de passe
En revanche, il faut renforcer l’obligation de 2FA. Pour l’instant, on laisse chaque projet définir ses propres règles de 2FA
Honnêtement, je ne mettrais aucun serveur interne sur l’Internet public
Mieux vaut n’autoriser l’accès que via VPN et disposer d’une deuxième ligne de défense
Il serait possible de n’autoriser précisément que ces requêtes, mais cela peut être assez pénible
Dans un environnement à haute sécurité, je suis d’accord pour employer des tactiques plus défensives, mais je pense qu’un logiciel doit être conçu pour résister aussi sur le web public
Automatiser les mises à jour de GitLab est vraiment simple
Pour ne prendre qu’une méthode, si on utilise GitLab avec Docker+Compose, c’est très stable, et un outil comme Watchtower peut le mettre à jour tous les jours
J’ai deux serveurs GitLab que j’exploite ainsi depuis plus de 7 ans, sans aucun problème
Quand je regarde autour de moi, je vois beaucoup trop de GitLab obsolètes, et je me demande vraiment ce que font les administrateurs
J’aimerais qu’on arrête de faire semblant que Ruby/Rails est un bon choix pour des logiciels qui doivent être sûrs
Je comprends que GitLab soit déjà dans cette situation et qu’il faille faire avec, mais à l’avenir, il faut arrêter de prétendre que les langages et frameworks qui privilégient l’astuce et les flux de contrôle cachés sont préférables à des alternatives plus ennuyeuses
Si j’ai l’air excessivement agacé, c’est parce que je dois gérer des bases de code Ruby en production
Comme quelqu’un a pensé que 17 couches d’abstraction rendaient le code incroyablement extensible, je vois largement assez de scénarios où des problèmes similaires n’attendent que d’être exploités
Le coût de cette seule erreur risque fort de dépasser toute la valeur apportée par l’usage de cette fonctionnalité
Encore un rappel qu’il faut toujours utiliser le SSO et la 2FA