Selon une étude de Verizon, l’exploitation des failles, y compris les attaques sur les équipements de bordure de réseau, a dépassé le phishing.
L’édition 2025 du Data Breach Investigation Report (DBIR) de Verizon est toujours riche en enseignement. Ainsi, le rapport constate que l’implication de tiers dans les failles de sécurité et l’exploitation des vulnérabilités sont devenues ont fortement progressé. Une analyse de 22 000 incidents de sécurité, dont 12 195 violations de données confirmées dans 139 pays, a montré que l’abus d’informations d’identification (22 %) et l’exploitation des vulnérabilités (20 %, contre 14,9 % en 2024)…
Il vous reste 94% de l’article à lireVous devez posséder un compte pour poursuivre la lecture
Vous avez déjà un compte?
La plateforme de développement pour les LLM, Ollama a colmaté une faille pouvant exposer les serveurs d’inférence de l’IA à une exécution de code à distance et à leur prise de contrôle par des pirates.
Les outils d’IA ne sont pas exempts de faille de sécurité. Preuve en est la découverte par un chercheur d’une vulnérabilité critique de type RCE (exécution de code à distance)dans Ollama. Cette plateforme vise à simplifier le processus de conditionnement et de déploiement des modèles d’IA. Selon, l’éditeur en sécurité Wiz, en raison d’un manque de support d’authentification, elle est vulnérable à des attaques. Alerté par Wiz, Ollama a réagi rapidement en publiant une mise à jour de son service- la version 0.1.34 – exempte de la vulnérabilité CVE-2024-37032.
La faille a été corrigée le 8 mai, mais Wiz a attendu six semaines avant de rendre publiques ses conclusions. Dans un billet de blog technique, le fournisseur explique que la vulnérabilité a été découverte lors de l’évaluation de la plateforme pour héberger un projet interne en IA.
Exécution de code à distance
Lors de cette expérimentation, les experts ont constaté qu’il était possible d’utiliser une brèche de traversée de répertoire pour écraser des fichiers sur le serveur. Un examen plus approfondi a révélé que le bug, qui découle d’une validation d’entrée insuffisante, pouvait être renforcée pour une exécution complète de code à distance. « Dans les installations Docker, il est assez simple de l’exploiter et d’obtenir une exécution de code à distance, car le serveur fonctionne avec les privilèges root », a expliqué Sagi Tzadik, le chercheur de Wiz qui a découvert la vulnérabilité. Il avertit qu’un grand nombre d’instances Ollama exécutant une version vulnérable étaient exposées à Internet depuis le 10 juin. Dans les installations Linux par défaut, le serveur API de la plateforme est lié à l’hôte local, ce qui réduit le risque d’attaque.
Mais, dans les déploiements basés sur Docker, le serveur API est exposé publiquement et il est donc vulnérable aux attaques. Une analyse a permis d’identifier plus de 1 000 instances de serveur Ollama exposées, hébergeant de nombreux modèles d’IA, y compris des modèles privés non répertoriés dans le référentiel public d’Ollama. La plateforme est utilisée pour l’inférence d’IA auto-hébergée et prend en charge de nombreux modèles. Elle sert également de backend pour des projets d’IA communs tels que OpenWebUI, entre autres.
Prise de contrôle de serveurs d’inférence d’IA auto-hébergés
Selon Wiz, la faille est similaire à celle existante sur d’autres serveurs d’inférence, dont TorchServe et Ray Anyscale, découvertes au cours des 12 derniers mois. « Ces vulnérabilités pourraient permettre à des attaquants de prendre le contrôle de serveurs d’inférence d’IA auto-hébergés, de voler ou de modifier des modèles et de compromettre des applications d’IA », a ajouté le fournisseur. « Le problème critique ne vient pas seulement des vulnérabilités elles-mêmes, mais du manque inhérent de support d’authentification dans ces nouveaux outils ». Cette absence de prise en charge signifie qu’un attaquant pourrait accéder au système pour voler ou modifier des modèles d’IA.
Pire encore, une attaque réussie pourrait permettre à un pirate d’« exécuter du code à distance en tant que fonction intégrée », a expliqué Wiz. Le potentiel de nuisance est considérable. « Un attaquant pourrait faire fuiter secrètement des modèles privés, espionner les messages des utilisateurs, modifier leurs réponses, demander une rançon pour l’ensemble du système et même prendre pied dans le réseau interne. Une fois exploitée, la machine est compromise », a déclaré Sagi Tzadik.
Le défaut d’authentification crée un risque potentiel
« Le manque de maturité de cette catégorie de technologie invite à la prudence et doit inciter à déployer des contrôles de sécurité supplémentaires au-delà de l’application du correctif d’Ollama », a recommandé Wiz. Les installations de la plateforme devraient être isolées de l’Internet. Le projet « en est encore à ses débuts et ne prend pas en charge des fonctions de sécurité essentielles, comme l’authentification », a mis en garde M. Tzadik de Wiz. « Même avec la dernière version, les attaquants peuvent obtenir les modèles d’IA utilisés sur le serveur Ollama et les exécuter en exploitant la capacité de calcul de la victime.
« Nous conseillons l’usage d’un reverse proxy pour ajouter une couche d’authentification au-dessus d’Ollama ou de connecter ce dernier directement à l’application d’IA », a suggéré l’expert. « Les entreprises adoptent rapidement un tas de nouveaux outils et d’infrastructures d’IA pour acquérir un avantage concurrentiel. Malheureusement, des fonctions de sécurité courantes, comme l’authentification, sont à la traîne dans le développement de ces plateformes », a mis en garde Wiz.
Adapté aux environnements cloud, Fluent Bit est un outil qui collecte et analyse les données de plusieurs sources. Or des chercheurs de Tenable ont découvert une faille critique dans cette solution open source très utilisée par les grands fournisseurs de cloud.
Petit vent d’effroi sur le cloud, après la découverte d’une vulnérabilité critique dans Fluent Bit par des experts de Tenable. Référencée CVE-2024-4323 et baptisée Linguistic Lumberjack, elle résulte de failles de codage dans le serveur HTTP intégré de l’outil open source et provoque une corruption de mémoire. Si elle n’est pas résolue, elle pourrait conduire à un déni de service, à la divulgation d’informations ou, dans le cas le plus grave, mais improbable, à des attaques par exécution de code à distance (RCE. Les versions 2.0.7 à 3.0.3 de Fluent Bit sont toutes vulnérables. Selon les développeurs du composant, la version 3.0.4 de Fluent Bit résout cette vulnérabilité et les menaces qui y sont associées.
Fluent Bit est un collecteur de données et un moteur open source qui peut analyser les données de logs provenant de diverses sources. Son évolutivité fait qu’il est adapté aux environnements cloud. Parmi les utilisateurs répertoriés figurent AWS, Microsoft Azure et Google Cloud, et selon Tenable, les trois hyperscalers s’appuient fortement sur cette technologie. Cisco, Splunk et d’autres s’appuient aussi sur cette technologie dans leurs applications de surveillance. D’autres développeurs utilisent également l’offre, qui a enregistré 3 milliards de téléchargements en 2022 et continue d’être déployé plus de 10 millions de fois par jour. Alertés le 30 avril par Tenable, les responsables du projet ont réagi en développant une version corrigée de la technologie, Fluent Bit 3.0.4, livrée le 21 mai. Dans un communiqué publié sur leur site web, les développeurs de Fluent Bit ont invité les fournisseurs de technologie à procéder à une mise à jour « immédiate pour garantir la stabilité et la sécurité des systèmes ».
Des fournisseurs assez réactifs pour le patch
Généralement, les vulnérabilités des systèmes basés sur le cloud sont corrigées rapidement et sans intervention de l’utilisateur. Contacté pour commentaires, un des fournisseurs a répondu qu’il n’avait pas été touché par le problème et a critiqué la recherche de Tenable, la jugeant un peu sensationnaliste. D’autres acteurs IT qui utilisent l’outil de surveillance des journaux ont la vulnérabilité en main.
CrowdStrike, par exemple, a déclaré avoir mis à jour son environnement avec la version corrigée de Fluent Bit, et qu’il n’y avait pas d’impact direct sur les clients. Cependant, l’entreprise a invité les « clients utilisant le package LogScale Kubernetes Logging de redéployer et de mettre à jour vers la version corrigée de Fluent Bit immédiatement ». Elle recommande aussi aux clients qui utilisent leurs propres instances Fluent Bit de vérifier leurs versions et d’appliquer les mises à jour nécessaires pour atténuer tout risque potentiel. Par contre, aucun fournisseur de services d’entreprise pour Fluent Bit (Calyptia, Fluentd et Clear Code) contacté pour savoir quels conseils ils avaient à donner à leurs clients, n’ont répondu dans l’immédiat.
Un apprentissage pour mieux sécuriser le projet open source
Dans un billet de blog technique, les experts de Tenable ont expliqué comment la vulnérabilité avait été découverte en enquêtant sur une faille distincte (non encore divulguée) dans un service cloud (non mentionné). Pendant leur analyse, ils ont réalisé qu’ils pouvaient accéder à divers indicateurs et points de terminaison de journalisation internes au service cloud lui-même, y compris un certain nombre d’instances de Fluent Bit. C’est en procédant à des tests supplémentaires de la solution dans un environnement isolé qu’ils ont découvert le problème de corruption de mémoire. Plus précisément, le serveur HTTP intégré dans Fluent Bit était vulnérable, car il ne parvenait pas à assainir les traces des requêtes. Or, par ce mécanisme, il devenait possible pour des attaquants de passer des entrées inattendues ou invalides afin de planter un système ou d’utiliser la corruption de mémoire pour exposer des informations secrètes. Une attaque par exécution de code à distance aurait également des chances d’aboutir, du moins en théorie.
Les experts soulignent qu’une telle attaque dépendrait fortement de l’architecture, du système d’exploitation hôte et d’autres facteurs environnementaux et qu’il serait difficile de la mener à bien. Les développeurs de l’outil open source considèrent cet épisode comme un apprentissage. « Même si personne ne se réjouit de recevoir un avis de sécurité critique juste avant d’aller déjeuner, ce problème nous a tout de même donné un coup de pouce utile pour évaluer nos pratiques de prévention des vulnérabilités au sein du projet Fluent Bit », ont-ils écrit. « Par exemple, cela nous a rappelé que certaines mesures que nous avons déjà mises en place, comme notre participation au programme OSS-Fuzz de Google, se justifient entièrement. Cela nous a également donné l’occasion de renforcer d’autres aspects de notre réponse aux incidents et de nous assurer qu’ils sont aussi efficaces que possible pour l’avenir de Fluent Bit ».