MLflow, un framework open source utilisé par de nombreuses entreprises pour gérer leurs tests d'apprentissage machine et enregistrer les résultats, est touchée par une faille critique. Celle-ci ouvre la voie à des attaquants pour extraire des informations sensibles des serveurs, comme des clés SSH et des identifiants AWS. Les attaques peuvent être exécutées à distance sans authentification, car MLflow n'implémente pas d'authentification par défaut sachant qu'un nombre croissant de déploiements MLflow sont directement exposés à lnternet. « En clair, chaque entreprise qui utilise cet outil risque de perdre ses modèles d'IA, d'avoir un serveur interne compromis et d'avoir son compte AWS compromis », a déclaré Dan McInerney, ingénieur de la sécurité senior pour la startup de cybersécurité Protect AI. « C'est assez brutal ». M. McInerney a découvert la vulnérabilité et l'a signalée au projet MLflow en privé. Elle a été corrigée dans la version 2.2.1 du framework publiée il y a trois semaines, mais les notes de version ne mentionnent aucun correctif de sécurité.

Inclusion de fichiers locaux et distants via une attaque Path traversal

Écrit en Python, MLflow automatise les workflows d'apprentissage machine. Du fait de ses nombreux composants, les utilisateurs peuvent déployer des modèles à partir de diverses bibliothèques d'apprentissage machine, gérer leur cycle de vie, y compris la version du modèle, les transitions d'étape et les annotations, suivre les expériences pour enregistrer et comparer les paramètres et les résultats, et même empaqueter le code d'apprentissage machine sous une forme reproductible pour le partager avec d'autres scientifiques des données. MLflow peut être contrôlé via une API REST et une interface en ligne de commande. Toutes ces capacités font de ce framework un outil précieux pour toute entreprise qui expérimente l'apprentissage machine. Les analyses effectuées à l'aide du moteur de recherche Shodan confirment ce constat : au cours des deux dernières années, les instances MLflow exposées publiquement n’ont cessé d’augmenter, le nombre actuel s'élevant à plus de 800. Cependant, on peut supposer que de nombreux autres déploiements de MLflow existent au sein de réseaux internes et pourraient être atteints par des attaquants qui gagneraient un accès à ces réseaux. « Plusieurs entreprises du Fortune 500 que nous avons contactées nous ont toutes confirmé qu’elles utilisaient MLflow en interne pour leur flux de travail d'ingénierie de l'IA », a encore déclaré M. McInerney.

Répertoriée sous la référence CVE-2023-1177, la vulnérabilité critique découverte par Dan McInerney a un score CVSS remarquable de 10. Selon ce référentiel, celle-ci - de type inclusion de fichiers locaux (LFI) ou distants (RFI) donne la possibilité à un attaquant distant et non authentifié d'envoyer des requêtes spécifiquement conçues au point d’extrémité de l'API forçant MLflow à exposer le contenu de n'importe quel fichier lisible sur le serveur. Par exemple, l'attaquant peut inclure JSON dans une requête où le paramètre source est un fichier de son choix sur le serveur et l'application le renverra. L'un de ces fichiers peut être les clés ssh, généralement stockées dans le répertoire .ssh à l'intérieur du répertoire personnel de l'utilisateur local. Cependant, la connaissance préalable du répertoire personnel de l'utilisateur n'est pas une condition à l'exploitation, car l'attaquant peut d'abord lire le fichier /etc/passwd, disponible sur tous les systèmes Linux, qui répertorie tous les utilisateurs disponibles et leurs répertoires personnels.

Des déploiements non sécurisés faute d'authentification par défaut

Aucun des autres paramètres envoyés dans le cadre de la requête malveillante n'a besoin d'exister et peut être arbitraire. La vulnérabilité est d'autant plus grave que la plupart des entreprises configurent leurs instances MLflow pour qu'elles utilisent Amazon AWS S3 afin de stocker leurs modèles et autres données sensibles. Selon l’analyse de la configuration des instances MLflow accessibles au public effectuée par Protect AI, sept configurations sur dix utilisaient AWS S3. Cela signifie que les attaquants peuvent définir le paramètre source de leur requête JSON comme étant l'URL s3:// du bucket utilisé par l'instance pour voler des modèles à distance. Cela signifie également que les identifiants AWS sont probablement stockés localement sur le serveur MLflow afin que le framework puisse accéder aux buckets S3, et ces identifiants sont généralement stockés dans un dossier appelé ~/.aws/credentials dans le répertoire personnel de l'utilisateur. L'exposition des informations d'identification AWS peut constituer une violation grave, car, en fonction de la politique IAM, elle peut donner aux attaquants des capacités de mouvement latéral dans l'infrastructure AWS d'une entreprise.

Exiger une authentification pour accéder au point d’extrémité de l'API empêcherait l'exploitation de cette faille, mais MLflow n'implémente aucun mécanisme d'authentification. Il est possible d’ajouter une authentification de base avec un nom d'utilisateur et un mot de passe statiques en déployant un serveur proxy comme nginx devant le serveur MLflow et en forçant ainsi l'authentification. Malheureusement, presque aucune des instances exposées publiquement n'utilise une telle configuration. « Il est difficile de dire que ce mode de déploiement de l’outil est sûr, mais à tout le moins, le déploiement le plus sûr de MLflow tel qu'il est actuellement est de le garder sur un réseau interne, dans un segment de réseau séparé de tous les utilisateurs, sauf ceux qui ont besoin de l'utiliser, et de le placer derrière un proxy nginx avec une authentification de base », a expliqué M. McInerney. « Cela n'empêche pas un utilisateur ayant accès au serveur de télécharger les modèles et artefacts d'autres utilisateurs, mais cela limite au moins l'exposition. L'exposition sur un serveur public orienté vers lnternet suppose qu'absolument rien de ce qui est stocké sur le serveur ou sur le serveur de stockage d'artefacts à distance ne contient de données sensibles », a-t-il ajouté.