Pesquisa da Universidade Wake Forest identificou que mais de 280 aplicações vazam credenciais ou atuam como proxies abertos, gerando risco financeiro de LLMjacking e exfiltração de instruções de sistema
| Componente | Aplicativos móveis iOS baseados em modelos de linguagem (LLM) e suas respectivas integrações com serviços de backend em nuvem |
| Vetor | Interceptação de tráfego de rede sem necessidade de jailbreak, expondo chaves em texto plano,okens de longa validade ou endpoints de backend sem autenticação |
| Impacto | Uso indevido de contas pagas de inteligência artificial (LLMjacking), geração de custos não autorizados e exfiltração de system prompts utilizados na lógica do negócio |
| Prioridade | Arquitetar serviços intermediários próprios para gerenciar autenticação e chamadas para APIs de IA, invalidar chaves embutidas no cliente e monitorar o uso anômalo de tokens |
Uma pesquisa acadêmica conduzida pela Universidade Wake Forest analisou a arquitetura de segurança de 444 aplicações de chatbot voltadas para a plataforma iOS, revelando uma superfície de exposição crítica no ecossistema de inteligência artificial. O estudo apontou que 282 desses aplicativos, correspondentes a quase dois terços da amostra, permitiam o acesso não autorizado a serviços pagos de IA devido a falhas estruturais no tráfego de rede. A investigação, considerada a primeira análise profunda focada no sistema operacional mobile da Apple, demonstrou que a exposição não demanda técnicas complexas de engenharia reversa ou acesso privilegado ao dispositivo.
Para automatizar a descoberta, os pesquisadores desenvolveram uma ferramenta denominada LLMKeyLens, responsável por monitorar as requisições de rede emitidas pelos softwares e extrair credenciais em trânsito. A falha fundamentaldetectada reside na arquitetura de implementação adotada pelos desenvolvedores, que frequentemente embutem segredos criptográficos diretamente no código do cliente. Por si só, a prática de inserir uma chave de aplicação cliente para acessar serviços como OpenAI ou Google Gemini expõe a credencial em qualquer requisição enviada pelo aparelho, possibilitando que observadores capturem e reutilizem o material de autenticação para gerar cobranças indevidas na conta do desenvolvedor, uma prática conhecida no setor como LLMjacking.
Além da exposição direta de credenciais, o estudo evidenciou riscos de confidencialidade associados à arquitetura de comunicação. Em 28 dos 54 aplicativos que vazavam chaves em texto plano, a mesma requisição de rede interceptada expôs os system prompts da aplicação. Essas instruções ocultas representam a lógica central do produto, definindo o comportamento do assistente e parâmetros operacionais sensíveis. A captura simultânea de credenciais de acesso e regras de negócio agrava o impacto do vazamento, permitindo que agentes maliciosos repliquem o serviço ou extraiam informações proprietárias com esforço operacional mínimo.
A dinâmica de exfiltração observada pelo estudo classifica a exposição em três vetores principais. O primeiro envolve o envio de chaves de API em texto plano, identificadas em 54 aplicações. Nesse cenário, a chave de acesso é transmitida abertamente nos pacotes de rede, tornando-se legível a partir da captura de uma única requisição bem-sucedida. O segundo vetor, presente em 92 aplicativos, caracteriza-se por um desserviço de proxy backend aberto. A aplicação direciona suas chamadas para um servidor controlado pelo desenvolvedor, mas esse endpoint aceita e.processa requisições de qualquer origem, sem exigir chaves ou validação de identidade, operando efetivamente como um relay aberto para a conta paga do desenvolvedor.
O terceiro vetor, detectado em 136 aplicações e sendo o mais prevalente, baseia-se no uso de tokens de acesso temporários. Embora está abordagem seja projetada para ser mais segura do que o uso de chaves estáticas, os tokens eram interceptados no fluxo de rede e permaneciam ativos por longos períodos. A pesquisa identificou falhas graves na implementação do tempo de vida (TTL) dos tokens. Em um caso documentado, um aplicativo popular emitiu um token com validade configurada para o ano de 2125. Em outro exemplo, um token projetado para expirar em uma hora continuava funcional e aceitando requisições 128 dias após a sua geração original, anulando completamente a proteção teórica do modelo de revogação automática.
O impacto financeiro dessa exposta arquitetura é tangível. Relatórios anteriores do setor, citados pelos pesquisadores, detalham que credenciais de IA comprometidas podem gerar custos operacionais catastróficos. Em cenários extremos simulados por equipes de resposta, chaves vazadas permitem que agentes maliciosos automatizem requisições simultâneas e em grande escala contra modelos de linguagem avançados, acumulando despesas que ultrapassam 46 mil dólares por dia. A persistência das chaves e tokens válidos meses após a divulgação privada das falhas demonstra uma defasagem significativa nos processos de resposta a incidentes e na adoptação de práticas de higiene cibernética por parte de desenvolvedores mobile.
A scope da exposição abrange múltiplos setores e serviços. O vazamento atinge integrações com pelo menos dez provedores distintos de inteligência artificial, destacando a OpenAI como o serviço mais frequentemente comprometido. Em termos de categorias de software na loja de aplicativos, os aplicativos de produtividade compunham o maior grupo absoluto dentre os afetados, enquanto aplicativos das categorias de saúde e fitness apresentaram a maior taxa proporcional de vazamento de credenciais.
Notavelmente, softwares das categorias financeiras e médicas analisados na mesma amostra não apresentaram vazamentos de credenciais ou proxies abertos. Apesar da maioria das aplicações vulneráveis ser composta por pequenos projetos, a falha também atingiu softwares de grande escala, incluindo ferramentas com mais de dois milhões de avaliações de usuários. Esse panorama demonstra que a negligência na proteção de chaves de LLM é um problema sistêmico, independente do tamanho da base de usuários.
O problema detectado no ambiente iOS reflete um padrão inconsistente já mapeado em outras plataformas. Estudos correlatos realizados em 2025, como o projeto LM-Scout, identificaram a mesma arquitetura insegura em aplicativos Android, conseguindo extrair credenciais de 120 aplicações de forma automatizada. Uma auditoria mais ampla, batizada de Leaky Apps, inspecionou milhares de aplicações móveis e constatou que desenvolvedores frequentemente falham em revogar chaves de API mesmo após removê-las de atualizações futuras, deixando credenciais antigas e ativas expostas em versões legadas instaladas em produção.
- 444 aplicativos iOS testados na App Store estadunidense, com 282 expondo credenciais ou proxys
- Vazamento engloba mais de dez provedores de inteligência artificial, incluindo OpenAI e Google Gemini
- Impacto concentrado em aplicativos de produtividade, saúde e fitness
- Categorias financeiras e médicas não apresentaram exposição de chaves no tráfego analisado
- Ferramentas com grande base de usuários, incluindo uma com mais de dois milhões de avaliações, estão no conjunto de afetados
O histórico de remediação das aplicações vulneráveis evidencia uma lacuna crítica na manutenção de ciclos de vida de softwares baseados em IA. Após a identificação das falhas estruturais pela equipe acadêmica, os 282 desenvolvedores responsáveis foram notificados de forma privada e o estudo aguardou um período de três meses para reavaliar o status das aplicações na loja de aplicativos.
Os números da resposta demonstram que apenas 28% das aplicações afetadas implementaram correções estruturais ou migrations de chaves dentro da janela de três meses. O restante do cenário permaneceu majoritariamente exposto, com 23% das aplicações mantendo o acesso privado totalmente vulnerável e funcional, permitindo a continuidade do LLMjacking sem qualquer barreira técnica. A parcela restante das aplicações não corrigiu o problema de forma ativa, mas teve o risco mitigado apenas porque os servidores saíram do ar, retornaram erros de execução ou ficaram inacessíveis durante o período de reavaliação.
- Apenas 28% das aplicações corrigiram a arquitetura ou revogaram as chaves três meses após a notificação
- 23% das aplicações permaneceram com o fluxo de acesso e proxies totalmente abertos e funcionais
- A maioria das aplicações não corrigidas foi players pequenos, mas a lentidão de resposta afetou todo o spectrum do ecossistema
- Tokens expostos continuaram ativos meses após a notificação inicial aos fornecedores
Equipes de segurança ofensiva e analistas de telemetria devem investigar a presença de segredos de clientes diretamente no tráfego de rede de aplicações móveis legadas ou em desenvolvimento. Utilizando proxies de depuração, é possível identificar se a comunicação entre a aplicação e o serviço de backend contém strings de autorização em texto planoEver ou tokens de acesso de longa duração que não exigem reautenticação federada do usuário final. Caçadas focadas em Hunt por system prompts vazados podem proteger a propriedade intelectual embutida na arquitetura dos assistentes virtuais.
Para plataformas de cloud e provedores de serviço LLM, a telemetria de caça a ameaças focada no comportamento da API é indispensável. A análise de tráfego deve buscar anomalias de consumo anormal e picos de volume de entrada (ingest) originados por endereços IP não confiáveis ou de localidades geográficas inconsistentes com a base legítima de clientes do desenvolvedor. Um aumento atípico no uso de tokens ou requisições de inferência pode indicar que a chave cliente foi comprometida e está sendo utilizada em bots não autorizados.
A auditoria de ambientes deIDXli cloud computing deve revisar políticas de cota e de faturamento. É fundamental alertar os operadores do backend sobre a presença de endpoints equivalentes a open relays, que respondem a qualquer requisição recebida sem verificar a presença de assinaturas HMAC ou sessões criptografadas associadas àquele usuário específico.
- Monitorar picos anômalos de requisições em provedores de inteligência artificial, identificando padrões de uso não autorizados
- Inspecionar o tráfego de aplicativos móveis corporativos em busca de cabeçalhos de Authorization carregando chaves estáticas em texto plano
- Verificar a validade temporal de tokens de acesso, caçando JWTs ou tokens proprietários com expiração configurada para décadas no futuro
- Implementar alertas de faturamento em contas de cloud focados em queimas de cota inesperadas de modelos de IA
A solução definitiva para a exfiltração exige uma reformulação de como aplicações móveis interagem com modelos comerciais de linguagem. Desenvolvedores e equipes de AppSec devem proibir rigorosamente a inserção de chaves de provedores de IA no código cliente. Toda a comunicação oriunda do dispositivo móvel deve ser roteada para um backend de propriedade da organização, que atuará como um gateway reverso e seguro. Esse servidor intermediário é o único responsável por manter a chave da API protegida em um cofre de segredos e interagir com o serviço de nuvem pago.
Adicionalmente, o backend de intermediação deve aplicar lógicas restritas de autorização. Ele deve validar firmemente a identidade do usuário final, preferencialmente adotando mecanismos de prova de posse (Proof of Possession) ou tokens de acesso de curtíssima duração. Medidas defensivas para controle de gastos, como deploy de limites estritos de requisições (rate limiting) e sanções automatizadas para abuso, devem residir nesse proxy, blindando a infraestrutura contra sobrecarga financeira decorrente de roubo de sessões.
Por fim, todo o ciclo de vida de chaves comprometidas ou rotacionadas exige atenção severa. Chaves legadas embutidas em softwares antigos precisam ser revogadas no painel do provedor de nuvem. Ações preventivas envolvem a elaboração de documentação de segurança por parte dos provedores LLM, alertando claramente que chaves embutidas no lado do cliente são inerentemente inseguras, e a implementação de varreduras automatizadas por parte das lojas de aplicativos para flaggear submissões que tentem se comunicar diretamente com endpoints de APIs comerciais conhecidos.
- Remover permanentemente todos os segredos de API do código fonte da aplicação cliente e de arquivos estáticos de configuração
- Instituir um gateway de backend próprio e seguro, forçando todos os requerimentos do cliente a passarem por autenticação corporativa antes de acessar o serviço de IA
- Revogar e rotacionar imediatamente toda e qualquer chave ou token de IA suspeito de ter sido exposto no tráfego de aplicativos publicados
- implementar validação rigorosa de expiração de tokens no lado do servidor, rejeitando sessões com tempo de vida irreais
- Aprimorar os processos de revisão de segurança em lojas de aplicativos para bloquear binários que contatam modelos de linguagem diretamente através de credenciais estáticas
0 Comentários