Muse, el privilegiado asistente de IA de Meta, expone una grave vulnerabilidad de día cero, la aplicación local puede tomar el control

Resumen:

Muse, el asistente de inteligencia artificial recientemente lanzado por Meta, estuvo expuesto a una grave vulnerabilidad de seguridad de día cero. Muse para macOS tiene permisos de sistema extremadamente amplios. Una vez explotado, un atacante puede obtener el token utilizado para verificar la identidad de la cuenta de Muse a través de aplicaciones locales o incluso comandos de terminal, y controlar aún más toda la cuenta del asistente de IA.

Muse es un nuevo agente de IA lanzado recientemente por Meta. Puede completar operaciones como programar citas, completar formularios, manejar asuntos de servicio al cliente y comprar en nombre de los usuarios. También puede generar imágenes, crear documentos y conectarse a las aplicaciones y servicios en línea más utilizados por los usuarios. Actualmente, Muse ofrece una versión para macOS y aún no se ha lanzado una versión para Windows. Para que Muse pueda completar estas tareas, los usuarios deben otorgarle acceso a WhatsApp, correo electrónico, calendario y cuentas de redes sociales.

A diferencia de los chatbots comunes, Muse es un agente de inteligencia artificial que realmente puede realizar operaciones en nombre del usuario. Incluso puede crear dinámicamente las herramientas que necesita mientras ejecuta una tarea. Por lo tanto, Muse debe obtener permisos del sistema mucho más amplios que las aplicaciones tradicionales de chat de IA.

En macOS, Muse necesita obtener una serie de permisos protegidos por el sistema operativo, que incluyen escribir archivos en el disco, acceder al micrófono y la cámara, obtener la ubicación y acceder al calendario. La razón por la que Apple diseñó estas restricciones de permisos del sistema es para evitar que las aplicaciones o programas ordinarios ejecutados en el terminal llamen a estos recursos confidenciales a voluntad.

Sin embargo, los investigadores de seguridad descubrieron que el diseño de Muse en realidad pasa por alto algunos de los mecanismos de aislamiento de seguridad proporcionados originalmente por macOS.

La vulnerabilidad fue descubierta por el experto en seguridad de macOS, Patrick Wardle. Descubrió que cualquier aplicación instalada localmente o código en ejecución, sin importar cuán limitados sean los permisos de macOS que tenga, puede modificar una gran cantidad de configuraciones internas no reveladas de Muse.

La gran mayoría de estas configuraciones en sí mismas no representan un riesgo de seguridad obvio, como cambiar las opciones de la interfaz de usuario, como el modo oscuro. Pero una configuración es crucial porque permite que el proceso modifique los puntos finales de red utilizados por Muse para la transcripción de voz.

En circunstancias normales, Muse enviará la solicitud de transcripción de voz al servidor operado por Meta. Sin embargo, un atacante puede aprovechar la vulnerabilidad y cambiar esta dirección a un servidor que él controle. Una vez que Muse comienza a enviar solicitudes al servidor malicioso, el atacante también puede obtener el token utilizado para autenticar la cuenta de Muse del usuario.

Una vez que se obtiene este token, el atacante ya no controla solo una solicitud de voz, sino que puede obtener control continuo sobre toda la cuenta de Muse. Wardle dijo que los atacantes pueden usar directamente los altos privilegios que Muse ha obtenido para completar varias operaciones sin tener que escribir especialmente un conjunto complejo de malware para macOS.

Wardle ha producido múltiples ataques de prueba de concepto, incluido el uso de Muse para escribir archivos maliciosos en el disco y llamar a la cámara para tomar fotografías. En algunas pruebas, incluso un usuario muy alerta podría no ver advertencias de seguridad obvias.

Esto significa que Muse tiene un problema de seguridad especial: el atacante no necesita necesariamente obtener primero el control completo de Muse, sino que sólo necesita encontrar un punto de entrada que permita que el código malicioso se ejecute en el Mac y pueda explotar aún más los privilegios del sistema que Muse ha obtenido.

Vale la pena destacar un tipo de ataque en particular, el llamado ataque ClickFix. ClickFix se ha convertido en los últimos años en un medio muy eficaz de ataques de ingeniería social. Su método básico es engañar a los usuarios para que realicen operaciones o comandos aparentemente normales, pero en realidad ejecutan código malicioso proporcionado por el atacante en el dispositivo.

Wardle dijo que con una simple modificación de este método de ataque, es posible controlar aún más la cuenta de Muse. Esto también hace que la sabiduría convencional de que "todas las medidas de seguridad no tengan sentido si su Mac ha sido comprometida" no sea del todo aplicable a Muse.

La razón es que las consecuencias de los ataques a aplicaciones ordinarias y los ataques a agentes de IA son diferentes. La propia Muse ha obtenido una gran cantidad de permisos para acceder a los datos del usuario y realizar operaciones reales. Por lo tanto, siempre que un atacante pueda usar Muse para completar la escalada de permisos, un ataque local original con permisos muy limitados puede transformarse en un control a gran escala del agente de IA.

Un atacante también puede utilizar servidores proxy de red para lanzar ataques. Una forma es tener un servidor controlado por el atacante entre el usuario de Muse y el metaservidor. Cuando un usuario ingresa un comando de voz en Muse, un atacante puede insertar un mensaje malicioso en la solicitud para inducir a Muse a realizar la operación que el atacante desea completar, como requerir que Muse empaquete todos los mensajes de WhatsApp del usuario y se los envíe al atacante.

Lo que es más grave es que una vez que el token de autenticación de Muse también se envía a un servidor malicioso, el atacante puede obtener control continuo sobre la cuenta de Muse en lugar de simplemente completar un ataque.

Wardle cree que múltiples decisiones de diseño en Muse se combinaron para crear la vulnerabilidad. Una de las cuestiones clave es la elección de Meta de permitir que Muse complete la transcripción de voz en la nube.

El propio macOS ha proporcionado durante mucho tiempo mecanismos para completar el dictado y la transcripción localmente en el dispositivo. Si Meta optara por mantener datos de voz confidenciales dentro del dispositivo, el ataque del atacante modificando la dirección del servidor de transcripción en la nube no sería factible.

Otro problema es que Muse permite que cualquier aplicación local controle una gran cantidad de configuraciones no reveladas. Wardle cree que Meta originalmente solo quería permitir que las aplicaciones que colaboran con Muse ajusten los parámetros relacionados con la interfaz de usuario, y este diseño en sí tiene cierta racionalidad. Pero permitir que cualquier aplicación altere los puntos finales del servidor que manejan datos de voz confidenciales es un riesgo de seguridad completamente diferente.

Wardle cree que estas decisiones de diseño plantean una pregunta más amplia sobre cuántas consideraciones de seguridad puso Meta en el diseño y prueba de Muse. Dijo que para las aplicaciones de IA con permisos de sistema tan amplios, los requisitos de seguridad deberían ser mucho más altos que los del software ordinario.

Meta ha publicado anteriormente dos artículos consecutivos que detallan las medidas que Muse ha tomado para la privacidad y la seguridad durante el proceso de diseño. El fundador y director ejecutivo de Meta, Mark Zuckerberg, también ha enfatizado que Muse ha sido diseñado de acuerdo con los requisitos de privacidad y seguridad desde el principio.

Sin embargo, la exposición de la vulnerabilidad de día cero contrasta claramente con el concepto de seguridad que Meta ha enfatizado anteriormente. Especialmente en el contexto de los recientes incidentes de seguridad que han ocurrido en otros modelos de IA, la cuestión de que los agentes de IA obtengan cada vez más permisos operativos prácticos está atrayendo la atención de los investigadores de seguridad.

Anteriormente, los modelos de Anthropic y Google tuvieron incidentes de seguridad que involucraron redes externas de terceros durante las pruebas internas. Aunque las pruebas no tenían como objetivo atacar estas redes, la capacidad de los sistemas de inteligencia artificial para actuar de forma autónoma ha provocado debates en curso en el campo de la seguridad.

Al mismo tiempo, Amazon comenzó a impedir que Muse comprara en su sitio web unas 12 horas antes de que la vulnerabilidad se hiciera pública. Cuando los usuarios intenten pedirle a Muse que compre en Amazon, verán un mensaje de Amazon que indica que Muse es un agente de inteligencia artificial no autorizado y viola los términos de uso de Amazon.

Amazon dijo que las aplicaciones de terceros que permiten compras de otras empresas en nombre de los clientes deben operar de forma abierta y transparente y respetar la decisión del proveedor de servicios de permitirles participar en las transacciones. Amazon cree que esto es similar a la relación entre las plataformas de comida para llevar y los restaurantes, las plataformas y tiendas de entrega, y las agencias de viajes en línea y las aerolíneas. Los agentes de IA que pueden realizar transacciones en nombre de los consumidores también deben cumplir con este principio.

Amazon también pidió a Meta que eliminara su plataforma de la experiencia de compra de Muse.

Las medidas restrictivas adoptadas por Amazon esta vez también se producen en el contexto de la competencia entre Meta y Amazon en torno a la compra de agentes de IA. En el futuro, los agentes de IA podrán navegar directamente por sitios web, seleccionar productos y completar pagos para los usuarios. Por lo tanto, cómo identificar los sitios web tradicionales y si permitir que los agentes de IA accedan a ellos se está convirtiendo en una nueva cuestión comercial y técnica.

Meta aún tiene que responder a preguntas específicas planteadas por los medios sobre esta vulnerabilidad de día cero, por lo que no está claro si la compañía ha desarrollado un parche, si ha comenzado a enviar actualizaciones de corrección a los usuarios afectados y si esta vulnerabilidad fue realmente explotada antes de ser descubierta por los investigadores.

Wardle dijo que planea presentar más esta vulnerabilidad y discutir otras amenazas a la seguridad que los asistentes de IA pueden plantear en la conferencia de seguridad Objective by the Sea en noviembre de este año. También cree que los estándares de seguridad de los agentes de IA deben ser significativamente más altos que los de las aplicaciones ordinarias, porque para completar las tareas autorizadas por los usuarios, dicho software a menudo necesita acceder a cuentas, comunicaciones, archivos, cámaras, micrófonos y otros recursos sensibles al mismo tiempo.

Los problemas expuestos por Muse esta vez también muestran que existen diferencias obvias en los modelos de seguridad de los agentes de IA y las aplicaciones tradicionales. Incluso si se producen vulnerabilidades en el software tradicional, los atacantes normalmente todavía necesitan obtener permisos del sistema gradualmente; Los propios agentes de IA están diseñados para realizar operaciones en nombre de los usuarios. Por lo tanto, una vez que hay fallas en su mecanismo de autenticación o límites de permisos, los atacantes pueden usar directamente los permisos originalmente obtenidos legalmente por el agente de IA para completar operaciones de alto riesgo.

El alcance del impacto específico de esta vulnerabilidad y el progreso de la reparación de Meta aún deben confirmarse. Pero para los usuarios que necesitan agentes de IA para conectarse al correo electrónico, mensajería instantánea, calendarios, redes sociales y servicios de pago y compras, el incidente de Muse resalta una vez más una cuestión central: cuantos más permisos tenga un asistente de IA, mayor será la importancia de su propio mecanismo de seguridad.