La plateforme d’entrainement, d’orchestration et de création d’applications et agents IA de Google, Vertex AI, n’est pas étanche aux failles selon des chercheurs en sécurité de XM Cyber. Ces derniers ont découvert qu’elle était vulnérable à l’escalade de privilèges, rappelant brutalement aux RSSI - qui en douteraient encore - que les projets agentiques ne sont pas sans risque. La société spécialisée dans l’exposition aux cybermenaces a signalé deux problèmes concernant Vertex AI, dans lesquels des configurations par défaut permettent à des utilisateurs disposant de droits limités d'accéder à des rôles d’agents IA disposant de privilèges plus élevés.

Selon Sanchit Vir Gogia, analyste en chef chez Greyhound Research, ce rapport met en tout cas en lumière « le décalage fondamental entre le modèle de confiance qui sous-tend Vertex AI de Google et les principes de sécurité des entreprises ». Dans ces plateformes, les agents de services managés se voient accorder des autorisations étendues afin que les fonctions IA puissent fonctionner dès leur mise en place. Mais cette commodité se fait au détriment de la visibilité et du contrôle. Ces identités fonctionnent en arrière-plan, disposent de privilèges à l'échelle du projet et peuvent être manipulées par tout utilisateur qui comprend le fonctionnement du système ». Google n'a pas répondu à la demande de commentaires de CSO.

Des agents de service aux privilèges trop élevés

Dans son analyse, XM Cyber explique que les vulnérabilités trouvées résident dans la manière dont les privilèges sont attribués aux différents rôles associés à Vertex AI. « Le rôle des agents de service est central à cet égard : il s'agit de comptes de service spéciaux créés et gérés par Google Cloud qui accordent aux services d'accéder à vos ressources et d'effectuer des processus internes en votre nom. Comme ces identités managées sont nécessaires au fonctionnement des services, elles se voient souvent automatiquement accorder des autorisations étendues à l'échelle du projet », explique la société. « Ces failles donnent à un attaquant disposant d'autorisations minimales la capacité de détourner des agents dotés de privilèges élevés, transformant ainsi ces identités invisibles en agents doubles qui facilitent l'escalade des privilèges. Lorsque nous avons communiqué nos conclusions à Google, leur raisonnement était que les services « fonctionnent actuellement comme prévu ». 

Sanchit Vir Gogia estime que cette réponse est alarmante : « lorsqu'un fournisseur de cloud affirme que le fait qu'un utilisateur disposant de faibles privilèges puisse détourner une identité de service à haut privilège fonctionne comme prévu, ce qu'il dit en réalité, c'est que votre modèle de gouvernance est subordonné à son architecture », explique-t-il. « Il s'agit d'un défaut de conception structurel qui confère du pouvoir à des composants dont la plupart des clients ignorent même l'existence. » Rock Lambros, CEO de la société de sécurité RockCyber, explique quant à lui : « L'Owasp Agentic Top 10 vient de codifier l'abus d'identité et de privilèges sous le nom d'ASI03 et Google nous a immédiatement fourni une étude de cas [...] Ce scénario a déjà été vu. Orca a découvert une élévation des privilèges dans Azure Storage, Microsoft l’avait décrite comme étant by design. Aqua a trouvé des chemins de déplacement latéral dans SageMaker, AWS a déclaré lui aussi que tout fonctionnait comme prévu». Il ajoute que « les fournisseurs cloud ont transformé la responsabilité partagée en un bouclier pour leurs propres paramètres par défaut non sécurisés. Les RSSI doivent cesser de croire qu’un service managé signifie qu’il est sécurisé, et commencer à auditer chaque identité de service associée à leurs charges de travail IA, car les fournisseurs ne le font clairement pas pour vous. »

Ne pas attendre que les fournisseurs agissent

Brian Levine, consultant en cybersécurité et directeur exécutif de FormerGov, s'est également montré inquiet. « La meilleure chose à faire pour les RSSI est de mettre en place dès maintenant des contrôles préventifs, car attendre que les fournisseurs redéfinissent le comportement prévu n'est pas une stratégie de sécurité », a-t-il déclaré. Flavio Villanustre, RSSI du groupe LexisNexis Risk Solutions, a lancé cette mise en garde : « Un collaborateur malveillant pourrait exploiter ces faiblesses pour s'octroyer un accès plus étendu que celui qui lui est normalement accordé. » Mais, a-t-il ajouté, « il n'y a pas grand-chose à faire pour atténuer le risque, si ce n'est peut-être limiter la portée des dégâts en réduisant le champ d'application de l'authentification et en mettant en place des barrières de sécurité robustes entre les deux. » Cependant, « cela pourrait avoir pour effet secondaire d'augmenter considérablement les coûts, ce qui n'en ferait pas non plus une option viable sur le plan commercial. »

Selon M. Gogia, le plus grand risque réside dans le fait que ces failles passeront probablement inaperçues, car les outils de sécurité des entreprises ne sont pas programmés pour les détecter. « La plupart des entreprises ne surveillent pas le comportement des agents de service. Si l'une de ces identités est utilisée à mauvais escient, cela ne ressemblera pas à une attaque. Cela ressemblera plutôt à la plateforme qui fait son travail », explique M. Gogia. « C'est ce qui rend le risque si grave. Vous faites confiance à des composants que vous ne pouvez pas observer, restreindre ou isoler sans repenser fondamentalement votre posture cloud. La plupart des entreprises enregistrent l'activité des utilisateurs, mais ignorent ce que fait la plateforme en interne. Cela doit changer. Vous devez surveiller vos agents de service comme s'ils étaient des employés ayant des accès à privilèges. Créez des alertes pour les requêtes BigQuery inattendues, les accès au stockage ou les comportements de session. L'attaquant ressemblera à l'agent de service, c'est donc là que la détection doit se concentrer. »