Meta publie en urgence un correctif pour Muse après qu’un chercheur a transformé l’agent d’IA en outil d’attaque local

Meta a corrigé une vulnérabilité zero-day dans l’application Muse pour macOS. Celle-ci pouvait permettre à du code malveillant exécuté localement de détourner le processus de transcription de l’agent d’IA et d’exploiter son accès à l’appareil.

Le chercheur en sécurité Patrick Wardle a démontré qu’un attaquant pouvait manipuler Muse, accéder à des ressources associées au compte Muse de la victime, capturer des images et écrire des fichiers malveillants sur le disque. Certaines actions ne déclenchaient pas systématiquement d’avertissement visible.

La faille n’était pas exploitable à distance en elle-même. L’attaquant devait d’abord exécuter du code sur le Mac de la victime avec le compte de celle-ci, ce qui rendait cette vulnérabilité surtout utile après une compromission initiale plutôt que comme point d’entrée.

Meta a publié un correctif d’urgence quelques heures après la divulgation publique. L’entreprise n’a toutefois communiqué ni la plage de versions concernées, ni le numéro de build corrigé, ni l’identifiant CVE.

Un paramètre non documenté redirigeait la transcription vers le cloud

La faiblesse concernait une option de configuration non documentée de Muse, qui contrôlait l’endroit où l’application envoyait les données de transcription pour leur traitement.

Muse s’appuyait sur une infrastructure cloud pour la dictée, au lieu d’effectuer l’intégralité du traitement localement. Wardle a découvert qu’une application exécutée sur le Mac pouvait apparemment modifier les paramètres non documentés de Muse, notamment la destination utilisée pour le traitement des transcriptions.

Du code malveillant pouvait donc remplacer le point de terminaison légitime côté serveur de Meta par une infrastructure contrôlée par l’attaquant. Cette redirection ouvrait la voie à l’interception ou à la manipulation du fonctionnement de Muse et pouvait exposer des accès liés au compte Muse de la victime.

Le problème ne se limitait pas à la transcription dans le cloud. L’exploit résultait de la combinaison de plusieurs choix d’architecture :

• Muse envoyait la dictée hors de l’appareil pour la traiter.
• D’autres applications pouvaient modifier les paramètres non documentés de Muse.
• L’agent conservait l’accès aux fonctions de l’appareil et au stockage local.
• La séparation de sécurité entre les modifications de configuration et les actions autorisées par l’utilisateur était insuffisante.

Une fois le comportement de Muse redirigé, l’attaquant pouvait utiliser l’agent comme composant de l’intrusion, au lieu d’intégrer toutes les fonctionnalités nécessaires dans un logiciel malveillant distinct.

Cette distinction est importante. Un implant local élémentaire pouvait détourner une application déjà approuvée, en tirant parti des autorisations et de l’accès au compte que l’utilisateur avait accordés à Muse.

Des attaques de démonstration ont dépassé le cadre de la transcription

Wardle a créé des attaques de démonstration montrant que cette faiblesse pouvait être exploitée pour faire prendre des photos à Muse et déposer des fichiers malveillants sur le Mac.

Ces tests ont également indiqué que les utilisateurs ne recevraient pas toujours d’alerte visuelle fiable. L’absence de notification systématique pouvait rendre les activités malveillantes plus difficiles à distinguer des opérations normales exécutées en arrière-plan par l’agent.

L’impact démontré comprenait les possibilités suivantes :

• Rediriger le trafic de transcription vers un point de terminaison contrôlé par l’attaquant.
• Accéder potentiellement à des informations associées au compte Muse.
• Invoquer les fonctions de l’appareil accessibles à l’agent.
• Capturer des images sans notification fiable de l’utilisateur.
• Créer sur le disque des fichiers choisis par l’attaquant.

Ces résultats ne signifient pas que la vulnérabilité permettait à elle seule de prendre entièrement le contrôle d’un Mac connecté à Internet. L’attaquant devait toujours disposer d’un accès préalable, par exemple au moyen d’un logiciel malveillant déjà exécuté dans la session de l’utilisateur ou d’un logiciel que la victime avait été incitée à lancer.

À partir de là, toutefois, Muse pouvait réduire la quantité de fonctionnalités que l’attaquant devait implémenter directement. L’agent d’IA devenait de fait une ressource post-compromission.

Meta estime le risque concret faible

Meta a classé le problème comme une vulnérabilité d’élévation de privilèges locale. David Singleton, de Meta Superintelligence Labs, a déclaré que le risque concret pour les utilisateurs de Muse sur macOS était « assez faible », car l’exploitation supposait que du code malveillant soit déjà exécuté localement.

Cette évaluation tient à l’absence de mécanisme permettant un accès initial à distance. D’après le scénario d’attaque connu, un site web, une requête réseau ou un internaute non authentifié ne pouvait pas exploiter seul la vulnérabilité.

Cette condition préalable n’élimine pas le risque. Les intrusions sur les terminaux se déroulent fréquemment en plusieurs étapes, et les attaquants combinent régulièrement une technique d’exécution initiale avec des mécanismes qui étendent l’accès, volent des informations ou détournent des logiciels de confiance.

Dans ce cas, la valeur de la vulnérabilité résidait dans ce qu’elle permettait après l’exécution locale. Un attaquant ne disposant que d’un logiciel malveillant limité, exécuté sous l’identité de la victime, pouvait potentiellement détourner la relation entre Muse et le compte, le flux de travail cloud, l’accès aux fichiers et les fonctions liées à la caméra.

Aucune exploitation réelle n’a été signalée. Les attaques connues étaient des démonstrations de faisabilité, et non des activités confirmées visant des clients de Muse.

Aucun identifiant CVE n’a non plus été communiqué. Par conséquent, aucune entrée correspondante dans le catalogue CISA Known Exploited Vulnerabilities ni aucune échéance fédérale de remédiation n’a été identifiée pour ce problème.

Le correctif est arrivé rapidement, mais les détails de version restent inconnus

Meta a publié un correctif d’urgence quelques heures après la divulgation de la vulnérabilité par Ars Technica. L’article consacré à la réaction de Meta indique que la mise à jour corrigeait le mécanisme de configuration exposé.

Cette réaction rapide réduit la période durant laquelle une installation non corrigée reste vulnérable, mais l’absence d’informations précises sur la publication complique les vérifications. Meta n’a pas indiqué publiquement :

• Les versions vulnérables de l’application Muse.
• La première version ou le premier build corrigé.
• Un numéro CVE.
• Un avis technique complet.
• Des empreintes de fichiers ou d’autres indicateurs liés à l’exploitation.

Les administrateurs ne peuvent pas s’appuyer sur une limite de version clairement définie au vu des informations disponibles. Ils doivent installer la dernière mise à jour de Muse proposée par Meta et vérifier, au moyen de leurs outils de déploiement, que le correctif d’urgence a bien été installé sur chaque Mac géré.

Lorsque cette vérification n’est pas possible, les organisations qui traitent des conversations sensibles, des identifiants ou des informations propriétaires devraient envisager de suspendre l’utilisation de Muse jusqu’à ce que l’application corrigée puisse être vérifiée.

Les défenseurs doivent rechercher des comportements plutôt que des indicateurs figés

Aucun domaine malveillant, aucune empreinte de fichier ni aucune campagne nommée n’a été associé à cette vulnérabilité. La détection repose donc sur l’analyse des comportements observés sur les terminaux et le réseau.

Les équipes de sécurité doivent examiner les Mac exécutant Muse afin de repérer les connexions sortantes de l’application vers des hôtes inattendus, en particulier le trafic associé au traitement des transcriptions. Toute connexion vers une infrastructure extérieure à l’environnement attendu de Meta doit faire l’objet d’une investigation.

D’autres signaux utiles comprennent :

• Des modifications inattendues des valeurs de configuration non documentées de Muse.
• Une activité liée à la caméra ou à la capture d’images impliquant le processus Muse.
• Des fichiers créés par Muse dans des répertoires inhabituels.
• La création de fichiers suspects au moment d’une activité de Muse ou peu après.
• Des processus enfants non autorisés lancés par Muse ou à proximité de celui-ci.
• Une redirection réseau inhabituelle associée aux sessions de transcription.
• L’exécution d’applications non fiables sous le compte de l’utilisateur concerné.

Un événement suspect impliquant Muse doit également déclencher une investigation plus large du terminal. Puisque l’exploit nécessite une exécution préalable de code en local, tout indice de tentative d’exploitation peut signaler que le Mac était déjà compromis par un autre moyen.

Les contrôles applicatifs peuvent réduire l’exposition en empêchant l’exécution de logiciels inconnus ou non approuvés sur les systèmes où Muse est installé. Les solutions de détection sur les terminaux doivent également surveiller l’accès aux ressources liées à la caméra, les modifications de la configuration des applications et les relations inhabituelles entre processus et réseau.

La croissance de Muse accentue le coût d’un cloisonnement insuffisant des agents

La vulnérabilité est apparue alors que Meta mettait en avant la confidentialité et la sécurité de Muse, tout en positionnant le produit face à d’autres fournisseurs d’IA. Son lancement aurait suscité un intérêt considérable : les téléchargements mobiles estimés aux États-Unis et au Canada au cours des douze premiers jours de Muse auraient dépassé les téléchargements estimés de ChatGPT pendant ses douze premiers jours correspondants sur ces marchés.

L’action Meta a également progressé de 11 % lundi. Parallèlement, Muse a fait l’objet d’autres critiques que celles liées à la faille macOS. Amazon aurait bloqué l’agent sur sa plateforme de commerce électronique et accusé Meta de ne pas disposer de l’autorisation nécessaire pour cet accès.

Ce problème de sécurité met en lumière une préoccupation architecturale plus large concernant les agents d’IA. Un assistant ayant accès à des comptes cloud, à des microphones, à des caméras, à des fichiers et à des services externes peut concentrer des capacités que les attaquants devraient autrement réunir séparément.

Un cloisonnement strict doit donc couvrir bien davantage que le modèle lui-même. Les interfaces de configuration, les destinations cloud, les autorisations interapplications, les jetons de compte, les fonctions de l’appareil et les notifications destinées à l’utilisateur font tous partie de la frontière de sécurité de l’agent.

Le correctif de Meta corrige la faiblesse signalée. L’incident montre néanmoins comment un terminal compromis peut transformer les autorisations légitimes d’un assistant d’IA en raccourci pour un attaquant.