Desde a descoberta de CRIME, BREACH, TIME, LUCKY-13 etc., os ataques de canal lateral baseados em comprimento têm sido considerados práticos. Embora os pacotes fossem criptografados, os invasores conseguiram inferir informações sobre o texto simples subjacente, analisando metadados como o comprimento do pacote ou informações de tempo.
A Cloudflare foi recentemente contatada por um grupo de pesquisadores da Universidade Ben Gurion, que escreveram um artigo intitulado "What Was Your Prompt? A Remote Keylogging Attack on AI Assistants"que descreve" um novo canal lateral que pode ser usado para ler respostas criptografadas de assistentes de IA pela web".
A equipe do Workers AI e do AI Gateway colaborou estreitamente com esses pesquisadores de segurança por meio de nosso programa Public Bug Bounty, descobrindo e corrigindo totalmente uma vulnerabilidade que afeta os provedores de LLM. Você pode ler o artigo da pesquisa em detalhes aqui.
Desde que fomos notificados sobre essa vulnerabilidade, implementamos uma mitigação para ajudar a proteger todos os clientes do Workers AI e do AI Gateway. Tanto quanto pudemos avaliar, não havia risco pendente para os clientes do Workers AI e do AI Gateway.
Como funciona o ataque de canal lateral?
No artigo, os autores descrevem um método no qual interceptam o fluxo de uma sessão de chat com um provedor de LLM, usam os cabeçalhos dos pacotes de rede para inferir o comprimento de cada token, extraem e segmentam sua sequência e, em seguida, usam seus próprios LLMs dedicados para inferir a resposta.
Os dois principais requisitos para um ataque bem-sucedido são um cliente de chat de IA em execução no modo streaming e um agente malicioso capaz de capturar o tráfego de rede entre o cliente e o serviço de chat de IA. No modo streaming, os tokens de LLM são emitidos sequencialmente, introduzindo um canal lateral do comprimento de um token. Agentes maliciosos podem espionar pacotes por meio de redes públicas ou dentro de um provedor de internet.
Um exemplo de solicitação vulnerável ao ataque de canal lateral é assim:
curl -X POST \
https://api.cloudflare.com/client/v4/accounts/<account-id>/ai/run/@cf/meta/llama-2-7b-chat-int8 \
-H "Authorization: Bearer <Token>" \
-d '{"stream":true,"prompt":"tell me something about portugal"}'
Vamos usar o Wireshark para inspecionar os pacotes de rede na sessão de chat do LLM durante o streaming:
O primeiro pacote tem comprimento de 95 e corresponde ao token "Port" que tem comprimento de quatro. O segundo pacote tem comprimento de 93 e corresponde ao token "ug" que tem comprimento de dois, e assim por diante. Ao remover o provável envelope de token do comprimento do pacote de rede, é fácil inferir quantos tokens foram transmitidos e sua sequência e comprimento individual apenas detectando dados criptografados da rede.
Como o invasor precisa da sequência de comprimento de token individual, esta vulnerabilidade afeta apenas os modelos de geração de texto usando streaming. Isso significa que os provedores de inferência de IA que usam streaming, a maneira mais comum de interagir com LLMs, como o Workers AI, estão potencialmente vulneráveis.
Esse método requer que o invasor esteja na mesma rede ou em posição de observar o tráfego de comunicação e sua precisão depende do conhecimento do estilo de escrita do LLM alvo. Em condições ideais, os pesquisadores afirmam que seu sistema "pode reconstruir 29% das respostas de um assistente de IA e inferir com sucesso o tópico de 55% delas". Também é importante observar que, ao contrário de outros ataques de canal lateral, neste caso o invasor não tem como avaliar sua previsão em relação à verdade de campo. Isso significa que é tão provável obter uma frase com precisão quase perfeita quanto obter uma em que apenas as coisas que correspondem são conjunções.
Mitigar ataques de canal lateral no LLM
Como esse tipo de ataque depende do comprimento dos tokens inferidos do pacote, ele pode ser facilmente mitigado ocultando o tamanho do token. Os pesquisadores sugeriram algumas estratégias para mitigar esses ataques de canal lateral, uma das quais é a mais simples: preencher as respostas do token com ruído de comprimento aleatório para ocultar o comprimento do token e impedir que as respostas sejam inferidas a partir dos pacotes. Embora tenhamos adicionado imediatamente a mitigação ao nosso próprio produto de inferência, o Workers AI, queríamos ajudar os clientes a proteger seus LLMs, independentemente de onde os estejam executando, adicionando-a ao nosso AI Gateway.
A partir de hoje, todos os usuários do Workers AI e do AI Gateway estão protegidos automaticamente contra esse ataque de canal lateral.
O que fizemos
Assim que soubemos desse trabalho de pesquisa e como a exploração da técnica poderia impactar nossos produtos de IA, fizemos o que sempre fazemos em situações como esta: reunimos uma equipe de engenheiros de sistemas, engenheiros de segurança e gerentes de produto e começamos a discutir estratégias de mitigação de riscos e próximas etapas. Também fizemos uma call com os pesquisadores, que gentilmente participaram, apresentaram suas conclusões e responderam às perguntas de nossas equipes.
A equipe de pesquisa forneceu um notebook de testes que poderíamos usar para validar os resultados do ataque. Embora tenhamos conseguido reproduzir os resultados nos exemplos do notebook, descobrimos que a precisão variou imensamente com nossos testes usando diferentes respostas de prompts e diferentes LLMs. No entanto, o artigo tem valor e os riscos não são insignificantes.
Decidimos incorporar a primeira sugestão de mitigação no artigo: incluir preenchimento aleatório em cada mensagem para ocultar o comprimento real dos tokens no streaming, complicando assim as tentativas de inferir informações com base apenas no tamanho do pacote de rede.
O Workers AI, nosso produto de inferência, agora está protegido
Com nosso produto de inferência como serviço, qualquer pessoa pode usar a plataforma Workers AI e fazer chamadas de API para nossos modelos de IA compatíveis. Isso significa que supervisionamos as solicitações de inferência feitas de e para os modelos. Como tal, temos a responsabilidade de garantir que o serviço seja seguro e protegido contra possíveis vulnerabilidades. Lançamos imediatamente uma correção assim que fomos notificados sobre a pesquisa, e todos os clientes do Workers AI agora estão protegidos automaticamente contra esse ataque de canal lateral. Não vimos nenhum ataque malicioso explorando essa vulnerabilidade, além dos testes éticos dos pesquisadores.
Nossa solução para o Workers AI é uma variação da estratégia de mitigação sugerida no documento de pesquisa. Como fazemos streaming de objetos JSON em vez de tokens brutos, em vez de preencher os tokens com caracteres de espaço em branco, adicionamos uma nova propriedade, "p" (para preenchimento), que tem um valor de string de comprimento aleatório variável.
Exemplo de resposta de streaming usando a sintaxe SSE:
data: {"response":"portugal","p":"abcdefghijklmnopqrstuvwxyz0123456789a"}
data: {"response":" is","p":"abcdefghij"}
data: {"response":" a","p":"abcdefghijklmnopqrstuvwxyz012"}
data: {"response":" southern","p":"ab"}
data: {"response":" European","p":"abcdefgh"}
data: {"response":" country","p":"abcdefghijklmno"}
data: {"response":" located","p":"abcdefghijklmnopqrstuvwxyz012345678"}
Isso tem a vantagem de que nenhuma modificação é necessária no SDK ou no código do cliente, as alterações são invisíveis para os usuários finais e nenhuma ação é necessária por parte de nossos clientes. Ao adicionar um comprimento de variável aleatória aos objetos JSON, introduzimos a mesma variabilidade em nível de rede e o invasor perde essencialmente o sinal de entrada necessário. Os clientes podem continuar usando o Workers AI como de costume enquanto se beneficiam dessa proteção.
Um passo além: o AI Gateway protege os usuários de qualquer provedor de inferência
Adicionamos proteção ao nosso produto de inferência de IA, mas também temos um produto que faz proxy de solicitações para qualquer provedor, o AI Gateway. AI Gateway atua como um proxy entre um usuário e os provedores de inferência compatíveis, ajudando os desenvolvedores a obter controle, desempenho e observabilidade sobre seus aplicativos de IA. De acordo com nossa missão de ajudar a construir uma internet melhor, queríamos lançar rapidamente uma correção que pudesse ajudar todos os nossos clientes que usam IAs de geração de texto, independentemente de qual provedor usem ou se eles têm mitigações para evitar esse ataque. Para fazer isso, implementamos uma solução semelhante que preenche todas as respostas de streaming que fazem proxy por meio do AI Gateway com ruído aleatório de comprimento variável.
Nossos clientes do AI Gateway agora estão protegidos automaticamente contra esse ataque de canal lateral, mesmo que os provedores de inferência upstream ainda não tenham mitigado a vulnerabilidade. Se você não tiver certeza se seu provedor de inferência já corrigiu essa vulnerabilidade, use o AI Gateway para fazer proxy de suas solicitações e garantir sua proteção.
Conclusão
Na Cloudflare, nossa missão é ajudar a construir uma internet melhor, isso significa que nos importamos com todos os cidadãos da internet, independentemente de como seja sua pilha de tecnologia. Temos orgulho de poder melhorar a segurança de nossos produtos de IA de forma transparente e não exigir nenhuma ação de nossos clientes.
Agradecemos aos pesquisadores que descobriram essa vulnerabilidade e têm colaborado muito para nos ajudar a entender o espaço do problema. Se você é um pesquisador de segurança interessado em nos ajudar a tornar nossos produtos mais seguros, confira nosso programa Bug Bounty em hackerone.com/cloudflare.