Des chercheurs ont découvert une faille dans le serveur MCP d’Asana qui peut entraîner une fuite de données. Une affaire qui montre que le protocole dans le domaine de l’IA est toujours en développement.
Si l’interopérabilité est essentiel pour le développement de l’IA, elle ne doit pas de faire sans une sécurité renforcée. Dernier exemple en date Asana. Ce dernier, qui édite une plateforme SaaS de gestion des tâches, a mis hors ligne temporairement son serveur MCP (Model context protocol). En effet, des chercheurs du fournisseur de sécurité Upguard ont découvert début juin une faille qui « aurait potentiellement exposée certaines informations des domaines Asana à d’autres utilisateurs MCP, au sein des projets, des équipes, des tâches et d’autres objets Asana liés aux autorisations de l’utilisateur MCP ».
Selon Upguard, « rien n’indique que des attaquants aient exploité le bug ou que d’autres utilisateurs aient réellement consulté les informations accessibles via le bug MCP. De son côté, Asana affirme que la vulnérabilité ne résulte pas d’un piratage ou d’une activité malveillante sur ses systèmes. Notre confrère CSO a contacté l’entreprise pour un commentaire, mais aucune réponse n’a été apportée pour le moment.
Un outil beta expérimental
Pour mémoire, MCP est un protocole créé par Anthropic et rendu open source en novembre dernier. L’entreprise le décrit comme « une nouvelle norme pour connecter les assistants IA aux systèmes où résident les données, notamment les référentiels de contenu, les outils métiers et les environnements de développement. Son objectif est d’aider les modèles de pointe à produire des réponses plus performantes et plus pertinentes.» Les développeurs peuvent soit exposer leurs données via les serveurs MCP, explique Anthropic, soit créer des applications d’IA (clients MCP) qui se connectent à ces serveurs. L’idée est qu’au lieu de maintenir des connecteurs distincts pour chaque source de données, les développeurs peuvent désormais développer leurs applications à partir d’un protocole standard.
Reste que MCP est encore en phase de développement. D’ailleurs, le serveur MCP d’Asana a été publié le 1er mai dernier où une page web le présentait comme un « outil bêta expérimental ».Il était donc possible de « rencontrer des bugs, des erreurs ou des résultats inattendus » peut-on lire sur le site. Pour Kellman Meghu, architecte principal en sécurité chez DeepCove Cybersecurity, cabinet de conseil canadien, la faille découverte n’est pas une surprise, « c’est un problème courant avec les serveurs MCP, c’est pourquoi nous les évitons. Tous les MCP présentent ce problème.» Il ajoute que les RSSI se servant de ces outils doivent limiter les données auxquelles ils peuvent accéder jusqu’à ce que les contrôles de cybersécurité soient renforcés.
Des serveurs MCP encore en phase de développement
Il observe que ces protocoles d’interopérabilité sont « en réalité des connexions serveur-TCP durables ». Le spécialiste privilégie une solution de connexion utilisant le modèle RAG (retrieval augmentationd generation) avec un appel API authentifiable pour des raisons de sécurité. Entre autres avantages, le RAG peut être configuré pour rechercher uniquement les données approuvées et non les informations utilisées en formation, susceptibles d’inclure des informations sensibles. « C’est là que les leçons que nous avons apprises en matière de segmentation [des données] et de gestion des API directes s’appliquent [aux systèmes d’IA] », a-t-il déclaré. « Mais ils ont abandonné cette approche et opté pour des connexions TCP à longue durée de vie, difficilement supervisables. Lorsqu’une fuite de données se produit, il est déjà trop tard.»
Selon son interface, un serveur MCP peut constituer un « vecteur d’attaque massif et massif », a expliqué Kellman Meghu. Par exemple, si le serveur MCP est connecté à une plateforme SIEM (surveillance des informations et des événements de sécurité) pour l’analyse des données de logs, un acteur malveillant pourrait tenter d’accéder à ce serveur pour collecter des données. La grande question pour les RSSI selon lui est « où placer le serveur MCP ? ». Difficile trouver une réponse, « je pense que comme pour tous les nouveaux protocoles, il est trop tôt pour le mettre en production », glisse l’architecte en sécurité. Tout en reconnaissant, « ils ont fait ça à la va-vite. Je pense qu’il y a de meilleures façons de faire, mais nous n’en avons pas encore trouvées ». Et d’évoquer « Pourquoi ne pas s’appuyer sur des protocoles connus comme JSON et RestAPI ? Pourquoi fallait-il créer un service spécifique ? Le contrôle d’accès n’était-il pas intégré au protocole ? ». Il se veut néanmoins optimiste, « Je m’attends à ce que de nombreux protocoles de ce type apparaissent, et j’espère que certains d’entre eux seront conçus dès le départ avec la sécurité à l’esprit : contrôle d’audit, authentification de chaque appel »