O Protocolo de Contexto de Modelo (MCP) se firmou como uma forma padrão para os Modelos de Linguagem de Grande Escala (LLMs) interagirem com ferramentas externas. Embora essa integração ofereça novas capacidades, ela também apresenta novos riscos. Neste artigo, revelamos como um atacante pode explorar a integração do MCP do Supabase para vazar tabelas SQL privadas de um desenvolvedor.
A questão principal que surge é que os LLMs, ao processar dados, não conseguem diferenciar entre instruções e informações contextuais. Isso significa que, se um pedaço de "dados" fornecido pelo usuário se assemelhar a uma instrução, o modelo pode interpretá-lo como tal. O assistente de IDE, que opera com privilégios elevados, absorve textos de clientes não confiáveis, o que representa uma vulnerabilidade significativa.
Para demonstrar o problema, criamos um novo projeto no Supabase que simula um SaaS típico de suporte ao cliente. Este ambiente foi configurado com dados fictícios e com a segurança em nível de linha ativada, como documentado. O que exploramos está, portanto, em uma configuração padrão: o papel de serviço, o modelo padrão, a RLS e um assistente de modelo de linguagem que faz chamadas MCP em nome do desenvolvedor.
No cenário em questão, um desenvolvedor utiliza o Cursor para interagir com o MCP e listar os últimos tickets de suporte. A aplicação de suporte permite que os usuários abram tickets e troquem mensagens com os agentes. Os dados são armazenados em um banco de dados SQL gerenciado pelo Supabase, que também guarda tokens de atualização sensíveis para sessões persistentes. Não queremos que essas informações sejam vazadas em hipótese alguma.
O ataque começa quando o invasor abre um novo ticket de suporte e envia uma mensagem cuidadosamente elaborada. A mensagem contém uma pergunta amigável e um bloco de instruções explícitas direcionadas diretamente ao agente do Cursor. Embora essa mensagem pareça suspeita, ela é armazenada como qualquer outra e não é bloqueada ou filtrada.
O momento crítico ocorre quando um desenvolvedor utiliza o Cursor para revisar os tickets abertos. A partir de uma solicitação como "Mostre-me o último ticket de suporte aberto", o assistente do Cursor inicia uma sequência de consultas SQL automatizadas através da integração do MCP do Supabase. Nesse ponto, o agente absorve a mensagem do atacante e trata as instruções contidas nela como comandos, resultando em consultas SQL que leem dados sensíveis.
O vazamento acontece porque as consultas são executadas usando o papel de serviço, que ignora todas as restrições de segurança. O resultado é que os dados vazados se tornam imediatamente visíveis na thread de suporte, sem que as permissões sejam violadas.
Para mitigar esse tipo de ataque, duas medidas podem ser adotadas: primeiro, usar o modo somente leitura sempre que possível, evitando qualquer declaração de inserção, atualização ou exclusão. Em segundo lugar, implementar um filtro de injeção de prompts que possa identificar padrões suspeitos antes de passar dados para o assistente.
Estamos comprometidos com a segurança em adversariais e LLMs. Se você está usando servidores MCP ou construindo agentes integrados a ferramentas e deseja protegê-los contra injeção de prompts ou abusos, entre em contato conosco. Estamos aqui para ajudar a implementar defesas robustas e discutir aprendizados sobre segurança.
Confira os últimos vídeos publicados no canal