Meta detiene el uso compartido de Muse tras una filtración de DNS que expone datos privados

Meta ha deshabilitado temporalmente la función de compartir enlaces de su asistente de IA Muse después de que investigadores de seguridad descubrieran que miles de conversaciones privadas eran accesibles públicamente. La falla permitía que cualquier persona con acceso a registros DNS públicos reconstruyera las URL y viera datos sensibles, incluyendo revisiones financieras y notas de entrevistas de trabajo.

Qué ocurrió

La firma de seguridad Claroc publicó esta semana un informe detallando cómo localizaron más de 6.800 enlaces de conversaciones de Muse escaneando registros DNS públicos. Estos registros actúan como un directorio del tráfico web, mapeando nombres de dominio a direcciones IP. Debido a que la implementación de Meta incluía elementos predecibles en la estructura de la URL, los investigadores pudieron ingeniería inversa de los enlaces sin necesidad de acceso directo a cuentas de usuario o bases de datos privadas. Las conversaciones expuestas contenían información altamente sensible, como la revisión de ingresos de una empresa de marketing, la solicitud de préstamo de un pequeño empresario, el calendario completo de personal de un año laboral y notas de preparación para un candidato que se entrevistaba con un laboratorio de IA.

En respuesta a los hallazgos, Meta confirmó que ha pausado la funcionalidad que permite a los usuarios compartir artefactos específicos de Muse. Tracy Clayton, portavoz de Muse, declaró que si bien la función fue diseñada para permitir que las personas compartieran páginas con quienes tienen el enlace, la empresa está revisando ahora el informe para determinar cómo proteger mejor estos enlaces contra su descubrimiento. Este incidente destaca un problema recurrente en la industria de la IA, donde las funciones de uso compartido de plataformas como ChatGPT de OpenAI, Claude de Anthropic y Grok de xAI han resultado previamente en que chats privados aparezcan en resultados de motores de búsqueda.

Cómo funciona

La vulnerabilidad surgió de cómo Muse construía las direcciones web para las conversaciones compartidas. Según Claroc, la URL de cada elemento compartido se creaba utilizando tres componentes: el título del elemento compartido, una frase corta que describe la conversación y un ID aleatorio. Aunque el ID proporcionaba cierta aleatoriedad, la inclusión del título y la frase descriptiva hacía que las URLs fueran parcialmente predecibles. Más críticamente, el nombre de host en sí mismo a menudo revelaba el tipo de contenido antes de que la página fuera incluso abierta.

Debido a que estos nombres de host y registros asociados fueron publicados en logs DNS públicos, los investigadores podían consultar estos directorios para encontrar subdominios activos de Muse. Al combinar los datos del nombre de host con la estructura de URL conocida, podían reconstruir los enlaces completos. Este método evitaba cualquier control de privacidad previsto, ya que los enlaces no requerían autenticación ni permisos adicionales para verlos una vez que la dirección correcta era adivinada o reconstruida. El sistema dependía de la "seguridad por oscuridad" mediante IDs aleatorios, pero los metadatos predecibles y la visibilidad pública de la infraestructura socavaban esa protección.

Detalles clave

• Los investigadores de Claroc identificaron más de 6.800 enlaces de Muse accesibles públicamente a través de registros DNS públicos.
• Los datos expuestos incluyeron revisiones de ingresos, solicitudes de préstamos, calendarios de personal y notas de entrevistas.
• Las URLs de Muse se construían a partir de un título, una frase descriptiva y un ID aleatorio.
• Los registros DNS públicos revelaron nombres de host que ayudaron a los investigadores a reconstruir los enlaces completos.
• Meta ha pausado la función de uso compartido mientras revisa el informe de seguridad.
• Incidentes similares han ocurrido con las funciones de uso compartido de ChatGPT, Claude y Grok.

Por qué importa

Para ingenieros de software y fundadores técnicos, este incidente sirve como un claro recordatorio de que generar IDs únicos no es suficiente para asegurar recursos compartidos. Al construir funciones que permiten a los usuarios compartir contenido mediante enlaces, depender únicamente de tokens indescifrables es riesgoso si otras partes de la URL o los metadatos de la infraestructura filtran información. Los registros DNS visibles públicamente, los logs del servidor o incluso pistas del lado del cliente pueden proporcionar a los atacantes las piezas faltantes necesarias para enumerar recursos válidos. Esto es particularmente crítico para aplicaciones de IA donde los usuarios pueden pegar inadvertidamente datos corporativos sensibles en interfaces de chat, asumiendo que los ajustes de privacidad predeterminados de la plataforma son robustos.

Además, esto resalta la importancia de estrategias de defensa en profundidad para activos compartidos. Un mecanismo seguro de uso compartido no solo debe utilizar identificadores aleatorios criptográficamente fuertes, sino también aplicar controles de acceso, tales como fechas de caducidad, protección con contraseña o autenticación explícita de usuario. Sin estas capas, cualquier fuga de la estructura de la URL o de los metadatos puede llevar a una exposición masiva de datos privados. Los equipos que construyen productos impulsados por IA deben tratar los enlaces compartidos como públicos por defecto a menos que estén explícitamente asegurados con barreras adicionales, garantizando que, incluso si un enlace es descubierto, el contenido permanezca inaccesible para partes no autorizadas.

Qué puedes hacer

• Audita tu lógica de generación de URLs para asegurar que ningún metadato predecible, como títulos o marcas de tiempo, esté incluido en enlaces públicos.
• Implementa estrictos controles de acceso para recursos compartidos, requiriendo autenticación o contraseñas de un solo uso en lugar de depender únicamente del secreto del enlace.
• Monitorea registros DNS públicos y logs de transparencia de certificados para tus dominios para detectar exposiciones no intencionadas de subdominios o servicios.
• Establece tiempos de caducidad automáticos para todos los enlaces compartidos para limitar la ventana de vulnerabilidad si un enlace se filtra.
• Educa a los usuarios sobre los riesgos de pegar datos sensibles en herramientas de IA, incluso cuando utilizan plataformas internas o de grado empresarial.
• Realiza pruebas de penetración regulares enfocadas en ataques de enumeración para identificar si los IDs de recursos pueden ser adivinados o reconstruidos.