Plus d'un millier de serveurs Ollama exposés sur Internet

L’essor des LLM à grande échelle n’est pas sans risque. Dans une dernière étude, l’entité cybersécurité de Cisco, Talos, a découvert 1 139 serveurs Ollama non authentifiés, dont 214 hébergeant activement des modèles vulnérables. « Ces conclusions mettent en évidence une vulnérabilité critique et systémique dans le déploiement de l'infrastructure LLM », alertent les chercheurs en sécurité de l'équipement américain qui se sont intéressés aux déploiements d'outils d'hébergement LLM populaires : Ollama, vLLM, llama.cpp, LM Studio, GPT4All et LangChain.

Pour leur recherche, ils se sont appuyés sur l'API du moteur de scan Shodan intégrée à un outil maison basé sur Python pour détecter les environnements LLM non sécurisés. Les métadonnées (adresses IP, les ports ouverts, les en-têtes HTTP et les bannières de service) des hôtes ont été analysées, et pour minimiser les faux positifs, un filtrage supplémentaire basée sur le contenu des bannières a été réalisé. « En combinant le filtrage basé sur les ports avec l'analyse des bannières et la validation des mots-clés, notre système vise à trouver un équilibre entre la précision et la couverture dans l'identification des serveurs LLM réellement exposés, donnant ainsi une évaluation précise et responsable des failles », explique Talos.

Des risques d’attaques par extraction et d’empoisonnement de modèles

Le fournisseur indique avoir découvert la plus grande partie des instances Ollama vulnérables dans la phase initiale de son analyse, avec plus de 1 000 détectées dans les 10 premières minutes. « Cela souligne la nature généralisée et largement non atténuée de cette exposition », fait savoir Talos. La majorité des serveurs exposés étaient hébergés aux États-Unis (36,6 %), en Chine (22,5 %) et en Allemagne (8,9 %). Suivent notamment Hong Kong (6,8 %), la France (2,6 %), Singapour (1,9 %), le Japon (1,8 %), et le Brésil (1,5 %). Concernant les 214 instances Ollama vulnérables (18,8 % du total de celles exposées sur l’Internet public), Mistral et LLaMA font partie des déploiements les plus fréquents. « Les 80 % des serveurs détectés restants, bien qu'accessibles via des interfaces non authentifiées, ne comportaient aucun modèle instancié », précise Talos. « Ces serveurs dormants, bien qu'ils ne fournissent pas activement de réponses de modèles, restent vulnérables à l'exploitation via des téléchargements de modèles non autorisés ou la manipulation de configurations. Il est important de noter que leurs interfaces exposées pourraient toujours être utilisées dans le cadre d'attaques impliquant l'épuisement des ressources, le déni de service ou le mouvement latéral ».

Le rapport souligne par ailleurs trois conséquences liées à ces exploitations : attaques par extraction de modèle (les pirates peuvent reconstruire les paramètres d'un modèle en interrogeant de manière répétée un serveur exposé), jailbreaking et utilisation abusive de contenu (les LLM tels que GPT-4, LLaMA et Mistral peuvent être manipulés pour générer du contenu restreint, notamment des informations erronées, des codes malveillants ou des résultats nuisibles), et injection par porte dérobée et empoisonnement de modèle (les adversaires pourraient exploiter des points de terminaison de modèle non sécurisés pour introduire des charges utiles malveillantes ou charger à distance des modèles non fiables).

Des mesures préventives à considérer

« La vulnérabilité généralisée des serveurs Ollama non authentifiés souligne le besoin urgent de stratégies de remédiation standardisées, pratiques et multicouches visant à sécuriser l'infrastructure LLM », prévient le fournisseur. Pour rehausser le niveau de sécurité, plusieurs recommandations et bonnes pratiques sont proposées.

• Application de l'authentification et le contrôle d'accès (par clé API ou OAuth2) ;
• Segmentation réseau (groupes de sécurité, pare-feu et sous-réseaux privés pour isoler les services LLM) ;
• Limitation du débit et détection des abus (intégrer des passerelles API comme Kong ou Amazon API Gateway pour appliquer des limites et surveiller les comportements anormaux) ;
• Désactivation des ports par défaut et masquage des bannières de service (modifier les configurations par défaut pour supprimer les métadonnées identifiables) ;
• Déploiement de pipelines sécurisés pour le téléchargement et l'exécution de modèles (utilisation de liste blanche de contenu, signatures numériques et vérification rigoureuse des modèles téléchargés) ;
• Surveillance continue et audits automatisés de l'exposition aux risques (recours à des outils automatisés comme naabu de Project Discovery ou écriture de scripts de surveillance Shodan personnalisés).

« Les futurs travaux devraient explorer l'intégration de plusieurs sources de données, notamment Censys, ZoomEye et des scanners personnalisés basés sur Nmap, afin d'améliorer la précision de la détection et de réduire la dépendance à une seule plateforme », promet par ailleurs Talos. « La détection des ports non standard et l'analyse des prompts malveillants sont des pistes prometteuses pour affiner la capacité du système à détecter et à caractériser les déploiements LLM cachés ou évasifs dans des environnements réels ».