Serveurs non corrigés pour la vulnérabilité GitLab CVE-2023-7028
- La vulnérabilité critique CVE-2023-7028 de GitLab n’était toujours pas corrigée sur plus de 5 300 serveurs à mardi, ce qui permettrait la compromission à distance des comptes de développeurs.
- Ce bug a reçu le score CVSS maximal de 10, et GitLab l’a révélé et corrigé pour la première fois le 11 janvier.
- En raison d’une faille dans le système de connexion de GitLab, un attaquant peut envoyer un lien de réinitialisation de mot de passe vers une adresse e-mail non authentifiée, sans interaction de la victime.
Informations sur le correctif et résultats des tests de la vulnérabilité
- Des mises à jour de sécurité ont été publiées pour GitLab versions 16.5.6, 16.6.4 et 16.7.2, avec rétroportage également vers les versions 16.1.6, 16.2.9, 16.3.7 et 16.4.5.
- Un chercheur a testé le bug sur GitLab Community Edition version 16.6.1 et a partagé sur AttackerKB qu’il était « très efficace et facile à exploiter ».
Détection des instances vulnérables et tendance à la baisse
- Près de deux semaines après la disponibilité du correctif, la Shadowserver Foundation a détecté 5 379 instances GitLab vulnérables dans le monde.
- Les États-Unis et l’Allemagne comptaient le plus grand nombre d’instances vulnérables, avec respectivement 964 et 730.
- L’outil de tableau de bord de Shadowserver montrait, le 24 janvier, une baisse à 4 652 instances vulnérables.
- Un porte-parole de Shadowserver a indiqué à SC Media que cette diminution constituait une évolution positive, mais qu’il faudrait davantage de temps pour déterminer s’il s’agit d’une tendance ou d’une simple fluctuation.
Indicateurs de compromission pour GitLab CVE-2023-7028
- Les clients GitLab disposant d’instances autohébergées de GitLab Community Edition et GitLab Enterprise Edition doivent examiner leurs journaux afin de vérifier si CVE-2023-7028 a été exploitée.
- Il faut vérifier dans
gitlab-rails/production_json.log les requêtes HTTP vers le chemin /users/password, et confirmer si params.value.email est constitué d’un tableau JSON contenant plusieurs adresses e-mail.
- Il faut vérifier dans
gitlabs-rails/audit_json.log les entrées où meta.caller.id est PasswordsController#create et où target_Details est constitué d’un tableau JSON contenant plusieurs adresses e-mail.
- Aucune exploitation de ce bug n’a été détectée sur GitLab.com ni sur les instances dédiées GitLab.
- GitLab recommande également d’activer l’authentification à deux facteurs (2FA), ce qui empêche la compromission de compte via CVE-2023-7028, mais les utilisateurs d’instances non corrigées risquent toujours d’être verrouillés hors de leur compte si un attaquant exploite la faille pour réinitialiser le mot de passe.
L’avis de GN⁺
- Cet article fournit des informations importantes sur une vulnérabilité de sécurité critique de GitLab. CVE-2023-7028 peut constituer une menace directe pour la sécurité des comptes de développeurs et exige des mesures appropriées.
- Bien qu’un correctif soit disponible, un grand nombre de serveurs dans le monde restent vulnérables, ce qui souligne l’importance de la sensibilisation à la sécurité et de mises à jour effectuées à temps.
- Il met en avant l’importance de l’authentification à deux facteurs (2FA) et encourage les utilisateurs à recourir à des moyens de sécurité supplémentaires, contribuant ainsi à renforcer la sensibilisation à la sécurité.
1 commentaires
Avis sur Hacker News
« Je veux parler du risque de la fonctionnalité qui “associe une adresse e-mail à un compte” dans les applications web basées sur des comptes. C’est l’une des premières choses que les pentesters essaient immédiatement de manipuler, et des vulnérabilités y sont découvertes depuis le début des années 2000. Le même problème s’est reproduit chez GitLab. GitLab dispose d’une excellente équipe sécurité, mais il semble difficile d’éviter ce type de bug. Si cette histoire intéresse un lecteur lambda de Hacker News, j’espère qu’il ira vérifier sa propre fonctionnalité de réinitialisation de mot de passe, en particulier la logique d’association d’e-mail. »
« Je partage le lien du commit où cette vulnérabilité a été repérée dans la base de code Rails : lien vers le commit GitLab »
« J’ai été touché par ce bug. L’attaque nécessite de connaître l’e-mail de l’utilisateur, mais il existe une adresse e-mail cachée liée à l’ID utilisateur GitLab (un nombre qui s’incrémente à partir de 1). Les ID 1 ou 2 ont de fortes chances d’être des administrateurs, ce qui en fait de bonnes cibles. Le format de l’e-mail ressemble à
1-user@mail.noreply.<gitlabhost>. Cela avait l’air d’une attaque automatisée, et la 2FA nous a sauvés. »« La réinitialisation de mot de passe par e-mail est un cauchemar de sécurité, même lorsqu’elle est correctement implémentée. Dans la plupart des services, il est impossible de désactiver cette fonction, et l’alternative se limite souvent au SSO d’entreprise. Certains services permettent de configurer un numéro de téléphone pour des jetons SMS, mais je n’ai jamais vu d’option imposant à la fois l’e-mail et un jeton SMS. »
« J’ai déjà trouvé un bug qui permettait de lancer une attaque par force brute sur un compte en saisissant un tableau de mots de passe dans le formulaire de connexion. C’était une interface web bricolée pour un appliance antispam, et je n’ai jamais su si c’était intentionnel ou si un débutant en PHP avait écrit le code. À l’époque, un utilisateur qui employait un mot de passe contenant des caractères spéciaux avait découvert le problème. »
« Cela rappelle qu’il vaut mieux faire tourner des services internes comme GitLab derrière un VPN, afin que seuls des utilisateurs de confiance puissent y accéder. »
« Automatiser les mises à jour de GitLab est très simple. Il suffit d’utiliser GitLab avec Docker+Compose et de le mettre à jour chaque jour via Watchtower ou équivalent. J’administre des serveurs GitLab ainsi depuis plus de 7 ans sans problème. Quand on regarde autour de soi, beaucoup de GitLab tournent encore sur d’anciennes versions ; que font donc les administrateurs ? »
« J’ai pour principe de ne jamais exposer au web public aucun type de serveur interne. Je rends l’accès possible uniquement via VPN, ce qui ajoute une deuxième ligne de défense. »
« Encore un rappel qu’il faut toujours utiliser le SSO et ne pas oublier d’activer la 2FA. »
« Arrêtons de penser que Ruby/Rails est un choix adapté pour des logiciels qui doivent être sûrs. Je comprends que GitLab doive faire avec, mais il faut reconnaître qu’à l’avenir, quelque chose de plus simple vaut mieux que des langages et frameworks qui privilégient des flux de contrôle intelligents et cachés. Je travaille sur une base de code Ruby en production, et je vois très bien comment des problèmes similaires peuvent survenir à cause de quelqu’un qui pense que plusieurs couches d’abstraction rendent le code extrêmement extensible. »