L'AI non découvert : 175 000 cas d'Olama exposés sur Internet et le boom du LLMjacking

La possibilité d'exécuter de grands modèles de langage (LLM) sur votre propre ordinateur ou dans une petite machine à cloud a été l'une des grandes avancées qui a démocratisé l'IA. Mais une nouvelle enquête conjointe de SentinelOne SentinelLABS et Censys a suscité une alarme : cette démocratisation a également créé une énorme « couche d'infrastructure informatique non gérée et accessible au public » pour l'IA. L'étude détecte approximativement 175 000 cas uniques d'Olama Il s'agit d'un projet qui a été mis en place par le biais d'un réseau d'échange d'informations et d'informations.

Le mécanisme technique qui explique une grande partie du problème est étonnamment simple. Olama, un framework open source qui facilite le téléchargement, l'exécution et la gestion des modèles de langage dans Windows, macOS et Linux, est configuré par défaut pour écouter dans la direction locale 127.0.0.1: 11434. Cependant, avec un minimum de changement - par exemple, lier le service à 0.0.0.0 ou une interface publique - la même instance est accessible depuis Internet. Ce geste futile est tout ce qui a besoin à la fois des administrateurs dissidents et des attaquants pour transformer un service conçu pour une utilisation locale en point d'accès public.

L'exposition n'est pas homogène : selon le rapport, la plupart de ces cas sont situés en Chine (un peu plus de 30%), mais il y a aussi une empreinte significative aux États-Unis, en Allemagne, en France, en Corée du Sud, en Inde, en Russie, à Singapour, au Brésil et au Royaume-Uni. En plus de la simple présence de paramètres exposés, l'étude met en évidence un facteur qui augmente considérablement le risque : près de la moitié des hôtes observés ont signalé dans leurs API les capacités d'appel d'outils ou d'invocation de fonctions. Dans la pratique, cela permet au modèle d'interagir avec des API externes, d'exécuter du code ou d'accéder à des systèmes supplémentaires, ce qui fait d'un générateur de texte un acteur capable d'effectuer des actions avec un impact réel.

Ce saut - de la production de texte à l'exécution des opérations - transforme complètement le modèle de menace. Une API qui renvoie seulement du texte peut produire des informations nuisibles, mais ce n'est pas la même chose qu'une API qui, si elle est dupe ou abusée, peut faire des appels à des services internes, manipuler des bases de données ou lancer des scripts. Lorsque ces capacités sont combinées avec une authentification insuffisante et une exposition au réseau, le résultat selon les chercheurs est une des plus grandes sources de risque dans l'écosystème.

L'analyse a également relevé des cas qui étendent les capacités au-delà du texte, y compris le raisonnement et la vision avancés, et trouvé des cas précis - 201 hôtes, selon le rapport - avec des modèles rapides non censurés qui suppriment les garanties de sécurité. Cette combinaison de fonctionnalités puissantes et de l'absence de contrôles augmente la probabilité d'attaques telles que le "Jacking LLM", où les ressources d'une instance LLM sont enlevées au profit d'un tiers alors que le propriétaire en paie le coût.

Le danger n'est pas purement théorique. Un rapport complémentaire de Pillar Security documente une campagne appelée Opération Bizarre Bazaar, dans laquelle les acteurs malveillants scannent systématiquement l'Internet à la recherche d'instances exposées d'Olama, vLLM et APis compatibles avec OpenAI qui n'ont pas d'authentification, valident la qualité de la réponse et ensuite l'accès au marché. L'opération décrite par Pilier comprend un processus complet de reconnaissance, validation et revente de l'accès via une passerelle unifiée, ce qui confirme qu'il y a déjà une économie criminelle autour de ces infrastructures. Cette enquête retrace l'opération à un acteur connu sous le nom de Hecker (alias Sakuya / LiveGamer101).

La nature décentralisée de cet écosystème - avec des points de mise en œuvre répartis entre les fournisseurs de cloud et les réseaux résidentiels - crée également des lacunes en matière de gouvernance. Bon nombre de ces organismes sont mis en œuvre en dehors du contrôle du matériel de sécurité de l'entreprise, ce qui rend difficile la mise en oeuvre des politiques conventionnelles. Les chercheurs insistent sur le fait qu'il faut commencer à distinguer entre les dispositifs gérés par le nuage et les dispositifs à l'extrémité (à l'extrémité) ou les appareils ménagers et adopter des contrôles spécifiques au contexte.

Que peuvent faire les gestionnaires et les utilisateurs pour réduire les risques? Le plus basique, et en même temps plus efficace, est de traiter n'importe quel paramètre de LLM exposé comme s'il s'agissait d'un service public de plus: imposer une authentification robuste, le chiffrement, l'enregistrement d'événements et les contrôles réseau. Forcer le processus de lier uniquement à localhost à moins qu'il y ait une raison justifiée de l'ouvrir, appliquer des règles de pare-feu pour limiter qui peut se connecter, et activer les mécanismes d'authentification (clés, mTLS, jetons) sont des mesures immédiates. En même temps, la segmentation du réseau, la surveillance continue et l'application de limites de taux aident à détecter et à atténuer les abus. Pour les organisations qui constituent des « appels d'outils », il convient d'examiner et de limiter les capacités disponibles dans le modèle et de vérifier en profondeur tout pont permettant l'exécution de codes ou l'accès à des systèmes critiques.

Si vous cherchez des références et des lectures à approfondir, l'analyse technique de Sentinel L'un d'eux est disponible sur votre blog et fournit plus de détails sur la méthodologie et les résultats: SentinelOne SentinelLABS. Le rapport sur l'exploitation commerciale du détournement de LLM se trouve dans la publication de Pilier Security: Opération Bizarre Bazaar - Sécurité du pilier. Pour comprendre le logiciel concerné, la page officielle d'Olama et son dépôt fournissent des informations sur le projet et sa configuration: Olama et GitHub - Olama. Il est également utile de se rappeler les bonnes pratiques générales de sécurité pour les IPA, recueillies dans le cadre d'initiatives comme le PAOAO : Sécurité de l'API OWASP et cadres de référence des risques pour l'analyse d'impact, tels que ceux publiés par le NIST: NIST - AI.

L'équilibre final est clair: les outils IA open source ont ouvert d'énormes opportunités, mais ils ont apporté avec eux une responsabilité. Si les modèles peuvent traduire des instructions en actions, ils doivent être soumis aux mêmes contrôles que tout autre service bénéficiant de privilèges réseau. Ignorer cette réalité laisse ouverte la fraude, les abus et la construction de marchés illicites qui monétisent l'exposition. La leçon pour les gestionnaires de TI, les équipes de sécurité et les utilisateurs finals est que la flexibilité technique doit s'accompagner dès le départ de politiques, de suivi et de conception sûre.