Développée initialement par Databricks en 2018, MLflow est une plateforme open source utilisée par de nombreuses organisations, notamment pour les tests de ML. Après qu'une vulnérabilité critique du framework ait été signalée, celle-ci a été corrigée dans la version 2.2.1 publiée il y a 3 semaines, on ne peut que conseiller aux entreprises d'effectuer une mise à jour vers cette dernière version. MLflow est un outil très populaire (plus de 13 millions de téléchargements mensuels) écrit en Python, utilisé pour gérer le cycle de vie complet de l'apprentissage automatique, conçu pour fonctionner avec n'importe quelle bibliothèque et algorithme d'apprentissage machine et qui peut être utilisé dans l'infrastructure ML existante d'une organisation. Le framework compte quatre composants principaux:
  • MLflow Tracking : permet d'enregistrer et de consulter des expériences, y compris du code, des données, des configurations et des résultats;
  • MLflow Projects : fournit un format pour empaqueter le code de science des données de manière réutilisable et reproductible. Il définit des conventions pour spécifier les dépendances et exécuter le code;
  • MLflow Models : fournit un format pour empaqueter les modèles d'apprentissage machine qui peuvent être utilisés dans une variété d'outils en aval, tels que la desserte en temps réel via une API REST ou l'inférence par lots sur Apache Spark;
  • MLflow Model Registry: Ce composant fournit un magasin de modèles centralisé, un ensemble d'API et une interface utilisateur pour gérer de manière collaborative le cycle de vie complet d'un modèle MLflow.
Le framework peut être contrôlé via une API REST et une interface de ligne de commande. Toutes ces fonctionnalités font de ce framework un outil précieux pour toute organisation expérimentant l’apprentissage automatique. Les analyses utilisant le moteur de recherche Shodan révèlent une augmentation constante des instances MLflow exposées publiquement au cours des deux dernières années, actuellement plus de 800. Après que Dan McInerney, ingénieur en sécurité senior de la start-up de cybersécurité Protect AI lui ait signalé une faille critique, la plateforme a reçu un correctif dans sa version 2.2.1.Sans celui-ci, les attaquants peuvent extraire des informations sensibles des serveurs tels que des clés SSH et des informations d’identification AWS. Ces attaques peuvent être exécutées à distance sans authentification car MLflow n’implémente pas l’authentification par défaut et un nombre croissant de déploiements MLflow sont directement exposés à Internet. Dan McInerney explique : « Fondamentalement, chaque organisation qui utilise cet outil risque de perdre ses modèles d’IA, de voir un serveur interne compromis et son compte AWS compromis. C’est assez brutal ».

Une faille classée 10 (critique) sur l’échelle CVSS

On peut penser que MLflow est déployé au sein de nombreux réseaux internes, ces déploiements pourraient être atteints par des attaquants qui accèdent à ces réseaux. Ainsi, selon Dan McInerney, les entreprises du Fortune 500 qu'il a contactées lui ont toutes confirmé utiliser MLflow en interne pour leur flux de travail d’ingénierie de l’IA. La vulnérabilité CVE-2023-1177, trouvée par Dan McInerney, est classée 10 sur l’échelle CVSS. Combinée d’inclusion de fichiers locaux et de fichiers distants, elle permet à un attaquant de se connecter à distance au serveur ou aux ressources cloud et d’exécuter du code arbitraire avec les autorisations des informations d’identification trouvées, pouvant conduire à une prise de contrôle complète du système ou du fournisseur de cloud. Dan McInerney l’a signalée au projet MLflow en privé, les mainteneurs ont très vite réagi et livré des correctifs, les versions de MLflow postérieures à la version 2.1.1 ne sont plus vulnérables. Selon Protect AI, cette vulnérabilité est aggravée du fait que la plupart des organisations configurent leurs instances MLflow pour utiliser Amazon AWS S3 afin de stocker leurs modèles et autres données sensibles. Selon l’examen que la société a effectué sur la configuration des instances MLflow accessibles au public, sept sur dix utilisaient AWS S3. Cela signifie que les attaquants peuvent définir le paramètre source dans leur requête JSON comme étant l’URL s3:// du compartiment utilisé par l’instance pour voler des modèles à distance. Cela signifie également que les informations d’identification AWS sont probablement stockées localement sur le serveur MLflow afin que le framework puisse accéder aux compartiments S3, et ces informations d’identification sont généralement stockées dans un dossier appelé ~/.aws/credentials sous le répertoire de base de l’utilisateur. L’exposition des informations d’identification AWS peut constituer une violation grave car, selon la stratégie IAM, elle peut donner aux attaquants des capacités de déplacement latéral dans l’infrastructure AWS d’une organisation.

Eliminer cette faille grâce à l'authentification

Exiger une authentification pour accéder au point de terminaison de l’API empêcherait l’exploitation de cette faille, mais MLflow n’implémente aucun mécanisme d’authentification. L’authentification de base avec un nom d’utilisateur et un mot de passe statiques pourrait être ajoutée en déployant un serveur proxy comme nginx devant le serveur MLflow mais, malheureusement, presque aucune des instances exposées publiquement n’utilise une telle configuration. Dan McInerney déclare : « Je peux difficilement appeler cela un déploiement sûr de l’outil, 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 qui est partitionné loin de tous les utilisateurs sauf ceux qui ont besoin de l’utiliser, et mis derrière un proxy nginx avec authentification de base. Cela n’empêche toujours pas tout utilisateur ayant accès au serveur de télécharger les modèles et artefacts d’autres utilisateurs, mais à tout le moins, cela limite l’exposition. L’exposer sur un serveur Internet public suppose qu’absolument rien de ce qui est stocké sur le serveur ou le serveur distant du magasin d’artefacts ne contient de données sensibles ». Références : blog de Lucian Constantin CSO online Plus d'informations sur la démarche de Dan McInerney : Hacking AI : prise de contrôle du système et du cloud via MLflow Exploit

Nos articles remonteront en priorité dans « À la une » de Google.