Plus de 5 300 instances GitLab exposées à Internet sont vulnérables à CVE-2023-7028, une faille de prise de contrôle de compte sans clic dont GitLab a mis en garde plus tôt ce mois-ci.

La faille critique (score CVSS: 10,0) permet aux attaquants d’envoyer des e-mails de réinitialisation de mot de passe pour un compte ciblé à une adresse e-mail contrôlée par l’attaquant, permettant à l’auteur de la menace de changer le mot de passe et de prendre le contrôle du compte.

Bien que la faille ne contourne pas l’authentification à deux facteurs (2FA), il s’agit d’un risque important pour tout compte non protégé par ce mécanisme de sécurité supplémentaire.

Le problème affecte les versions GitLab Community et Enterprise Edition 16.1 avant 16.1.5, 16.2 avant 16.2.8, 16.3 avant 16.3.6, 16.4 avant 16.4.4, 16.5 avant 16.5.6, 16.6 avant 16.6.4 et 16.7 avant 16.7.2.

GitLab a publié des correctifs dans 16.7.2, 16.5.6 et 16.6.4, ainsi que des correctifs de rétroportage vers 16.1.6, 16.2.9 et 16.3.7, le 11 janvier 2024.

Aujourd’hui, 13 jours après la mise à disposition des mises à jour de sécurité, le service de surveillance des menaces ShadowServer signale avoir vu 5 379 instances GitLab vulnérables exposées en ligne.

Sur la base du rôle de GitLab en tant que plate-forme de développement logiciel et de planification de projet et du type et de la gravité de la faille, ces serveurs sont exposés à des attaques de la chaîne d’approvisionnement, à la divulgation de code propriétaire, à des fuites de clés API et à d’autres activités malveillantes.

Shadowserver rapporte que la plupart des serveurs vulnérables se trouvent aux États-Unis (964), suivis de l’Allemagne (730), de la Russie (721), de la Chine (503), de la France (298), du Royaume-Uni (122), de l’Inde (117) et du Canada (99).

Emplacement des instances GitLab vulnérables

Ceux qui n’ont pas encore été corrigés ont peut-être déjà été compromis, il est donc essentiel d’utiliser le guide de réponse aux incidents Gitlab et de rechercher des signes de compromission.

GitLab a précédemment partagé les conseils de détection suivants pour les défenseurs:

  • Vérifiez gitlab-rails / production_json.connectez-vous pour les requêtes HTTP au chemin /users/password avec params.valeur.email composé d’un tableau JSON avec plusieurs adresses e-mail.
  • Vérifiez gitlab-rails / audit_json.connectez-vous pour les entrées avec meta.caller.id de PasswordsController#create et target_details consistant en un tableau JSON avec plusieurs adresses e-mail.

Les administrateurs qui trouvent des instances qui ont été compromises doivent effectuer une rotation de toutes les informations d’identification, jetons d’API, certificats et autres secrets, en plus d’activer 2FA sur tous les comptes et d’appliquer la mise à jour de sécurité.

Après avoir sécurisé les serveurs, les administrateurs doivent vérifier les modifications apportées à leur environnement de développement, y compris le code source et les fichiers potentiellement altérés.

À ce jour, il n’y a eu aucun cas confirmé d’exploitation active de CVE-2023-7028, mais cela ne doit pas être interprété comme une raison de reporter l’action.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *