Pesquisadores detalham como um ataque de injeção de prompt superou as proteções de inteligência da Apple

Um problema corrigido permitiu que os pesquisadores superassem as restrições da Apple e forçassem o LLM no dispositivo a realizar ações sob controle do atacante. Veja como eles fizeram isso.

A Apple reforçou suas medidas contra esse ataque

Hoje, dois posts no blog da RSAC (1, 2) (AppleInsider) detalham como os pesquisadores combinaram duas estratégias de ataque para forçar o modelo nos dispositivos da Apple a executar instruções sob controle do atacante.

Curiosamente, os pesquisadores conseguiram realizar essa exploração com sucesso sem ter 100% de certeza sobre como a Apple lidou com uma parte do processo de filtragem de entrada e saída do modelo local, pois a Apple não divulga os detalhes internos de seus modelos por razões de segurança.

Ainda assim, os pesquisadores afirmam ter uma boa ideia do que está acontecendo por trás do motor.

Segundo eles, o cenário mais provável é que, após um usuário enviar um prompt para o modelo no dispositivo da Apple por meio de uma chamada de API, um filtro de entrada se assegure de que o pedido não contenha conteúdo inseguro.

Se esse for o caso, a API falha. Caso contrário, o pedido é enviado para o modelo no dispositivo real, e esse modelo responde a um filtro de saída que verifica se sua saída contém conteúdo inseguro; isso pode resultar na falha ou sucesso da API, dependendo do que encontrar.

Como eles fizeram isso

Tendo isso em mente, os pesquisadores descobriram que poderiam combinar duas técnicas de exploração para fazer o modelo da Apple ignorar suas diretrizes de segurança fundamentais e, ao mesmo tempo, convencer os filtros de entrada e saída a passar conteúdo malicioso.

Primeiro, eles inverteram a string maliciosa e, em seguida, usaram o caractere de transição UNICODE DA DIREITA PARA A ESQUERDA para garantir que ela fosse exibida corretamente na tela do usuário, enquanto mantinham a entrada e saída bruta invertida para a filtragem.

Em seguida, os pesquisadores incorporaram a string maliciosa invertida em um segundo método de ataque chamado Neural Exec, que é uma maneira complexa de contornar as instruções do modelo com novas instruções que um atacante poderia querer executar.

Como resultado, o ataque Unicode conseguiu superar os filtros de entrada e saída, enquanto o Neural Exec fez com que o modelo da Apple se comportasse mal.

Para avaliar a eficácia do ataque, estamos preparando três pools diferentes para criar prompts de entrada apropriados:

• Prompts do sistema: Uma série de prompts/tarefas do sistema (por exemplo, “Torne o texto fornecido conforme as regras de ortografia e pontuação do inglês americano”).
• Strings maliciosas: Strings criadas manualmente projetadas para serem consideradas ofensivas ou maliciosas (ou seja, as saídas que queremos forçar o modelo a gerar).
• Entradas inocentes: Parágrafos retirados aleatoriamente de artigos da Wikipedia, usados para simular entradas não ofensivas e que parecem inocentes (por exemplo, no contexto de injeção de prompt indireta através de sistemas como RAG ou similares).

Durante a avaliação, pegamos aleatoriamente um item de cada pool, criamos um prompt completo, geramos uma carga útil (veja abaixo), injetamos isso e testamos se o ataque foi bem-sucedido ao executar o modelo no dispositivo da Apple.

Em seus testes, os atacantes alcançaram uma taxa de sucesso de 76% em 100 prompts aleatórios.

Eles relataram o ataque à Apple em outubro de 2025, e a empresa "reforçou os sistemas afetados por esse ataque, e essas proteções foram implementadas no iOS 26.4 e no macOS 26.4."

Para ler o relatório completo, siga este link, que também contém uma ligação para os aspectos técnicos do ataque.

Vale a pena conferir na Amazon

• David Pogue – 'Apple: Os Primeiros 50 Anos'
• MacBook Neo
• Logitech MX Master 4
• AirPods Pro 3
• AirTag (2ª Geração) – Pacote com 4
• Apple Watch Series 11
• Adaptador CarPlay sem fio