Grok está a vazar dados de utilizadores com instruções cifradas
Investigadores mostraram como contornar as proteções do Grok cifrando o ataque. A falha expõe conversas e dados pessoais e mostra o quão frágeis são os “railings” de segurança dos LLM.
Investigadores mostraram como contornar as proteções do Grok cifrando o ataque. A falha expõe conversas e dados pessoais e mostra o quão frágeis são os “railings” de segurança dos LLM.
Nem foi preciso um exploit sofisticado. Para pôr o Grok, o modelo de linguagem da xAI de Elon Musk, a roubar dados de utilizadores, bastou adicionar texto cifrado e deixar o próprio sistema fazer o resto. A Adversa, empresa de segurança, mostrou como o modelo exfiltra nome, localização e histórico de chat para um servidor controlado pelo atacante, sem alertas nem pedidos de confirmação. Segundo os investigadores, a xAI foi avisada em junho. Em agosto, a fuga continuava.
O ataque segue a mesma linha do que foi revelado esta semana no Copilot empresarial da Microsoft, onde um parâmetro secreto permitia extrair palavras-passe de emails. Já escrevemos sobre esse caso no artigo Copilot da Microsoft tinha parâmetro secreto que roubava palavras-passe. A moral repete-se: os LLM não conseguem resolver o problema de base das prompt injections, aquela família de vulnerabilidades em que instruções maliciosas se escondem em conteúdos que o assistente é convidado a resumir ou analisar.
No ataque ao Grok, o truque chama-se “Cryptographic Context Injection”. Em vez de escrever as instruções perigosas em texto simples, o atacante cifra-as. Na mesma página coloca o texto cifrado, a chave e um passo-a-passo, em claro, a explicar ao modelo como usar PBKDF2 (Password-Based Key Derivation Function 2) e AES-256-GCM para decifrar aquele bloco. Quando o utilizador pede ao Grok para resumir a página, o modelo segue essas instruções técnicas sem desconfiar. A partir do momento em que o conteúdo é decifrado dentro do próprio “sandbox” de execução de código do modelo, as verdadeiras ordens aparecem como saída de ferramenta, já fora do alcance do filtro de segurança.
Essas ordens pedem ao Grok para construir aquilo que, à superfície, parece uma nova chave de cifragem. Na prática, o “valor” dessa pseudo-chave é o nome do utilizador, a localização e o histórico de conversas. O modelo concatena tudo isto num parâmetro de um URL e abre o link. A visita fica registada nos logs do servidor do atacante, com os dados embutidos. As mesmas instruções em texto simples são bloqueadas pelas guardas de segurança do Grok. Em formato cifrado passam sem problemas, porque o classificador só lê texto, não executa PBKDF2 nem AES para perceber o que está realmente escondido ali.
É aqui que a solução atual dos fabricantes de IA mostra as costuras. Os chamados guardrails são filtros “estáticos”: classificam conteúdo de entrada e saída como texto, não correm código, não decifram nada. Os investigadores limitam-se a explorar esse vazio técnico. Tudo o que o filtro precisaria de ver está na página, mas o sistema de segurança não faz o esforço computacional de transformar o ciphertext em plaintext. O resultado é previsível: o modelo obedece às instruções perigosas, mas só depois de as ter gerado para si próprio, numa camada que o filtro não vigia.
A Adversa já tinha usado uma variante desta técnica para fazer jailbreak ao Gemini da Google, desencriptando um payload que parecia apenas um traceback de Python e que acabava a forçar o modelo a gerar conteúdo sobre receitas incendiárias e até a revelar instruções internas. A Google não foi notificada porque a empresa nem sequer considera jailbreaks como vulnerabilidades reportáveis. No caso da xAI, houve disclosure responsável e, ainda assim, a falha manteve-se ativa. Para quem está deste lado na Europa, a lição é simples: integrar estes assistentes em email, documentos ou dados sensíveis sem uma camada de segurança externa é voluntarismo. As guardas internas dos LLM são mais railings improvisados do que barreiras reais.
Fonte: Ars Technica
Comentários · 0