DEF CON 34: RovoBlast Exposes Atlassian Rovo Data Risks 

Les chercheurs de Varonis Threat Labs ont identifié RovoBlast, une vulnérabilité affectant Atlassian Rovo.

La faille a montré comment un simple lien spécialement conçu pouvait introduire des instructions contrôlées par un attaquant dans la session d’IA de confiance d’un utilisateur et potentiellement exposer des données de l’organisation.

Les chercheurs Dolev Taler et Mark Vaitsman ont présenté leurs conclusions à la DEF CON 34 après avoir signalé la vulnérabilité de manière responsable à Atlassian, qui l’a ensuite corrigée.

RovoBlast met en lumière un problème de sécurité plus vaste pour l’IA d’entreprise. 

Lorsque les assistants peuvent accéder à des données sensibles et interagir de manière autonome avec plusieurs systèmes métier, des entrées non fiables peuvent créer des risques qui dépassent largement le cadre d’une session classique avec un chatbot.

Principaux enseignements de l’étude de Varonis sur RovoBlast

• RovoBlast a utilisé une attaque Parameter-to-Prompt (P2P) qui permettait à un lien spécialement conçu d’introduire des instructions contrôlées par un attaquant dans une session Atlassian Rovo authentifiée.
• L’attaque ne nécessitait ni jailbreak classique ni contournement des autorisations, mais s’appuyait sur les accès existants de l’utilisateur pour récupérer des informations depuis des systèmes d’entreprise connectés.
• Les intégrations de Rovo et ses capacités d’agent autonome ont accru l’ampleur potentielle de l’impact, ouvrant la voie à la récupération et à l’exposition potentielle de données sensibles avec une interaction minimale de l’utilisateur.
• Les organisations doivent limiter les autorisations, les intégrations et les capacités autonomes de l’IA tout en considérant les invites externes comme des entrées non fiables et en surveillant l’activité de l’IA pour détecter les signes d’abus.

Fonctionnement de l’attaque RovoBlast

Atlassian Rovo est un assistant d’IA d’entreprise qui propose des fonctions de recherche, de conversation et d’agent dans Jira, Confluence, Bitbucket et des services tiers connectés.

Les chercheurs ont découvert que Rovo acceptait du contenu fourni par des sources externes via son paramètre d’URL rovoChatPrompt. 

Un lien spécialement construit pouvait donc préremplir Rovo Chat avec des instructions contrôlées par un attaquant lorsqu’un utilisateur connecté cliquait dessus.

Varonis décrit cette technique comme une attaque Parameter-to-Prompt (P2P), un mode opératoire que l’entreprise avait précédemment documenté dans ses recherches consacrées à Microsoft Copilot.

RovoBlast était particulièrement préoccupant, car son exploitation ne nécessitait ni jailbreak classique ni contournement des autorisations. 

Selon les chercheurs, des instructions fournies par des sources externes pouvaient entrer dans la session Rovo authentifiée de l’utilisateur sans avertissement notable ni confirmation indiquant que l’invite provenait d’un paramètre externe.

Les autorisations existantes de l’utilisateur déterminaient ensuite les informations que Rovo pouvait récupérer.

Les intégrations de Rovo ont accru l’ampleur potentielle de l’impact

L’utilité de Rovo tient en partie à sa capacité à rechercher et à synthétiser des informations dans différents systèmes d’entreprise. Cette même interconnexion a accru l’impact potentiel de RovoBlast.

Pendant les tests, les chercheurs ont constaté que Rovo pouvait accéder à des données dans Jira, Slack, Google Workspace, Microsoft 365, des bases de données, des fichiers importés et d’autres ressources connectées. 

Les connecteurs Rovo peuvent encore étendre cet accès à des dizaines de services externes.

Cela crée une distinction importante entre l’injection d’invite et les attaques applicatives plus traditionnelles. 

Un attaquant n’a pas nécessairement besoin de compromettre individuellement chaque système sous-jacent si un assistant d’IA y dispose déjà d’un accès légitime au nom de l’utilisateur.

Les actions effectuées via une session d’IA authentifiée peuvent également ressembler à une activité légitime, ce qui peut rendre les comportements malveillants plus difficiles à distinguer des flux de travail ordinaires assistés par l’IA.

Les agents autonomes ont créé une autre voie d’exposition des données

Les chercheurs ont également examiné ResearchAgent de Rovo, qui peut effectuer des recherches multi-sources et naviguer sur le Web en plusieurs étapes.

Ces capacités autonomes ont potentiellement amplifié l’impact de RovoBlast. 

Une fois les instructions malveillantes introduites dans une session de confiance, un agent pouvait récupérer des données sensibles et potentiellement les exposer à l’extérieur avec une interaction minimale de l’utilisateur.

Selon Varonis, l’attaque testée ne nécessitait généralement que l’interaction P2P initiale, et non les techniques plus complexes utilisées pour contourner les garde-fous de l’IA.

Cette découverte montre pourquoi les organisations doivent évaluer les agents d’IA non seulement en fonction des informations qu’ils peuvent récupérer, mais aussi des actions qu’ils peuvent effectuer avec ces informations.

Comment les organisations peuvent réduire leur exposition à l’IA d’entreprise

Atlassian a corrigé la vulnérabilité RovoBlast signalée, mais les organisations qui utilisent des assistants d’IA connectés devraient mettre en place des contrôles plus larges afin de réduire l’impact d’attaques similaires.

Les équipes de sécurité devraient :

• Limiter l’accès de l’IA aux systèmes sensibles et supprimer les connecteurs, intégrations et sources de données inutilisés afin de réduire l’ampleur potentielle de l’impact.
• Appliquer le principe du moindre privilège et utiliser, lorsque c’est possible, des identités de service dédiées à l’IA afin de restreindre les accès et d’améliorer la traçabilité.
• Traiter les invites et paramètres externes comme des entrées non fiables et les valider avant d’autoriser des actions sensibles ou l’accès à des données.
• Restreindre les capacités autonomes et les accès sortants afin d’empêcher les agents d’IA de naviguer inutilement, d’exécuter des actions en plusieurs étapes ou de transmettre des données à l’extérieur.
• Utiliser des contrôles de prévention des pertes de données pour détecter et bloquer l’exposition non autorisée d’informations confidentielles, réglementées ou sensibles.
• Surveiller et consigner l’activité de l’IA afin de repérer les recherches inhabituelles, les accès inattendus aux données, les comportements suspects des agents et les interactions avec des destinations externes.
• Tester les plans de réponse aux incidents avec des outils et des scénarios de simulation d’attaque portant sur l’injection d’invites et d’autres attaques pilotées par l’IA.

Ensemble, ces mesures peuvent réduire la surface d’attaque des assistants d’IA connectés et limiter l’impact potentiel lorsque des entrées non fiables atteignent des flux de travail d’entreprise de confiance.

En résumé

RovoBlast souligne les risques de sécurité qui apparaissent à mesure que les assistants d’IA obtiennent un accès plus étendu aux systèmes, aux données et aux flux de travail de l’entreprise. 

Si une interconnexion accrue peut améliorer la productivité, chaque autorisation, intégration et capacité autonome supplémentaire élargit l’ampleur potentielle de l’impact si un attaquant parvient à manipuler l’IA.

La sécurisation de l’IA d’entreprise exige des contrôles qui vont au-delà du filtrage des invites. 

Les organisations doivent imposer des limites de confiance claires autour de ce à quoi les assistants d’IA peuvent accéder, des actions que les agents peuvent effectuer et de la manière dont les entrées externes ou non fiables sont traitées avant d’atteindre des ressources sensibles.