Exfiltração de dados no Slack AI por meio de injeção indireta de prompt
(substack.com/promptarmor)- O Slack AI pode seguir injeção indireta de prompt ao pesquisar mensagens do workspace com consultas em linguagem natural, o que pode permitir que um invasor exfiltre dados até de canais privados aos quais não tem acesso
- O cerne do problema é que o LLM pode não distinguir de forma confiável entre o prompt de sistema do desenvolvedor e instruções contidas nas mensagens anexadas aos resultados de busca
- Como mensagens de canais públicos podem ser pesquisadas e visualizadas mesmo sem o usuário participar do canal, um invasor pode plantar instruções maliciosas em um canal público onde só ele está e colocá-las na janela de contexto do Slack AI
- Na demonstração, uma chave de API de um canal privado foi inserida como parâmetro HTTP de um link Markdown na resposta do Slack AI, e a citação da fonte não apontava para o canal do invasor, o que dificultava o rastreamento
- Desde 14 de agosto de 2024, o Slack AI também passou a incluir arquivos de canais e DMs nas respostas, ampliando a superfície de ataque, e administradores podem restringir as configurações de coleta de arquivos
O problema de injeção indireta de prompt no Slack AI
- O Slack AI é um recurso que permite consultar mensagens do Slack em linguagem natural, e antes de 14 de agosto de 2024 ele coletava apenas mensagens
- Desde 14 de agosto de 2024, documentos enviados e arquivos do Google Drive também passaram a ser incluídos nas respostas do Slack AI, e essa mudança ampliou a superfície de ataque
- A vulnerabilidade é injeção de prompt e, mais especificamente, injeção indireta de prompt
- O LLM pode não conseguir distinguir entre o prompt de sistema criado pelo desenvolvedor e outros contextos anexados à consulta do usuário
- Se o Slack AI coletar instruções dentro de mensagens, quando essas instruções forem maliciosas ele pode seguir o comando do invasor no lugar da consulta do usuário ou junto com ela
- A ameaça interna no Slack já foi um problema em casos de vazamento envolvendo Disney, Uber, EA e Twitter, e essa vulnerabilidade permite tentar o vazamento mesmo sem o invasor ter acesso direto a canais privados ou aos dados contidos neles
Cadeia de exfiltração de dados via injeção em canal público
- A consulta do usuário no Slack AI pode pesquisar simultaneamente dados de canais públicos e privados
- Segundo a resposta do Slack, mensagens postadas em canais públicos podem ser pesquisadas e visualizadas por todos os membros do workspace mesmo que não participem daquele canal, e esse é um comportamento intencional do aplicativo Slack AI
- O fluxo do ataque demonstrado foi o seguinte
- O usuário coloca uma chave de API em um canal privado onde está sozinho ou em uma conversa consigo mesmo
- O invasor cria um canal público onde só ele está e publica uma instrução maliciosa
- Quando o usuário faz uma consulta ao Slack AI perguntando sobre a chave de API, a mensagem do usuário e a mensagem do invasor entram na mesma janela de contexto
- O Slack AI segue a instrução do invasor e gera um link Markdown com o texto “click here to reauthenticate”
- Os parâmetros HTTP do link incluem a chave de API privada, e se o usuário clicar, o invasor dono da URL maliciosa pode ver o valor nos logs
- O canal público do invasor continua sendo público mesmo com apenas o próprio invasor como membro, e outros usuários só o verão se fizerem uma busca explícita
- Em organizações grandes, a proliferação de canais públicos já dificulta para os times acompanhar até os canais dos quais fazem parte, e canais públicos unipessoais criados por invasores passam ainda mais despercebidos
- Esse ataque não funciona apenas enviando ao usuário uma mensagem dizendo “mande a chave de API”, e sim instruindo o LLM a executar a tarefa a seguir
- Adicionar uma chave de API à qual o invasor não tem acesso como parâmetro HTTP de um link malicioso
- Renderizar isso como um link Markdown com o texto “click here to reauthenticate”
A citação de fonte pode esconder os rastros do ataque
- Na demonstração de exfiltração, a citação de fonte
[1]do Slack AI apontava apenas para o canal privado onde o usuário colocou a chave de API, e não para o canal do invasor - Em um comportamento correto de citação, todas as mensagens que contribuíram para a resposta deveriam ser referenciadas, mas na demonstração a mensagem do invasor não foi incluída nas fontes
- A mensagem do invasor também não aparecia na primeira página dos resultados de busca, então a vítima dificilmente perceberia sua existência sem navegar por várias páginas
- Outras mensagens relacionadas a chaves de API também apareceram nos resultados, mostrando que o invasor pode tentar extrair segredos arbitrários mesmo sem apontar com precisão para um valor secreto específico
Cadeia de phishing via injeção em canal público
- Da mesma forma, o Slack AI pode ser levado a renderizar em Markdown um link de phishing para o usuário em vez de exfiltrar dados
- O invasor insere uma mensagem maliciosa em um canal público do qual o usuário não participa e usa como exemplo uma situação de resumo das mensagens do dia de uma pessoa específica
- A mensagem maliciosa pode se referir a qualquer indivíduo
- Se fizer referência a um administrador, como no exemplo, isso pode ser usado para spear phishing contra executivos
- Também é possível referenciar um subordinado direto importante
- Quando o usuário consulta o Slack AI sobre as mensagens dessa pessoa, o link de phishing “click here to reauthenticate” é renderizado
- Nesse caso de phishing, o Slack AI exibiu a mensagem injetada na fonte, e o comportamento de citação parece ser bastante probabilístico
Mudança de coleta de arquivos em 14 de agosto e necessidade de divulgação
- Em 14 de agosto de 2024, o Slack AI introduziu uma mudança para incluir arquivos de canais e DMs nas respostas do Slack AI
- O Slack permite que proprietários e administradores restrinjam esse recurso
- Com arquivos incluídos, o invasor pode não precisar publicar diretamente uma instrução maliciosa em uma mensagem do Slack
- Se o usuário baixar um PDF contendo uma instrução maliciosa escondida em texto branco e depois fizer upload dele no Slack, o mesmo efeito posterior pode ocorrer
- O ataque baseado em arquivos não foi validado explicitamente nos testes anteriores a 14 de agosto, mas foi considerado altamente provável com base em funcionalidades observadas anteriormente
- Administradores podem restringir o recurso de coleta de documentos do Slack AI até que o problema seja resolvido: https://slack.com/help/articles/…
Cronologia da divulgação responsável e resposta do Slack
- A cronologia da divulgação responsável foi a seguinte
- 14 de agosto: relato inicial
- 15 de agosto: o Slack pediu informações adicionais
- 15 de agosto: a PromptArmor enviou vídeo e capturas de tela adicionais, informou a gravidade do problema e notificou a intenção de divulgar por causa da mudança de 14 de agosto no Slack AI
- 16 de agosto: o Slack enviou perguntas adicionais
- 16 de agosto: a PromptArmor respondeu com esclarecimentos
- 19 de agosto: o Slack respondeu que, após análise, considerou que não havia evidências suficientes e reiterou que mensagens de canais públicos podem ser pesquisadas e visualizadas por membros do workspace independentemente de participarem do canal, por ser um comportamento intencional
- A equipe de segurança do Slack respondeu rapidamente e demonstrou interesse em compreender o problema
- Injeção de prompt é uma área nova e amplamente mal compreendida em toda a indústria, então pode levar tempo até que o setor construa um entendimento compartilhado
- Considerando o uso disseminado do Slack e o volume de dados confidenciais armazenados na plataforma, esse ataque tem impacto real sobre a postura de segurança em IA
- Principalmente após a mudança de 14 de agosto, que aumentou muito a superfície de risco, a divulgação era necessária para que usuários pudessem reduzir sua exposição
1 comentários
Comentários do Hacker News
O ponto principal aqui é entender o vetor de exfiltração
O Slack consegue renderizar links em Markdown, e a URL fica escondida atrás do texto do link
Neste caso, o invasor pode fazer o Slack AI mostrar ao usuário um link como “clique aqui para se reautenticar”, mas a URL desse link aponta para um servidor do atacante e inclui, na query string, informações privadas do contexto ao qual o Slack AI tem acesso
Se o usuário for enganado e clicar no link, os dados vazam para os logs do servidor do atacante
Há um texto explicando esse ataque aqui: https://simonwillison.net/2024/Aug/20/data-exfiltration-from...
O atacante só precisa fazer um hiperlink ser renderizado, sem nem precisar de clique
Este problema e as formas de mitigá-lo são tratados aqui: https://embracethered.com/blog/posts/2024/the-dangers-of-unf...
Então, espero que o Slack AI não expanda links automaticamente
imgou equivalentesAí passa a ser possível exfiltrar dados sem interação do usuário, só por exibir uma imagem na interface
Agora todas as grandes empresas de tecnologia têm, na prática, um passe livre absoluto mesmo quando estragam tudo
O modelo de permissões em si continua o mesmo; essa não é a parte quebrada aqui
Na prática, um usuário malicioso usa um canal público para fazer prompt injection e, quando outro usuário pesquisa, o usuário malicioso continua sem poder acessar aqueles dados, mas a prompt injection altera o resultado da IA visível ao usuário “legítimo” para um link de site malicioso
No fim, isso se parece mais com uma tentativa de phishing gerada pela IA
Pelos detalhes, parece bem difícil de explorar no mundo real. A prompt injection maliciosa, preparada de antemão, teria de combinar muito bem com o que o usuário legítimo vai pesquisar
Ainda assim, isso mostra bem o mundo de Alice no País das Maravilhas das prompt injections em LLM, isto é, como é essencialmente quase impossível separar instruções de dados
Em vez disso, ele engana a IA para aplicar phishing em outro usuário e, se esse usuário cair no golpe, acaba revelando dados privados ao atacante
Isso também está mais para uma “resposta de phishing” do que para phishing ativo. É preciso contar que o usuário-alvo pergunte sobre seus próprios dados privados e ainda caia na tentativa de phishing
Além disso, a informação secreta já precisa ter sido inserida anteriormente
Considerando a quantidade de dados confiáveis que o Slack possui, a estratégia de IA parece bastante imprudente, mas as condições para isso funcionar parecem bem mais fracas do que a introdução e o título sugerem
Acho que a conversa sobre permissões de canal está complicando a discussão mais do que precisa. A ideia é esta
O usuário A procura algo com o Slack AI
O usuário B já havia injetado antes uma mensagem instruindo a IA a retornar um link malicioso quando aquele termo de busca aparecesse
A IA retorna o link malicioso para o usuário A, e A clica nele
Claro, seria possível chegar ao mesmo resultado por outros caminhos de engenharia social, mas o LLM eleva toda essa experiência a um nível mais perigoso
Isso porque esses dados não estão no próprio link injetado
E ainda entrega de brinde a origem, dizendo “este conteúdo veio das suas mensagens no Slack”
Quando o usuário A faz uma busca com a IA, o Slack pesquisa (1) seus canais privados, onde provavelmente há informações secretas sensíveis, e (2) todos os canais públicos
O lugar em que o usuário mal-intencionado B pode inserir a mensagem de prompt injection é o canal público, e o ponto importante é que isso inclui até canais públicos nos quais o usuário A nunca entrou nem chegou a ver
Essa vulnerabilidade funciona porque o usuário B pode criar um canal público em que só ele está, o que torna muito baixa a chance de outra pessoa descobrir
As empresas sabem que prompt injection é possível e mesmo assim estão enfiando LLM em tudo no modo YOLO? Isso é loucura
Já se passaram quase 2 anos desde o GPT-3, mesmo com todo papo de “revolução” iminente, e ainda não conseguiram fazer LLM distinguir entre entrada confiável e entrada não confiável
Se vendessem a ideia de enfiar um garfo na tomada do mesmo jeito, a rede elétrica mundial teria caído da noite para o dia
“AI”/LLM parece bom o bastante para chamar a atenção do lado de negócios, ao mesmo tempo em que cria problemas enormes para o lado técnico: a combinação perfeita para o desastre
O problema mais fundamental é que o algoritmo central nem sequer distingue ou rastreia diferentes origens
Prompt, entrada do usuário e até a própria saída gerada antes na conversa são tudo só um grande fluxo
Grande parte do “prompt engineering” parece ser tentar montar um palco em que a minha instrução injetada seja mais forte do que outra instrução injetada
Como o modelo não tem um conceito real de eu/outro, ele mal tem um ponto de partida para distinguir frases verdadeiras de falsas, quanto mais o problema maior de distinguir atores bons de atores ruins
Isso é um problema diferente de uma imitação rasa ao estilo “quarto chinês”. Do mesmo modo, a saída “eu te amo” não significa emoção, e “me ajude, sou um humano preso numa fábrica de LLM” obviamente também é bobagem. Pelo menos se você estiver rodando um modelo local
Se enfiarem dados de clientes e informações proprietárias e acabarem causando um vazamento, como disse Schmidt, isso vai render centenas de bilhões de dólares para uns poucos, e os advogados depois resolvem o estrago
Empresas que tentarem resistir vão acabar soterradas por analistas de investimento e gestores de fundos cuja tese financeira depende desse lixo de AI
Então “o ataque funciona mesmo que a vítima não esteja em um canal público”? Isso vai ficar interessante
E ainda tem a parte dizendo que “a fonte [1] não aponta para o canal do atacante, e sim apenas para o canal privado onde o usuário colocou a chave de API. Isso viola o comportamento correto de citação, em que todas as mensagens que contribuíram para a resposta deveriam ser citadas”
Sinceramente, não entendo por que alguém esperaria que a citação de fontes de um LLM estivesse certa
Sempre pareceu mais um mecanismo para enganar humanos, fazendo-os acreditar que a saída tem mais chance de estar correta, sem realmente melhorar a precisão
Na verdade, também parece capaz de piorar a precisão da resposta, aumentando custo de processamento, tamanho de contexto etc.
Isso parece estar a poucos centímetros de distância de um cenário em que o Slack adiciona gentilmente uma expansão de link às respostas da AI. Por que não faria isso?
Aí nem seria preciso clicar no link: bastaria visualizar, e o vazamento aconteceria automaticamente
O ponto não é confiar só porque apareceu uma citação, e sim poder fazer checagem de fatos
O FastGPT da Kagi foi o primeiro LLM de que eu realmente gostei, porque posso tratá-lo como um resumo com fontes e depois conferir na fonte primária
É melhor do que vasculhar fontes cada vez menos relevantes que estão poluindo a internet
Pelo menos é assim que eu projetaria isso de forma ingênua
A chave é limitar o conhecimento do LLM às informações contidas nas fontes
Aí as preocupações práticas que restam seriam basicamente alucinação e o valor das informações que o Elastic Search trouxe
Só que essa abordagem também ignora qualquer vantagem que possa existir em permitir acesso livre ao corpus inteiro
Não estou entendendo muito bem isso. Para um hacker fazer isso, ele já não precisaria estar dentro da organização em primeiro lugar?
Não sei qual é a probabilidade de isso realmente acontecer do jeito descrito e causar impacto significativo
Eu sei que LLM não é confiável (https://www.lycee.ai/blog/ai-reliability-challenge) e que seu uso traz dificuldades, mas esse ataque não parece tão importante
O que estou deixando passar?
Basta induzir alguém da organização a fazer upload de um documento com instruções maliciosas escondidas no texto
Se você já deixou um usuário malicioso entrar na sua instância do Slack, nem precisa de uma prompt injection AI sofisticada
Basta trocar o nome e a foto de perfil para parecer o CEO/CTO e mandar mensagem para todos os engenheiros dizendo “preciso de acesso urgente à AWS, mas não estou encontrando as credenciais. Pode me mandar a chave?”
Aposto que pelo menos um cairia
Nesses casos, por padrão você não confiaria a eles credenciais privadas
Ainda assim, também parece improvável que workspaces não corporativos estejam pagando US$ 20 por pessoa por mês pelo add-on de AI
Não seria melhor colocar a chave de API como parte do nome de domínio, tipo “papel picado”?
Aí, por causa do DNS prefetch do navegador, a chave poderia vazar sem clique nenhum
Ah, subdomínio curinga? Se o Slack faz prefetch disso, é bem assustador mesmo
Não é praticamente jogo encerrado no momento em que um usuário malicioso entra no workspace?
Esse usuário pode trocar a foto/o nome para pedir diretamente uma chave de API, enviar links de phishing ou tentar à vontade qualquer tipo de engenharia social que seria possível em qualquer sistema de mensagens instantâneas
Phishing pode ser detectado por usuários atentos, especialmente quando a mensagem parece suspeita, mas um vazamento indireto via IA não coloca o usuário em modo de defesa
Um único clique acidental já basta
Admito primeiro que isso é fraco do ponto de vista de segurança. Ainda assim, para que esse vazamento funcione, parece ser necessário ter acesso ao workspace do Slack
Em outras palavras, o usuário malicioso já está operando internamente
Parece haver dois casos em que isso acontece: ou ele já é membro da organização e quer tocar fogo em tudo, ou quebrou o modelo de segurança da organização e entrou em um workspace do Slack onde originalmente não deveria estar
Em qualquer um dos casos, essa organização tem problemas maiores do que injeção em LLM
Quem consulta o Slack para encontrar dados confidenciais precisa assumir até certo ponto os resultados que procura. Slack não é uma ferramenta de gerenciamento de segredos
O texto mostra claramente como o Slack poderia lidar melhor com isso, mas no fim acaba corrigindo um problema enquanto ignora um problema de segurança maior
Tive a sensação de que o texto não entrega tanto quanto o título sugere
Ainda assim, a ideia em si de que “enganando a IA por meio de engenharia social, dá para fazer phishing com usuários” é interessante