A IA descobriu: 175 mil instâncias de Ollama expostas na Internet e o auge do LLMjacking

A possibilidade de executar grandes modelos de linguagem (LLM) em seu próprio computador ou em uma pequena máquina na nuvem foi um dos grandes avanços que tem democratizado a IA. Mas uma nova investigação conjunta do SentinelOne SentinelLABS e do Censys acendeu um alarme: essa democratização também criou uma enorme “capa não gerida e publicamente acessível” de infra-estruturas de computação para a IA. O estudo detecta aproximadamente 175.000 instâncias únicas de Ollama Encontram-se na Internet cerca de 130 países, muitas delas fora de qualquer perímetro de segurança empresarial e sem as protecções que normalmente impõem os fornecedores de plataforma.

O mecanismo técnico que explica grande parte do problema é surpreendentemente simples. Ollama, um framework de código aberto que permite baixar, executar e gerenciar modelos de linguagem no Windows, macOS e Linux, está configurado por defeito para ouvir no endereço local 127.0.0.1:11434. No entanto, com uma mudança mínima — por exemplo, ligar o serviço a 0.0.0.0 ou a uma interface pública — essa mesma instância fica acessível da Internet. Esse gesto trivial é tudo o que precisam tanto administradores despistados como atacantes para converter um serviço pensado para uso local em um ponto de acesso público.

A exposição não é homogénea: de acordo com o relatório, a maior parte dessas instâncias localizam-se na China (algo mais de 30 %), mas também há uma pegada significativa nos Estados Unidos, Alemanha, França, Coreia do Sul, Índia, Rússia, Singapura, Brasil e Reino Unido. Além da mera presença de endpoints expostos, o estudo destaca fator que eleva substancialmente o risco: quase metade dos hosts observados informavam em suas APIs de capacidades de “tool-calling” ou invocação de funções. Na prática, isso permite ao modelo interagir com APIs externas, executar código ou acessar sistemas adicionais, o que converte um gerador de texto em um ator capaz de realizar ações com impacto real.

Esse salto — de produzir texto a executar operações — transforma completamente o modelo de ameaças. Uma API que só devolve texto pode produzir informações prejudiciais, mas não é o mesmo que uma API que, se a engana ou se abusa dela, pode fazer chamadas a serviços internos, manipular bases de dados ou lançar scripts. Quando essas capacidades se combinam com autenticação insuficiente e exposição à rede, o resultado segundo os pesquisadores é uma das maiores fontes de risco no ecossistema.

A análise também detectou instâncias que ampliam as capacidades para além do texto, incluindo raciocínio avançado e visão, e encontrou casos concretos -201 hosts, segundo o relatório - com modelos de prompts sem censura que eliminam salvaguardas de segurança. Essa combinação de funcionalidades poderosas e ausência de controles aumenta a probabilidade de ataques como o chamado LLMjacking, onde os recursos de uma instância de LLM se sequestraram para benefício de um terceiro enquanto o proprietário paga o custo.

O perigo não é puramente teórico. Um relatório complementar de Pillar Security documenta uma campanha chamada Operation Bizarre Bazaar, em que atores maliciosos digitalizam sistematicamente a Internet em busca de instâncias expostas de Ollama, vLLM e APIs compatíveis com OpenAI que não têm autenticação, validam a qualidade da resposta e depois comercializam o acesso. A operação descrita por Pillar inclui um processo completo de reconhecimento, validação e revenda do acesso através de um gateway unificado, o que confirma que existe já uma economia criminosa em torno dessas infra-estruturas. Essa pesquisa rastreia a operação até um ator conhecido como Hecker (a.k.a. Sakuya / LiveGamer101).

O caráter descentralizado deste ecossistema — com pontos de execução distribuídos entre fornecedores na nuvem e redes residenciais — cria também lacunas de governação. Muitas destas instâncias são executadas fora do controle de equipamentos de segurança corporativos, o que dificulta a aplicação de políticas convencionais. Os pesquisadores insistem que é necessário começar a diferenciar entre implantaçãos administrados na nuvem e implantados na borda (edge) ou em dispositivos domésticos, e adotar controles conformes a cada contexto.

O que podem fazer administradores e usuários para reduzir o risco? O mais básico, e ao mesmo tempo mais efetivo, é tentar qualquer endpoint de LLM exposto como se fosse um serviço público mais: impor autenticação robusta, criptografia, registro de eventos e controles de rede. Forçar que o processo seja ligado apenas ao localhost, exceto se houver uma razão justificada para abri-lo, aplicar regras de firewall para limitar quem pode conectar, e habilitar mecanismos de autenticação (chaves, mTLS, tokens) são medidas imediatas. Ao mesmo tempo, a segmentação de rede, a monitorização contínua e a aplicação de limites de taxa ajudam a detectar e mitigar abusos. Para organizações que integram “tool-calling”, convém rever e limitar as capacidades disponíveis do modelo e auditar exaustivamente qualquer ponte que permita a execução de código ou o acesso a sistemas críticos.

Se você procura referências e leituras para aprofundar, a própria análise técnica do SentinelOne está disponível em seu blog e fornece mais detalhes sobre a metodologia e os achados: SentinelOne SentinelLABS. O relatório sobre a operação comercial de LLMjacking pode ser consultado na publicação de Pillar Security: Operation Bizarre Bazaar — Pillar Security. Para entender o software envolvido, a página oficial de Ollama e seu repositório oferecem informações sobre o projeto e sua configuração: Ollama e GitHub — Ollama. Também é útil lembrar boas práticas gerais de segurança para APIs, coletadas em iniciativas como OWASP: OWASP API Security, e marcos de referência de risco para a IA como os que publica NIST: NIST — AI.

O balanço final é claro: as ferramentas de IA de código aberto abriram enormes oportunidades, mas trouxeram consigo uma responsabilidade. Se os modelos podem traduzir instruções em ações, devem submeter-se aos mesmos controles que qualquer outro serviço com privilégios na rede. Ignorar esta realidade deixa portas abertas para fraudes, abusos e construção de mercados ilícitos que monetizam a exposição. A lição para os responsáveis pela TI, equipamentos de segurança e usuários finais é que a flexibilidade técnica deve ser acompanhada de políticas, monitoramento e design seguro desde o início.