Une faille SSRF sur MLflow livre les secrets du cloud
MLflow est un outil très répandu pour gérer des modèles d'IA. Une faille du type SSRF y permet à un attaquant de faire parler le serveur à sa place, et de repartir avec des identifiants et des clés rangés dans le cloud. La faille est corrigée, mais le schéma, lui, se retrouve dans énormément d'applications montées vite.
Une SSRF, en français
Votre application propose un champ où l'on colle une adresse : importer une image depuis une URL, récupérer un flux, tester un lien. Votre serveur va chercher cette adresse et rapporte le contenu. Jusque-là, tout va bien.
Le problème, c'est que votre serveur voit des choses que vos visiteurs ne voient pas : les autres machines de votre réseau, vos bases de données, et surtout — chez tous les hébergeurs cloud — une adresse interne spéciale qui donne les identifiants du serveur. Un attaquant colle cette adresse dans votre champ, et c'est votre propre serveur qui va chercher vos secrets et les lui rapporte poliment.
Pourquoi ça vous concerne
C'est exactement le genre de trou que l'IA laisse quand elle génère du code. Demandez « ajoute une fonction pour importer une image depuis une URL » : vous obtiendrez du code qui marche, tout de suite, et qui ne vérifie rien du tout sur l'adresse demandée.
Et la conséquence n'est jamais petite. Ce qui fuit, ce sont les clés qui ouvrent votre stockage, votre base, vos sauvegardes. Une seule faille de ce type suffit à donner accès à l'ensemble.
Ce que vous pouvez vérifier vous-même
- Cherchez tous les endroits où votre serveur va chercher une adresse. Import par URL, aperçu de lien, webhook, génération de PDF, récupération d'avatar.
- Interdisez les adresses internes. Tout ce qui commence par 127., 10., 192.168., 172.16 à 172.31, et l'adresse de métadonnées de votre hébergeur, doit être refusé.
- Autorisez plutôt que d'interdire. Une liste de domaines permis tient mieux dans le temps qu'une liste d'interdits, qu'on contourne toujours.
- Regardez ce que votre serveur a le droit de faire. S'il n'a besoin que d'un dossier de stockage, il ne devrait pas détenir une clé qui ouvre tout le compte.
Tout endroit où votre app va chercher une ressource externe, et si un secret cloud traîne à portée de ce serveur.