Alerte sur la sécurité des modèles de machine learning avec la découverte d’une faille sévère dans le framework open source MLflow. Les attaquants pourraient s’en servir pour extraire des informations sensibles des serveurs, comme des clés SSH et des identifiants AWS. Les campagnes peuvent être exécutées à distance sans authentification, car MLflow n'implémente pas d'authentification par défaut et un nombre croissant de déploiements de 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 senior en sécurité senior pour la startup de cybersécurité Protect AI. « C'est assez brutal ». Il 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é.

Un framework très utilisé

É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 de machine learning, 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 le machine learning.

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é Dan McInerney.

Une faille classée 10 en CVSS

Répertoriée sous la référence CVE-2023-1177, la vulnérabilité découverte par Dan McInerney est classée 10 (critique) sur l'échelle CVSS. Le référentiel la décrit comme une inclusion de fichier en local et distante (LFI/RFI) via l'API, où un attaquant distant et non authentifié peut envoyer des requêtes spécifiquement conçues au endpoint de l'API qui forcerait 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 recense tous les utilisateurs disponibles et leurs répertoires personnels. 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 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 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.

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

Exiger une authentification pour accéder au endpoint de l'API empêcherait l'exploitation de cette faille, mais MLflow n'implémente aucun mécanisme d'authentification. Il est possible d’en ajouter une 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é Dan 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 système de stockage d'artefacts à distance ne contient de données sensibles », a-t-il ajouté.