Resumo:
O recém-lançado assistente de IA da Meta, Muse, foi exposto a uma grave vulnerabilidade de segurança de dia zero. O Muse para macOS possui permissões de sistema extremamente amplas. Uma vez explorado, um invasor pode obter o token usado para verificar a identidade da conta do Muse por meio de aplicativos locais ou até mesmo comandos de terminal e controlar ainda mais toda a conta do assistente de IA.
Pesquisadores de segurança disseram que isso significa que os invasores podem realizar um grande número de operações de alto risco com as permissões obtidas pelo próprio Muse, incluindo gravação de arquivos maliciosos, tirar fotos e ler dados do usuário.

Muse é um novo agente de IA lançado recentemente pela Meta. Ele pode realizar operações como marcar compromissos, preencher formulários, tratar de questões de atendimento ao cliente e fazer compras em nome dos usuários. Ele também pode gerar imagens, criar documentos e conectar-se a aplicativos e serviços online comumente usados pelos usuários. Atualmente, o Muse oferece uma versão para macOS, e uma versão para Windows ainda não foi lançada. Para que o Muse conclua essas tarefas, os usuários precisam conceder acesso ao WhatsApp, e-mail, calendário e contas de mídia social.
Ao contrário dos chatbots comuns, o Muse é um agente de IA que pode realmente realizar operações em nome do usuário. Ele pode até criar dinamicamente as ferramentas necessárias ao executar uma tarefa. Portanto, o Muse deve obter permissões de sistema muito mais amplas do que os aplicativos tradicionais de bate-papo com IA.
No macOS, o Muse precisa obter uma série de permissões protegidas pelo sistema operacional, incluindo gravação de arquivos em disco, acesso ao microfone e à câmera, obtenção de localização e acesso ao calendário. A razão pela qual a Apple projetou essas restrições de permissão do sistema é evitar que aplicativos ou programas comuns executados no terminal chamem esses recursos confidenciais à vontade.
No entanto, os pesquisadores de segurança descobriram que o design do Muse, na verdade, ignora alguns dos mecanismos de isolamento de segurança fornecidos originalmente pelo macOS.
A vulnerabilidade foi descoberta pelo especialista em segurança do macOS, Patrick Wardle. Ele descobriu que qualquer aplicativo instalado localmente ou código em execução, não importa quão limitadas sejam as permissões do macOS, pode modificar um grande número de configurações internas não divulgadas do Muse.
A grande maioria dessas configurações em si não representa um risco óbvio à segurança, como a alteração de opções da interface do usuário, como o modo escuro. Mas uma configuração é crucial porque permite que o processo modifique os terminais de rede usados pelo Muse para transcrição de fala.
Em circunstâncias normais, o Muse enviará a solicitação de transcrição de fala ao servidor operado pela Meta. No entanto, um invasor pode aproveitar a vulnerabilidade e alterar esse endereço para um servidor que ele controla. Assim que o Muse começar a enviar solicitações ao servidor malicioso, o token usado para autenticar a conta do usuário do Muse também poderá ser obtido pelo invasor.

Depois que esse token for obtido, o invasor não controlará mais apenas uma solicitação de voz, mas poderá obter controle contínuo sobre toda a conta do Muse. Wardle disse que os invasores podem usar diretamente os altos privilégios que o Muse obteve para concluir várias operações sem ter que escrever especialmente um conjunto complexo de malware para macOS.
Wardle produziu vários ataques de prova de conceito, incluindo o uso do Muse para gravar arquivos maliciosos em disco e chamar a câmera para tirar fotos. Em alguns testes, mesmo um usuário muito alerta pode não ver avisos de segurança óbvios.
Isso significa que o Muse tem um problema especial de segurança: o invasor não precisa necessariamente obter primeiro o controle completo do próprio Muse, mas apenas encontrar um ponto de entrada que permita a execução de código malicioso no Mac e possa explorar ainda mais os privilégios de sistema que o Muse obteve.
Um tipo de ataque em particular merece destaque, o chamado ataque ClickFix. ClickFix se tornou um meio muito eficaz de ataques de engenharia social nos últimos anos. Seu método básico é enganar os usuários para que executem operações ou comandos aparentemente normais, mas na verdade eles executam código malicioso fornecido pelo invasor no dispositivo.
Wardle disse que com uma simples modificação neste método de ataque, é possível controlar ainda mais a conta do Muse. Isso também faz com que a sabedoria convencional de que “todas as medidas de segurança sejam inúteis se o seu Mac for comprometido” não é inteiramente aplicável ao Muse.
A razão é que as consequências dos ataques a aplicações comuns e dos ataques a agentes de IA são diferentes. O próprio Muse obteve um grande número de permissões para acessar dados do usuário e realizar operações reais. Portanto, desde que um invasor possa usar o Muse para completar o escalonamento de permissões, um ataque local original com permissões muito limitadas pode ser transformado em controle em larga escala do agente de IA.
Um invasor também pode usar proxies de rede para lançar ataques. Uma maneira é ter um servidor controlado pelo invasor entre o usuário Muse e o servidor Meta. Quando um usuário insere um comando de voz no Muse, um invasor pode inserir um prompt malicioso na solicitação para induzir o Muse a realizar a operação que o invasor deseja concluir, como exigir que o Muse empacote todas as mensagens do WhatsApp do usuário e as envie ao invasor.
O que é mais sério é que, uma vez que o token de autenticação do Muse também é enviado para um servidor malicioso, o invasor pode obter controle contínuo sobre a conta do Muse, em vez de apenas concluir um ataque.
Wardle acredita que diversas decisões de design no Muse se combinaram para criar a vulnerabilidade. Uma das principais questões é a escolha da Meta de permitir que o Muse conclua a transcrição da fala na nuvem.
O próprio macOS há muito fornece mecanismos para completar o ditado e a transcrição localmente no dispositivo. Se a Meta optasse por manter dados de voz confidenciais dentro do dispositivo, o ataque do invasor modificando o endereço do servidor de transcrição em nuvem não seria viável.
Outro problema é que o Muse permite que qualquer aplicativo local controle um grande número de configurações não reveladas. Wardle acredita que Meta pode originalmente querer apenas permitir que aplicativos que colaboram com o Muse ajustassem os parâmetros relacionados à interface do usuário, e esse design em si tem uma certa racionalidade. Mas permitir que qualquer aplicativo altere os endpoints do servidor que lidam com dados de voz confidenciais é um risco de segurança totalmente diferente.
Wardle acredita que essas decisões de design levantam uma questão maior sobre quantas considerações de segurança a Meta colocou ao projetar e testar o Muse. Ele disse que para aplicações de IA com permissões de sistema tão amplas, os requisitos de segurança deveriam ser muito maiores do que os do software comum.
A Meta publicou anteriormente dois artigos consecutivos detalhando as medidas que o Muse tomou para privacidade e segurança durante o processo de design. O fundador e CEO da Meta, Mark Zuckerberg, também enfatizou que o Muse foi projetado de acordo com os requisitos de privacidade e segurança desde o início.
No entanto, a exposição da vulnerabilidade de dia zero contrasta claramente com o conceito de segurança que a Meta enfatizou anteriormente. Especialmente no contexto dos recentes incidentes de segurança que ocorreram noutros modelos de IA, a questão de os agentes de IA obterem cada vez mais permissões operacionais práticas está a atrair a atenção dos investigadores de segurança.
Anteriormente, os modelos Anthropic e Google tiveram incidentes de segurança envolvendo redes externas de terceiros durante testes internos. Embora os testes não se destinassem a atacar estas redes, a capacidade dos sistemas de IA agirem de forma autónoma tem suscitado discussões contínuas no domínio da segurança.
Ao mesmo tempo, a Amazon começou a impedir o Muse de fazer compras em seu site cerca de 12 horas antes de a vulnerabilidade se tornar pública. Quando os usuários tentarem pedir ao Muse para fazer compras na Amazon, eles verão um aviso da Amazon dizendo que o Muse é um agente de IA não autorizado e viola os termos de uso da Amazon.
A Amazon disse que aplicativos de terceiros que permitem compras de outras empresas em nome dos clientes devem operar de forma aberta e transparente e respeitar a decisão do provedor de serviços de permitir que eles participem de transações. A Amazon acredita que isso é semelhante ao relacionamento entre plataformas de entrega e restaurantes, plataformas de entrega e lojas, e agentes de viagens e companhias aéreas online. Os agentes de IA que podem realizar transações em nome dos consumidores também precisam respeitar este princípio.
A Amazon também pediu à Meta que removesse sua plataforma da experiência de compra do Muse.
As medidas restritivas tomadas pela Amazon desta vez também ocorrem no contexto da competição entre Meta e Amazon em torno da compra de agentes de IA. No futuro, os agentes de IA poderão navegar diretamente em sites, selecionar produtos e concluir pagamentos para usuários. Portanto, como identificar sites tradicionais e permitir que agentes de IA os acessem está se tornando uma nova questão comercial e técnica.
A Meta ainda não respondeu a questões específicas levantadas pela mídia sobre esta vulnerabilidade de dia zero, por isso não está claro se a empresa desenvolveu um patch, se começou a enviar atualizações de correção para os usuários afetados e se esta vulnerabilidade foi realmente explorada antes de ser descoberta pelos pesquisadores.
Wardle disse que planeja introduzir ainda mais essa vulnerabilidade e discutir outras ameaças à segurança que os assistentes de IA podem representar na conferência de segurança Objective by the Sea, em novembro deste ano. Ele também acredita que os padrões de segurança dos agentes de IA devem ser significativamente mais elevados do que os dos aplicativos comuns, porque para completar tarefas autorizadas pelos usuários, esse software muitas vezes precisa acessar contas, comunicações, arquivos, câmeras, microfones e outros recursos sensíveis ao mesmo tempo.
Os problemas expostos pelo Muse desta vez também mostram que existem diferenças óbvias nos modelos de segurança dos agentes de IA e dos aplicativos tradicionais. Mesmo que ocorram vulnerabilidades em software tradicional, os invasores geralmente ainda precisam obter permissões de sistema gradualmente; Os próprios agentes de IA são projetados para realizar operações em nome dos usuários. Portanto, uma vez que haja falhas em seu mecanismo de autenticação ou limites de permissão, os invasores podem usar diretamente as permissões originalmente obtidas legalmente do agente de IA para concluir operações de alto risco.
O escopo específico do impacto desta vulnerabilidade e o progresso do reparo do Meta ainda precisam ser confirmados. Mas para os utilizadores que necessitam de agentes de IA para se ligarem a e-mail, mensagens instantâneas, calendário, redes sociais e serviços de pagamento e compras, o incidente do Muse destaca mais uma vez uma questão central: quanto mais permissões um assistente de IA tiver, maior será a importância do seu próprio mecanismo de segurança.
Comentários