ShadowRay est une exposition de l’infrastructure du framework d’intelligence artificielle (IA) Ray. Cette exposition fait actuellement l’objet d’attaques, mais Ray conteste qu’il s’agisse d’une vulnérabilité et n’a pas l’intention de la corriger. Le différend entre les développeurs de Ray et les chercheurs en sécurité met en lumière des hypothèses cachées et livre des enseignements pour la sécurité de l’IA, les actifs exposés sur Internet et l’analyse des vulnérabilités, à travers l’étude de ShadowRay.
ShadowRay expliqué
La plateforme de calcul pour l’IA Anyscale a développé le framework d’IA open source Ray, principalement utilisé pour gérer les charges de travail liées à l’IA. L’outil affiche une liste de clients comprenant DoorDash, LinkedIn, Netflix, OpenAI, Uber et bien d’autres.
Les chercheurs en sécurité d’Oligo Security ont découvert la CVE-2023-48022, baptisée ShadowRay, qui révèle que Ray n’applique pas d’autorisation dans l’API Jobs. Cette exposition permet à tout utilisateur non authentifié disposant d’un accès réseau au tableau de bord de lancer des tâches, voire d’exécuter du code arbitraire sur l’hôte.
Les chercheurs estiment que cette vulnérabilité devrait obtenir une note de 9,8 (sur 10) selon le Common Vulnerability Scoring System (CVSS), mais Anyscale nie qu’il s’agisse d’une vulnérabilité. L’entreprise maintient au contraire que Ray est uniquement destiné à être utilisé dans un environnement contrôlé et que l’absence d’autorisation est une fonctionnalité prévue.
Les dégâts causés par ShadowRay
Malheureusement, un grand nombre de clients ne semblent pas comprendre qu’Anyscale part du principe que ces environnements ne seront pas exposés à Internet. Oligo a déjà détecté des centaines de serveurs exposés que des attaquants avaient déjà compromis, et a classé les types de compromission comme suit :
- Clés SSH consultées : Permettent aux attaquants de se connecter à d’autres machines virtuelles de l’environnement d’hébergement, d’y maintenir leur présence et de détourner la capacité de calcul.
- Accès excessif : Donne aux attaquants accès aux environnements cloud via les privilèges root de Ray ou aux clusters Kubernetes, en raison des autorisations d’administrateur d’API intégrées.
- Charges de travail d’IA compromises : Compromettent l’intégrité des résultats des modèles d’IA, permettent le vol de modèles et peuvent contaminer l’entraînement des modèles afin d’altérer les résultats futurs.
- Calcul détourné : Réaffecte la puissance de calcul coûteuse de l’IA aux besoins des attaquants, principalement au cryptojacking, qui consiste à miner des cryptomonnaies sur des ressources volées.
- Identifiants volés : Exposent d’autres ressources à une compromission par l’intermédiaire de mots de passe exposés pour OpenAI, Slack, Stripe, des bases de données internes, des bases de données d’IA et bien plus encore.
- Jetons détournés : Permettent aux attaquants de voler des fonds (Stripe), de mener des attaques contre la chaîne d’approvisionnement de l’IA (OpenAI, Hugging Face, etc.) ou d’intercepter les communications internes (Slack).
Si vous n’avez pas vérifié que les ressources Ray internes sont protégées par des contrôles de sécurité réseau rigoureux, exécutez les outils Anyscale pour localiser dès maintenant les ressources exposées.
Les enseignements indirects de ShadowRay
Même si les dégâts directs seront importants pour les victimes, ShadowRay révèle des hypothèses cachées en matière de sécurité réseau, négligées dans la course effrénée vers le cloud et l’adoption de l’IA. Examinons ces hypothèses dans le contexte de la sécurité de l’IA, des ressources exposées sur Internet et de l’analyse des vulnérabilités.
Leçons de sécurité de l’IA
Dans leur empressement à exploiter la puissance présumée de l’IA, les entreprises confient leurs initiatives à des experts de l’IA qui se concentrent naturellement sur leur objectif principal : obtenir les résultats des modèles d’IA. Cette myopie est compréhensible, mais les entreprises ignorent trois problèmes cachés essentiels révélés par ShadowRay : les experts de l’IA manquent d’expertise en sécurité, les données d’IA doivent être chiffrées et les modèles d’IA doivent faire l’objet d’un suivi de leur provenance.
Les experts de l’IA manquent d’expertise en sécurité
Anyscale part du principe que l’environnement est sécurisé, tout comme les chercheurs en IA supposent que Ray est sécurisé. Neil Carpenter, Field CTO chez Orca Security, déclare : « Si le point de terminaison ne doit pas être authentifié, il pourrait au moins être protégé par des contrôles réseau bloquant par défaut les accès en dehors du sous-réseau immédiat. Il est décevant que les auteurs contestent cette CVE en la considérant comme un choix de conception, au lieu de chercher à y remédier. »
La réponse d’Anyscale, comparée à l’utilisation réelle de Ray, montre que les experts de l’IA n’ont pas une culture de la sécurité. Les centaines de serveurs exposés indiquent que de nombreuses organisations doivent ajouter la sécurité à leurs équipes dédiées à l’IA ou intégrer une supervision de la sécurité à leurs opérations. Celles qui continuent de supposer que leurs systèmes sont sécurisés subiront des violations de la conformité des données et d’autres dommages.
Les données d’IA doivent être chiffrées
Les attaquants détectent et localisent facilement les informations sensibles non chiffrées, en particulier les données que les chercheurs d’Oligo décrivent comme les « modèles ou jeux de données [qui] constituent la propriété intellectuelle privée et unique qui différencie une entreprise de ses concurrents ».
Les données d’IA deviennent un point de défaillance unique pour les violations de données et l’exposition des secrets d’entreprise, alors que les organisations qui consacrent des millions à la recherche sur l’IA négligent les dépenses de sécurité nécessaires pour les protéger. Heureusement, le chiffrement au niveau applicatif (ALE) et d’autres solutions de chiffrement modernes peuvent être achetés pour renforcer la protection des données internes ou externes utilisées pour la modélisation de l’IA.
Les modèles d’IA doivent faire l’objet d’un suivi de leur provenance
À mesure que les modèles d’IA assimilent des informations pour leur modélisation, les programmeurs spécialisés dans l’IA partent du principe que toutes les données sont de bonnes données et que le principe « garbage in, garbage out » ne s’appliquera jamais à l’IA. Malheureusement, si des attaquants peuvent insérer de fausses données externes dans un jeu de données d’entraînement, le modèle sera influencé, voire complètement biaisé. Pourtant, la protection des données d’IA reste difficile.
« C’est un domaine qui évolue rapidement, reconnaît Carpenter. Cependant… les contrôles existants contribueront à protéger les futurs supports d’entraînement de l’IA ; par exemple, les premières lignes de défense devraient inclure la limitation des accès, à la fois au niveau de l’identité et de la couche réseau, ainsi que l’audit des accès aux données utilisées pour entraîner les modèles d’IA. La sécurisation d’une chaîne d’approvisionnement qui inclut l’entraînement de l’IA commence de la même manière que celle de toute autre chaîne d’approvisionnement logicielle : par des fondations solides. »
Les défenses traditionnelles protègent les sources de données d’IA internes, mais deviennent exponentiellement plus complexes lorsqu’il faut intégrer des sources de données externes à l’organisation. Carpenter souligne que les données de tiers nécessitent une attention particulière afin d’éviter des problèmes tels que « l’empoisonnement malveillant des données, la violation des droits d’auteur et les biais implicites ». Un nettoyage des données visant à éviter ces problèmes devra être effectué avant leur ajout aux serveurs servant à entraîner les modèles d’IA.
Certains chercheurs considèrent peut-être tous les résultats comme plausibles, y compris les hallucinations de l’IA. Pourtant, des résultats fictifs ou corrompus induiront en erreur quiconque tentera de les appliquer dans le monde réel. Il faut appliquer une bonne dose de scepticisme au processus afin d’encourager le suivi de l’authenticité, de la validité et de l’utilisation appropriée des données qui influencent l’IA.
Leçons sur les ressources exposées sur Internet
ShadowRay pose problème parce que les équipes chargées de l’IA ont exposé l’infrastructure à un accès public. Pourtant, bien d’autres laissent sur Internet des ressources accessibles présentant d’importantes vulnérabilités susceptibles d’être exploitées. Par exemple, l’image ci-dessous représente les centaines de milliers d’adresses IP présentant des vulnérabilités critiques que la Shadowserver Foundation a détectées comme accessibles depuis Internet !
Une recherche portant sur tous les niveaux de vulnérabilité révèle des millions de problèmes potentiels, mais n’inclut même pas une CVE contestée telle que ShadowRay, ni d’autres infrastructures accidentellement mal configurées et accessibles. Le recours à une plateforme de protection des applications cloud natives (CNAP), voire à un scanner de vulnérabilités des ressources cloud peut aider à détecter les vulnérabilités exposées.
Malheureusement, les analyses supposent que les équipes de développement de l’IA et les autres équipes déployant des ressources soumettent celles-ci au service de sécurité à des fins de suivi ou d’analyse. Les équipes chargées de l’IA lancent probablement des ressources de manière indépendante pour des raisons budgétaires et de rapidité de déploiement, mais les équipes de sécurité doivent tout de même être informées de leur existence afin d’appliquer les bonnes pratiques de sécurité cloud à l’infrastructure.
Leçons sur l’analyse des vulnérabilités
Le fait qu’Anyscale conteste la CVE-2023-48022 place cette vulnérabilité dans une zone grise, au même titre que les nombreuses autres vulnérabilités CVE contestées. Celles-ci vont de problèmes qui n’ont pas encore été prouvés et pourraient ne pas être valides à des problèmes pour lesquels le produit fonctionne comme prévu, mais de manière non sécurisée (comme ShadowRay).
Ces vulnérabilités contestées méritent d’être suivies, soit au moyen d’un outil de gestion des vulnérabilités soit dans le cadre d’un programme de gestion des risques. Elles méritent également une attention particulière en raison de deux enseignements essentiels révélés par ShadowRay. Premièrement, les outils d’analyse des vulnérabilités ne traitent pas tous les vulnérabilités contestées de la même manière ; deuxièmement, ces vulnérabilités doivent faire l’objet d’un suivi et d’une vérification actifs.
Surveillez les différences de traitement des vulnérabilités contestées
Les différents scanners de vulnérabilités et flux de menaces traiteront les vulnérabilités contestées différemment. Certains les omettront, d’autres pourront les proposer en option dans les analyses, et d’autres encore pourront les classer comme différents types de problèmes.
Par exemple, Carpenter révèle qu’« Orca a choisi de traiter cela comme un risque de posture plutôt que comme une vulnérabilité de type CVE… Il s’agit d’une approche plus facilement exploitable par les organisations, car une CVE est généralement traitée par une mise à jour (qui ne sera pas disponible ici), tandis qu’un risque de posture est traité par une modification de configuration (ce qui constitue l’approche appropriée dans ce cas). » Les équipes informatiques doivent suivre activement la manière dont un outil donné traitera une vulnérabilité précise.
Suivez et vérifiez activement les vulnérabilités
Les outils promettent de simplifier les processus, mais malheureusement, le bouton magique de la sécurité n’existe pas encore. En ce qui concerne les scanners de vulnérabilités, il ne sera pas évident de savoir si un outil existant recherche une vulnérabilité précise.
Les équipes de sécurité doivent suivre activement les vulnérabilités susceptibles d’affecter l’environnement informatique et vérifier que l’outil recherche bien les CVE concernées. Pour les vulnérabilités contestées, des étapes supplémentaires peuvent être nécessaires, comme l’envoi d’une demande à l’équipe d’assistance du scanner de vulnérabilités afin de vérifier comment l’outil traitera, ou ne traitera pas, cette vulnérabilité précise.
Pour réduire davantage le risque d’exposition, utilisez plusieurs outils d’analyse des vulnérabilités et des tests d’intrusion afin de valider le risque potentiel des vulnérabilités découvertes ou de détecter d’autres problèmes potentiels. Dans le cas de ShadowRay, Anyscale a fourni un outil, mais les outils open source gratuits d’analyse des vulnérabilités peuvent également fournir des ressources supplémentaires utiles.
En résumé : vérifiez et revérifiez les vulnérabilités importantes
Il n’est pas nécessaire d’être vulnérable à ShadowRay pour tirer profit des enseignements indirects de ce problème concernant les risques liés à l’IA, les actifs exposés sur Internet et l’analyse des vulnérabilités. Les conséquences réelles sont douloureuses, mais l’analyse continue des vulnérabilités potentielles sur les infrastructures critiques permet de localiser les problèmes à résoudre avant qu’un attaquant ne puisse causer des dommages.
Soyez conscients des limites des outils d’analyse des vulnérabilités, de la modélisation de l’IA et des employés pressés de déployer des ressources cloud. Mettez en place des mécanismes permettant aux équipes de collaborer pour renforcer la sécurité, ainsi qu’un système de surveillance continue des vulnérabilités potentielles au moyen de recherches, de flux de menaces, de scanners de vulnérabilités et de tests d’intrusion.
Pour obtenir davantage d’aide afin de vous informer sur les menaces potentielles, pensez à consulter les flux de renseignements sur les menaces.