CVE-2024-5806
MoveIT Authentication Bypass
Introduction
Remote | ✅ |
Authenticated | ❌ |
Default config | ✅ |
Source | 🌍 |
Versions concernées
- MOVEit Transfer 2023.0 < 2023.0.11
- MOVEit Transfer 2023.1 < 2023.1.6
- MOVEit Transfer 2024.0 < 2024.0.2
Détails
Le 25 Juin 2024, la société Progress a publié un bulletin d’alerte concernant son produit MoveIT Transfer portant sur une vulnérabilité, identifiée comme CVE-2024-5806 (CVSSv3.1 : 9.1), permettant d’outre passer l’authentification. Si le nom du logiciel MoveIT Transfer n’est pas étranger aux personnes suivant l’actualité cyber, c’est parce que ce dernier a beaucoup fait parler de lui en 2023. En effet, à cette période, 3 vulnérabilités permettant d’outrepasser l’authentification ont été publiées à quelques jours d’intervalle . Il n’en avait pas fallu plus pour que le groupe de ransomware Cl0p ne se saisisse de l’information et mène une attaque de masse touchant environ 2600 organisations [1] à travers le monde.
Ainsi l’annonce d’une nouvelle vulnérabilité du même type et sur le même produit ne peut qu’attirer l’attention. Cela peut probablement expliquer la gestion adoptée par Progress concernant cette vulnérabilité : l’entreprise a publié des mises à jour et a contacté directement ses clients avant de publier la note de sécurité 15 jours plus tard.
Le jour de l’annonce, le détail complet de la vulnérabilité a été publiée par la société WatchTowr [2]. Cette analyse permet de mieux comprendre le fonctionnement de la vulnérabilité ainsi que les prérequis pour l’exploiter. De plus, un outil permettant de preuve de concept a été également mis à disposition [3].
Cela met en évidence une problématique double : d’une part une erreur de logique dans l’application MoveIT, mais également un comportement inattendu dans une des librairies utilisées à savoir IPWorks SSH.
Pour résumer la vulnérabilité : lors d’une authentification par clé SSH sur le produit, il est possible de passer le chemin d’un fichier qui sera accéder en lieu et place d’une clé publique. Dans le cas où le fichier existe et contient une clé publique correspondant à celle utilisée par l’attaquant, l’empreinte de la clé envoyée par la librairie sera vide. L’attaquant sera considéré comme partiellement authentifié, comme dans le cas où un mot de passe est requis en plus d’une clé SSH par exemple, ce qui entraînera une nouvelle séquence d’authentification. Cependant, une condition sur la présence d’une empreinte en cache fera que, lors de cette seconde authentification, l’empreinte “vide” sera présence dans le cache et sera donc acceptée.
Le prérequis de la présence d’une clé publique sur le système de fichier du serveur est atteignable de manière non authentifiée en utilisant une clé au format PPK (Putty Private Key) et en polluant les logs (log poisoning) afin d’y faire référence.
Détection
La vulnérabilité étant connue depuis quelques temps mais sous embargo, des règles ont été mises à disposition rapidement après la publication de la vulnérabilité :
2053883 | ET EXPLOIT MoveIT Transfer SFTP Authentication Bypass Attempt Inbound M0 (CVE-2024-5806) |
2053884 | ET EXPLOIT MoveIT Transfer SFTP Authentication Bypass Attempt Inbound M1 (CVE-2024-5806) |
La détection se fait donc sur le endpoint /guestaccess.aspx utilisé pour empoissonner les logs avec une clé publique.
Comme cela a été souligné dans l’analyse, une autre possibilité est d’utiliser un chemin de fichier UNC (\\server\chemin\ressource ) ainsi que l’outil Responder afin d’obtenir le hash NTLM de l’utilisateur sur service sftp de la solution. Il peut donc également être utile de considérer l’activation de la règle suivante :
2051116 | ET INFO Outbound SMB2 NTLM Auth Attempt to External Address |
Correction
Comme indiqué précédemment, l’éditeur a publié les mises à jour avant la publication de la vulnérabilité les correctifs sont dont disponibles sur la page du bulletin d’alerte.
Au vu des impacts des précédentes vulnérabilités, il est fortement conseillé de mettre à jour au plus tôt les instances vulnérables.
Il est également important de rappeler qu’il est nécessaire de vérifier les logs des instances vulnérables même si celles-ci ont été mises à jour, car si une instance a été compromise avant la correction, l’attaquant peut toujours avoir un accès au système ou avoir pu exfiltrer des données.
Sources :
[1] https://konbriefing.com/en-topics/cyber-attacks-moveit-victim-list.html
[3] https://github.com/watchtowrlabs/watchTowr-vs-progress-moveit_CVE-2024-5806?ref=labs.watchtowr.com