Le cadre open-source Ray est largement utilisé, avec des milliers d'organisations qui en dépendent pour des charges de travail complexes et gourmands en ressources. Notamment, GPT-3 a été entraîné sur ce cadre, soulignant son importance dans le monde des grands modèles de langage (LLM).
Récemment, la découverte de la vulnérabilité “ShadowRay” a suscité de vives préoccupations. Pendant sept mois, cette vulnérabilité a permis à des attaquants d'accéder à des charges de travail sensibles liées à l'IA de milliers d'entreprises, compromettant ainsi la puissance de calcul, les identifiants, les mots de passe, les clés, les tokens et d'autres données critiques.
Bien qu'Anyscale, le mainteneur du cadre, ait d'abord contesté la gravité de la vulnérabilité, ils ont depuis publié de nouveaux outils pour aider les utilisateurs à vérifier si leurs ports sont exposés. « À la suite de rapports d'activités malveillantes, nous avons agi rapidement pour fournir des outils permettant de vérifier la configuration correcte des clusters afin de prévenir toute exposition accidentelle », a déclaré un porte-parole d'Anyscale.
La vulnérabilité, identifiée comme CVE-2023-48022, peut exposer l'API Ray Jobs à des attaques d'exécution de code à distance. Cela signifie que toute personne ayant accès au réseau du tableau de bord pourrait invoquer des travaux non autorisés, comme l'a révélé Oligo Security dans un rapport récent.
Bien qu'Anyscale ait d'abord caractérisé le problème comme un comportement attendu, ils ont maintenant introduit le vérificateur de ports ouverts. Cet outil simplifie le processus d'identification des ports ouverts de manière inattendue. Le script côté client est configuré par défaut pour contacter un serveur Anyscale préconfiguré et renvoie un message “OK” ou un rapport “WARNING” concernant les ports ouverts.
Un "WARNING" signifie que le serveur détecte quelque chose sur le port, mais n'indique pas nécessairement l'accès ouvert au trafic non authentifié, car le script ne détermine pas ce qui s'exécute sur ce port. Une réponse “OK” indique qu'aucune connexion n'a pu être établie à aucun port. Cependant, Anyscale avertit que cette réponse ne garantit pas l'absence de ports ouverts en raison de configurations potentielles, telles que des pare-feux ou des règles NAT.
Anyscale prévoit d'organiser des tests pour que la communauté puisse vérifier explicitement ces chemins réseau. Le dépôt est disponible sous la licence Apache2 et peut être déployé sur n'importe quel nœud Ray Head ou Worker, fonctionnant sur toutes les versions de Ray et renvoyant tous les ports existants via les API Ray. L'outil peut également être configuré pour envoyer des appels réseau de test à un serveur web léger, ou les utilisateurs peuvent envoyer des appels à leurs propres serveurs si souhaité.
La vulnérabilité 'ShadowRay' est restée largement inaperçue, n'ayant pas de correctif en place. Elle a donc été considérée comme une “vulnérabilité d'ombre”, généralement négligée lors des analyses standards. Selon Oligo Security, cette vulnérabilité a affecté :
- Les charges de travail de production d'IA
- L'accès aux environnements cloud (AWS, GCP, Azure, Lambda Labs) et aux services cloud sensibles
- L'accès à l'API Kubernetes
- Les identifiants pour OpenAI, Stripe et Slack
- Les identifiants de base de données de production
- Les tokens pour OpenAI, Hugging Face, Stripe et Slack
Au 28 mars, Censys a identifié 315 hôtes affectés dans le monde, avec plus de 77 % d'entre eux exposant une page de connexion et plusieurs exposant des répertoires de fichiers.
Les experts avertissent que ‘ShadowRay’ pose des risques importants car il cible l'infrastructure sous-jacente plutôt que des applications spécifiques. Nick Hyatt, directeur de l'intelligence des menaces chez Blackpoint Cyber, souligne que les acteurs malveillants peuvent obtenir bien plus d'informations en compromettant l'infrastructure que par des attaques théoriques alimentées par l'IA.
Beaucoup supposent que cette infrastructure est sécurisée, ce qui conduit à une complaisance concernant les données que les LLM utilisent. Cette perception crée des opportunités pour les attaquants d'accéder à de grandes quantités d'informations sensibles. Neil Carpenter d'Orca Security souligne le défi de publier des projets d'IA open-source sans mesures de sécurité robustes, souvent en s'appuyant sur une documentation insuffisante pour des composants critiques.
La situation de 'ShadowRay' souligne la nécessité de discussions plus larges autour des pratiques de développement sécurisé, surtout dans un paysage où la vitesse l'emporte souvent sur la sécurité. Les entreprises souhaitant adopter des LLM doivent prioriser l'hygiène des données. « On ne peut pas introduire sans discernement un serveur entier dans un LLM et s'attendre à des résultats fluides, en particulier lorsqu'il s'agit de données sensibles », avertit Hyatt.
Les organisations doivent valider les ensembles de données et comprendre les exigences réglementaires, surtout lors du développement de LLM sur site. Les questions concernant l'origine des données et leur validation deviennent critiques pour garantir que les modèles fournissent des informations précises dans le cadre des opérations commerciales régulières.
En fin de compte, les défis posés par 'ShadowRay' ne sont pas uniquement technologiques ; ils impliquent des personnes, des processus et de la technologie. À mesure que l'IA générative continue d'évoluer, Hyatt prédit une augmentation des attaques sur l'infrastructure plutôt qu'une exploitation directe via l'IA générative. Avec des données facilement accessibles et des exploits courants, les attaquants pourraient trouver des voies plus faciles pour compromettre plutôt que d'utiliser l'IA directement pour l'intrusion.