Il y a environ un an, une vague d’attaques frappait les organisations utilisant l’application de transfert de fichiers géré MOVEit Transfer de Progress Software. À l’époque, la vulnérabilité critique CVE-2023-34362 permettait à un attaquant non authentifié de prendre le contrôle de la base de données et pouvait même mener à l’exécution de code à distance.
Aujourd’hui, les organisations sont pressées d’appliquer les correctifs, Progress Software ayant publié un avis de sécurité. La CVE-2024-5806, nouvellement divulguée, est une vulnérabilité critique du module SFTP de MOVEit Transfer qui permet à un attaquant non authentifié de contourner l’authentification SSH et d’accéder à n’importe quel utilisateur et à ses fichiers. Des analyses techniques détaillées de la vulnérabilité ont été publiées indépendamment par Watchtowr et par Rapid7.
La cause première: une erreur de logique
D’après les deux analyses, la cause première de la vulnérabilité est une erreur de logique attribuable à une mauvaise gestion de l’état de l’application pendant l’authentification. La fonction Authenticate suivante était vulnérable; la version corrigée définit un code d’erreur et une description dans deux cas précis.
public AuthenticationResult Authenticate(SILUser user)
{
if (string.IsNullOrEmpty(this._publicKeyFingerprint) && !this._keyAlreadyAuthenticated)
{
this._logger.Error("Attempted to authenticate empty public key fingerprint");
+ this.StatusCode = 2414;
+ this.StatusDescription = "No public key provided";
return AuthenticationResult.Denied;
}
if (string.IsNullOrEmpty(user.ID))
{
this._logger.Debug("No user ID provided for public key authentication");
+ this.StatusCode = 2050;
+ this.StatusDescription = this._i18N.GetMsg(60001);
return AuthenticationResult.Denied;
}Les équipes ont constaté que les deux branches conditionnelles où l’application refuse l’authentification (AuthenticationResult.Denied) sans modifier le StatusCode, qui reste à 0 (la valeur par défaut), mènent à un état vulnérable permettant à un attaquant de contourner l’authentification.
Plus loin dans la logique d’authentification, si le StatusCode est à 0 alors que le résultat initial est AuthenticationResult.Denied, le résultat devient Authentication.Indeterminate, ce qui indique que la clé publique était valide mais qu’une authentification supplémentaire est requise. Comme le statut Authentication.Indeterminate implique une clé valide, l’application retient que la clé a déjà été validée: les vérifications suivantes de _keyAlreadyAuthenticated seront donc vraies et la suite de la logique finira par authentifier l’utilisateur.
L’équipe de Watchtowr a d’abord montré comment exploiter le problème au moyen d’une vulnérabilité de type « zéro jour » dans une bibliothèque tierce, qui permettait de fournir une empreinte de clé vide et donc d’entrer dans le premier « if ». Environ une semaine plus tard, l’analyse de Rapid7 a démontré un exploit passant par le second « if », en réussissant à fournir un identifiant d’utilisateur vide.
La bibliothèque tierce: IPWorks SSH
Les chercheurs de Watchtowr ont relevé un comportement inhabituel dans la bibliothèque tierce IPWorks SSH, utilisée par le module SFTP de MOVEit pour gérer les connexions SSH. Lors d’une authentification au serveur par clé publique SSH, la bibliothèque tentait de traiter la clé fournie comme un chemin d’accès et essayait même de charger le fichier situé à ce chemin en s’attendant à y trouver une clé valide. Le comportement normalement attendu est que les données de clé contenues dans la requête d’authentification soient la clé elle-même.
En modifiant un client SSH par « monkey patching », les chercheurs ont pu déclencher le comportement vulnérable, à condition de disposer d’un nom d’utilisateur valide. Dans leurs premiers scénarios d’attaque, ils ont démontré qu’il était possible de forcer une authentification SMB en fournissant un chemin UNC au serveur. Cela livrait l’empreinte NetNTLM du compte exécutant le serveur SFTP et permettait même des attaques par relais en l’absence de pare-feu. Ce scénario pouvait mener à la compromission complète du serveur si le compte compromis pouvait se connecter à distance et détenait des privilèges dangereux.
La nécessité de connaître un nom d’utilisateur valide pourrait sembler limitative, mais les chercheurs ont aussi montré que, le fichier n’étant récupéré que si le nom d’utilisateur était valide, un attaquant pouvait tester des noms d’utilisateur en série tout en pointant le chemin vers un serveur distant à l’écoute des interactions DNS. Toute interaction révélait alors un nom d’utilisateur valide.
Le second scénario d’attaque, plus dévastateur, tenait à ce qui se produisait après le chargement de la clé située au chemin indiqué. Si le chemin pointait vers une clé valide, la requête était certes validée, mais la valeur de _publicKeyFingerprint retournée par la bibliothèque était vide. Cela déclenchait la première branche conditionnelle et permettait ensuite le contournement de l’authentification.
Watchtowr a également discuté de diverses techniques employées pour fournir localement une clé contrôlée par l’attaquant, afin que l’exploit ne dépende pas de la présence d’un pare-feu. En résumé, l’analyse laxiste des clés privées PuTTY, combinée à une injection dans les journaux par un utilisateur non authentifié, leur permet de déposer une clé valide dans un fichier journal du serveur et d’exécuter l’attaque.
Un nom d’utilisateur différent: invalide, puis valide
L’exploit de Rapid7 exige des conditions semblables, puisqu’il faut aussi connaître un nom d’utilisateur valide qui sera la victime. La différence principale avec l’exploit de Watchtowr est qu’il n’utilise pas le comportement vulnérable d’IPWorks SSH et n’exige pas de déposer une clé sur le serveur.
Il s’appuie plutôt sur la façon dont les noms d’utilisateur sont transmis pendant le processus d’authentification SSH. Le message initial envoyé par le client contient le nom d’utilisateur et la clé publique. À la réception de ce message avec un nom d’utilisateur invalide, le serveur SFTP vulnérable exécute la fonction Authenticate avec un user.ID vide, ce qui déclenche la seconde branche conditionnelle vulnérable.
Ce message initial sert normalement à vérifier si l’utilisateur peut bien s’authentifier avec la clé publique fournie. Ce test évite une vérification de signature inutilement coûteuse. Or, comme le premier message de Rapid7 déclenche l’état vulnérable (dans le second « if »), n’importe quelle clé publique fournie sera authentifiée et _keyAlreadyAuthenticated passera à True.
L’appel suivant à Authenticate authentifierait l’utilisateur avec une clé arbitraire, mais, comme mentionné plus haut, l’utilisateur indiqué est alors invalide. La technique employée par Rapid7 consiste à exploiter le fait que le second message d’authentification contient lui aussi un champ de nom d’utilisateur, sans qu’aucune vérification n’assure que ce nom corresponde à celui du premier message. Malgré des noms différents, le second message conserve la valeur enregistrée de _keyAlreadyAuthenticated. Résultat: l’authentification se fait sous ce nom d’utilisateur, avec n’importe quelle clé arbitraire « validée » lors du premier message en raison de l’état vulnérable.
Conclusion
Les preuves de concept des deux équipes sont relativement simples, mais la découverte de la vulnérabilité elle-même a été décrite comme complexe. Cette erreur exigeait une connaissance du protocole d’authentification SSH et de solides compétences en ingénierie inverse. La découverte du « zéro jour » dans IPWorks SSH devra aussi être corrigée, puisqu’elle touche probablement de nombreuses autres applications qui utilisent la bibliothèque.
Les erreurs de logique sont très difficiles à repérer par revue de code, car l’état d’une application est souvent difficile à suivre sans analyse dynamique. C’est encore plus difficile, voire impossible, pour les outils SAST, qui n’ont généralement aucune notion de ce qui constitue un état « invalide » ou « dangereux ».
On ne sait pas qui a découvert la vulnérabilité en premier, mais bravo à Watchtowr et à Rapid7: leur ingénierie inverse du correctif est précieuse pour la communauté, puisqu’ils partagent des indicateurs de compromission utiles aux équipes de défense.
MOVEit semble bel et bien dans la mire des acteurs malveillants, et les conséquences en sont graves. Si vous cherchez une solution de rechange, S-Filer Portal d’OKIOK est une solution MFT complète offrant le même ensemble de fonctionnalités que MOVEit.