Getty Images
Des milliers de serveurs stockant des charges de travail d’IA et des informations d’identification réseau ont été piratés dans le cadre d’une campagne d’attaque en cours ciblant une vulnérabilité signalée dans Ray, un framework informatique utilisé par OpenAI, Uber et Amazon.
Les attaques, actives depuis au moins sept mois, ont conduit à la falsification des modèles d’IA. Ils ont également abouti à la compromission des informations d’identification du réseau, permettant l’accès aux réseaux et bases de données internes, ainsi qu’aux jetons permettant d’accéder aux comptes sur des plateformes telles qu’OpenAI, Hugging Face, Stripe et Azure. En plus de corrompre les modèles et de voler les informations d’identification, les attaquants à l’origine de la campagne ont installé des mineurs de cryptomonnaie sur une infrastructure compromise, qui fournit généralement d’énormes quantités de puissance de calcul. Les attaquants ont également installé des reverse shells, qui sont des interfaces textuelles permettant de contrôler les serveurs à distance.
Gagner le jackpot
« Lorsque des attaquants mettent la main sur un cluster de production Ray, c’est un jackpot », ont écrit dans un article des chercheurs d’Oligo, la société de sécurité qui a repéré les attaques. « Les données précieuses de l’entreprise et l’exécution de code à distance facilitent la monétisation des attaques, tout en restant dans l’ombre, totalement indétectables (et, avec des outils de sécurité statiques, indétectables). »
Parmi les informations sensibles compromises figurent les charges de travail de production d’IA, qui permettent aux attaquants de contrôler ou de falsifier les modèles pendant la phase de formation et, à partir de là, de corrompre l’intégrité des modèles. Les clusters vulnérables exposent un tableau de bord central à Internet, une configuration qui permet à quiconque le recherche de voir un historique de toutes les commandes saisies à ce jour. Cet historique permet à un intrus d’apprendre rapidement comment fonctionne un modèle et à quelles données sensibles il a accès.
Oligo a capturé des captures d’écran exposant des données privées sensibles et affichant des historiques indiquant que les clusters avaient été activement piratés. Les ressources compromises comprenaient des hachages de mots de passe cryptographiques et des informations d’identification vers des bases de données internes et des comptes sur OpenAI, Stripe et Slack.
-
Opérateur Kuberay exécuté avec des autorisations d’administrateur sur l’API Kubernetes.
-
Hachages de mots de passe consultés.
-
Identifiants de la base de données de production.
-
Modèle d’IA en action : gestion d’une requête soumise par un utilisateur en temps réel. Le modèle pourrait être abusé par l’attaquant, qui pourrait potentiellement modifier les demandes ou les réponses des clients.
-
Jetons pour OpenAI, Stripe et Slack et informations d’identification de base de données.
-
Tableau de bord du cluster avec charges de travail de production et tâches actives.
Ray est un framework open source permettant de faire évoluer les applications d’IA, ce qui signifie permettre à un grand nombre d’entre elles de s’exécuter simultanément de manière efficace. En règle générale, ces applications s’exécutent sur d’énormes clusters de serveurs. La clé pour que tout cela fonctionne est un tableau de bord central qui fournit une interface pour afficher et contrôler les tâches et les applications en cours d’exécution. L’une des interfaces de programmation disponibles via le tableau de bord, connue sous le nom d’API Jobs, permet aux utilisateurs d’envoyer une liste de commandes au cluster. Les commandes sont émises à l’aide d’une simple requête HTTP ne nécessitant aucune authentification.
L’année dernière, des chercheurs de la société de sécurité Bishop Fox ont signalé ce comportement comme une vulnérabilité d’exécution de code de haute gravité identifiée comme CVE-2023-48022.
Un framework d’exécution distribué
« Dans la configuration par défaut, Ray n’applique pas l’authentification », a écrit Berenice Flores Garcia, consultante principale en sécurité chez Bishop Fox. « En conséquence, les attaquants peuvent librement soumettre des tâches, supprimer des tâches existantes, récupérer des informations sensibles et exploiter les autres vulnérabilités décrites dans cet avis. »
Anyscale, le développeur et responsable de Ray, a répondu en contestant la vulnérabilité. Les responsables d’Anyscale ont déclaré qu’ils ont toujours considéré Ray comme un cadre pour l’exécution de code à distance et, par conséquent, ont longtemps conseillé qu’il soit correctement segmenté au sein d’un réseau correctement sécurisé.
« En raison de la nature de Ray en tant que cadre d’exécution distribué, la limite de sécurité de Ray se situe en dehors du cluster Ray », ont écrit les responsables d’Anyscale. « C’est pourquoi nous insistons sur le fait que vous devez empêcher l’accès à votre cluster Ray à partir de machines non fiables (par exemple, l’Internet public). »
La réponse d’Anyscale a déclaré que le comportement signalé dans l’API jobs ne constituait pas une vulnérabilité et ne serait pas corrigé dans une mise à jour à court terme. La société a poursuivi en annonçant qu’elle introduireait éventuellement un changement qui renforcerait l’authentification dans l’API. Il expliquait :
Nous avons réfléchi très sérieusement à la question de savoir si une telle solution serait ou non une bonne idée et, à ce jour, nous ne l’avons pas mis en œuvre de peur que nos utilisateurs n’accordent trop de confiance à un mécanisme qui pourrait finir par fournir une façade de sécurité sans sécuriser correctement leurs utilisateurs. clusters comme ils l’imaginaient.
Cela dit, nous reconnaissons que les avis raisonnables peuvent différer sur cette question et, par conséquent, nous avons décidé que, même si nous ne pensons toujours pas qu’une organisation devrait s’appuyer sur des contrôles d’isolement au sein de Ray comme l’authentification, il peut être utile dans certains contextes de promouvoir un stratégie de défense en profondeur, et nous l’implémenterons donc en tant que nouvelle fonctionnalité dans une prochaine version.
Les critiques de la réponse Anyscale ont noté que les référentiels destinés à rationaliser le déploiement de Ray dans les environnements cloud lient le tableau de bord à 0.0.0.0, une adresse utilisée pour désigner toutes les interfaces réseau et pour désigner la redirection de port sur la même adresse. Un de ces modèles pour débutants est disponible sur le site Web Anyscale lui-même. Un autre exemple de configuration vulnérable accessible au public est ici.
Les critiques notent également que l’affirmation d’Anyscale selon laquelle le comportement signalé ne constitue pas une vulnérabilité a empêché de nombreux outils de sécurité de signaler les attaques.
Un représentant d’Anyscale a déclaré dans un e-mail que la société prévoyait de publier un script qui permettrait aux utilisateurs de vérifier facilement si leurs instances Ray sont exposées à Internet.
Les attaques en cours soulignent l’importance de configurer correctement Ray. Dans les liens fournis ci-dessus, Oligo et Anyscale répertorient les pratiques essentielles au verrouillage des clusters. Oligo a également fourni une liste d’indicateurs que les utilisateurs de Ray peuvent utiliser pour déterminer si leurs instances ont été compromises.