Meta suspend le partage des conversations Muse après une fuite DNS exposant des données privées

Meta a temporairement désactivé la fonctionnalité de partage de liens pour son assistant IA Muse après que des chercheurs en sécurité ont découvert que des milliers de conversations privées étaient publiquement accessibles. Cette faille permettait à quiconque ayant accès aux enregistrements DNS publics de reconstituer les URL et de consulter des données sensibles, notamment des revues financières et des notes d'entretien d'embauche.

Ce qui s'est passé

La société de sécurité Claroc a publié cette semaine un rapport détaillant comment elle a localisé plus de 6 800 liens de conversation Muse en scannant les enregistrements DNS publics. Ces enregistrements agissent comme un annuaire pour le trafic web, associant les noms de domaine aux adresses IP. Comme l'implémentation de Meta incluait des éléments prévisibles dans la structure des URL, les chercheurs ont pu inverser la conception des liens sans avoir besoin d'un accès direct aux comptes utilisateurs ou aux bases de données privées. Les conversations exposées contenaient des informations hautement sensibles, telles que la revue des revenus d'une agence marketing, une demande de prêt d'un petit entrepreneur, le calendrier complet du personnel d'une entreprise sur l'année entière, et des notes de préparation pour un candidat passant un entretien avec un laboratoire d'IA.

En réponse à ces découvertes, Meta a confirmé avoir mis en pause la fonctionnalité permettant aux utilisateurs de partager des artefacts spécifiques de Muse. Tracy Clayton, porte-parole de Muse, a déclaré que bien que la fonctionnalité ait été conçue pour permettre aux gens de partager des pages avec ceux disposant du lien, l'entreprise examine désormais le rapport afin de déterminer comment mieux protéger ces liens contre leur découverte. Cet incident met en lumière un problème récurrent dans l'industrie de l'IA, où les fonctionnalités de partage de plateformes comme ChatGPT d'OpenAI, Claude d'Anthropic et Grok de xAI ont déjà entraîné l'apparition de chats privés dans les résultats des moteurs de recherche.

Comment cela fonctionne

La vulnérabilité provenait de la manière dont Muse construisait les adresses web pour les conversations partagées. Selon Claroc, l'URL de chaque partage était constituée de trois composants : le titre du partage, une courte phrase décrivant la conversation et un ID aléatoire. Bien que l'ID offrait une certaine randomness, l'inclusion du titre et de la phrase descriptive rendait les URL partiellement prévisibles. Plus critique encore, le nom d'hôte lui-même révélait souvent le type de contenu avant même que la page ne soit ouverte.

Comme ces noms d'hôtes et les enregistrements associés étaient publiés dans les journaux DNS publics, les chercheurs pouvaient interroger ces annuaires pour trouver des sous-domaines Muse actifs. En combinant les données du nom d'hôte avec la structure d'URL connue, ils pouvaient reconstruire les liens complets. Cette méthode contournait tout contrôle de confidentialité prévu, car les liens ne nécessitaient aucune authentification ni autorisation supplémentaire pour être consultés une fois l'adresse correcte devinée ou reconstituée. Le système reposait sur une « sécurité par obscurité » via des IDs aléatoires, mais les métadonnées prévisibles et la visibilité publique de l'infrastructure ont miné cette protection.

Détails clés

• Les chercheurs de Claroc ont identifié plus de 6 800 liens Muse publiquement accessibles via les enregistrements DNS publics.
• Les données exposées incluaient des revues de revenus, des demandes de prêt, des calendriers du personnel et des notes d'entretien.
• Les URL de Muse étaient construites à partir d'un titre, d'une phrase descriptive et d'un ID aléatoire.
• Les enregistrements DNS publics ont révélé des noms d'hôtes aidant les chercheurs à reconstituer les liens complets.
• Meta a mis en pause la fonctionnalité de partage pendant qu'elle examine le rapport de sécurité.
• Des incidents similaires se sont produits avec les fonctionnalités de partage de ChatGPT, Claude et Grok.

Pourquoi c'est important

Pour les ingénieurs logiciels et les fondateurs techniques, cet incident sert de rappel sévère que la génération d'IDs uniques n'est pas suffisante pour sécuriser les ressources partagées. Lors de la création de fonctionnalités permettant aux utilisateurs de partager du contenu via des liens, compter uniquement sur des jetons impossibles à deviner est risqué si d'autres parties de l'URL ou les métadonnées de l'infrastructure fuient des informations. Les enregistrements DNS publiquement visibles, les journaux de serveur ou même les indices côté client peuvent fournir aux attaquants les pièces manquantes nécessaires pour énumérer les ressources valides. Cela est particulièrement critique pour les applications d'IA où les utilisateurs peuvent coller involontairement des données d'entreprise sensibles dans les interfaces de chat, supposant que les paramètres de confidentialité par défaut de la plateforme sont robustes.

De plus, cela souligne l'importance des stratégies de défense en profondeur pour les actifs partagés. Un mécanisme de partage sécurisé ne doit pas seulement utiliser des identifiants aléatoires cryptographiquement forts, mais aussi appliquer des contrôles d'accès, tels que des dates d'expiration, une protection par mot de passe ou une authentification utilisateur explicite. Sans ces couches, toute fuite de la structure d'URL ou des métadonnées peut entraîner une exposition massive de données privées. Les équipes développant des produits alimentés par l'IA doivent considérer les liens partagés comme publics par défaut, sauf s'ils sont explicitement sécurisés par des barrières supplémentaires, garantissant que même si un lien est découvert, le contenu reste inaccessible aux parties non autorisées.

Ce que vous pouvez faire

• Auditez votre logique de génération d'URL pour vous assurer qu'aucune métadonnée prévisible, telle que des titres ou des horodatages, n'est incluse dans les liens publics.
• Implémentez des contrôles d'accès stricts pour les ressources partagées, exigeant une authentification ou des mots de passe à usage unique plutôt que de compter uniquement sur le secret du lien.
• Surveillez les enregistrements DNS publics et les journaux de transparence des certificats pour vos domaines afin de détecter l'exposition involontaire de sous-domaines ou de services.
• Définissez des délais d'expiration automatiques pour tous les liens partagés afin de limiter la fenêtre de vulnérabilité si un lien est divulgué.
• Sensibilisez les utilisateurs aux risques liés au collage de données sensibles dans les outils d'IA, même lorsqu'ils utilisent des plateformes internes ou de niveau entreprise.
• Effectuez des tests d'intrusion réguliers axés sur les attaques par énumération pour identifier si les IDs de ressources peuvent être devinés ou reconstitués.