L’IA auto-hébergée promet un contrôle accru des workloads sensibles. Un nouveau scan réalisé à l’échelle d’Internet a révélé que des dizaines de milliers de ces systèmes étaient accessibles depuis l’Internet public.
Les chercheurs ont identifié 36 769 endpoints d’IA auto-hébergés répartis entre serveurs de modèles, outils de workflow et magasins vectoriels, selon une étude publiée le 10 septembre par Mysterium VPN. Seuls 741 d’entre eux, soit 2,02 %, ont renvoyé un défi d’authentification HTTP.
Cela ne signifie pas que les 98 % restants ne possédaient pas de page de connexion applicative. Un service peut renvoyer le code HTTP 200 tout en affichant sa propre page de connexion. La recherche de Mysterium VPN a montré que seule une petite fraction des services présentait la passerelle d’authentification au niveau réseau ou HTTP que sa méthodologie pouvait détecter.
L’exposition s’étend au-delà des serveurs de modèles
Open WebUI représentait 18 529 endpoints accessibles, suivi de 6 935 serveurs Ollama et de 4 880 endpoints vLLM. Les chercheurs ont également identifié 5 223 endpoints associés à des plateformes de workflow et de création d’agents d’IA, ainsi que 920 endpoints de magasins vectoriels, dont le nombre réel est probablement supérieur selon eux.
Les plateformes de workflow méritent une attention particulière, car elles peuvent connecter les modèles d’IA à des API, des bases de données, des services cloud, des webhooks et des identifiants. Ces connexions rendent également la confiance et les contrôles d’accès pour les agents d’IA importants au-delà du modèle lui-même.
Ollama s’est distingué, car 6 935 serveurs ont renvoyé sa réponse racine caractéristique à une requête anonyme. La documentation d’Ollama confirme qu’aucune authentification n’est requise pour accéder localement à son API.
Les infrastructures d’IA publiques font également l’objet d’attaques actives. Des attaques récentes contre LiteLLM et les serveurs MCP ont impliqué le vol d’identifiants, l’exécution de commandes, le cryptominage et des tentatives d’accès à des ressources connectées aux services d’IA. Lors d’un déploiement instrumenté distinct de 72 heures, des chercheurs de CyberDesserts ont observé des activités de reconnaissance propres à l’IA ainsi que des recherches d’identifiants et de fichiers de configuration, sans toutefois établir l’existence d’une exploitation généralisée des modèles d’IA eux-mêmes.
Verrouiller la surface d’attaque de l’IA
Les organisations doivent d’abord déterminer quels services d’IA sont accessibles depuis l’extérieur et vérifier si cette exposition est intentionnelle. Les contrôles doivent ensuite couvrir l’accès réseau, les identifiants, l’hygiène logicielle, la supervision et la réponse aux incidents.
- Recenser les services d’IA exposés au public. Incluez les serveurs de modèles, les interfaces web, les plateformes d’agents et les bases de données vectorielles dans la gestion de la surface d’attaque et les scans d’exposition externe.
- Restreindre les accès réseau inutiles.Gardez les services privés lorsque c’est possible, utilisez des règles de pare-feu ou des listes d’autorisation d’adresses IP, et protégez les accès distants nécessaires au moyen de proxys authentifiés, d’un VPN ou de contrôles zero trust.
- Appliquer les correctifs et renforcer les déploiements.Maintenez à jour les logiciels d’IA et leurs composants auxiliaires. CVE-2024-37032, connue sous le nom de Probllama, concernait les versions d’Ollama antérieures à la 0.1.34 et a été corrigée dans la version 0.1.34. La CISA a également ajouté les failles d’infrastructure d’IA exploitées activement à son catalogue des vulnérabilités connues comme exploitées.
- Protéger et renouveler les identifiants.Examinez les systèmes de workflow exposés à la recherche de clés d’API, de jetons cloud, d’identifiants de bases de données et de secrets de webhooks, puis renouvelez les secrets potentiellement exposés et appliquez le principe du moindre privilège.
- Limiter les abus et les déplacements latéraux.Appliquez des limites de débit, segmentez l’infrastructure d’IA des systèmes sensibles et restreignez les connexions sortantes inutiles.
- Surveiller les activités suspectes.Examinez les journaux des proxys, des pare-feu, des flux cloud et des applications à la recherche d’adresses IP sources inhabituelles, de volumes de requêtes anormaux, d’activités d’inférence inattendues et d’autres anomalies d’API.
- Tester les plans de réponse aux incidents liés à l’exposition de l’IA.Répétez les procédures de confinement, de conservation des journaux, de renouvellement des identifiants, d’examen des accès historiques et d’investigation des systèmes connectés.
Ces mesures sont conformes à la NIST SP 800-228, qui recense les risques et les contrôles liés aux API à travers les étapes de développement et d’exécution. Les 36 769 endpoints ne correspondent pas à 36 769 compromissions confirmées ; ils montrent l’ampleur de l’infrastructure d’IA auto-hébergée visible au-delà des environnements privés.
Réduire cette exposition, limiter les privilèges et superviser les accès peut empêcher qu’un service accessible ne se transforme en incident plus vaste.
À lire aussi : une récente vulnérabilité de NemoClaw a montré comment un backend Ollama exposé pouvait permettre à un site web malveillant de modifier le modèle utilisé par un agent d’IA, soulignant pourquoi les serveurs d’inférence locaux doivent être considérés comme une infrastructure privilégiée.