Violação da NEAR AI por uma falha no mecanismo de inferência (dados de conta de cerca de 100 usuários): o que foi confirmado e o que usuários e operadores de infraestrutura de IA devem fazer

Segundo o relatório da empresa, os usuários cujos dados de conta ela confirmou terem sido acessados, e os donos dos 18 agentes, foram contatados diretamente por security@near.ai com os passos que se aplicam a eles. Confira também a pasta de spam. Se recebeu uma mensagem, siga primeiro as orientações dela.

Se não tiver certeza de que uma mensagem é genuína, não abra os links dela; abra você mesmo o site oficial da empresa. O contato da empresa é security@near.ai.

A empresa aconselha tratar com cautela mensagens não solicitadas que façam referência à sua conta ou ao seu saldo. O que foi levado é um endereço de e-mail e um nome, além de informações de plano e saldo em algumas contas. Juntos, permitem redigir mensagens falsas convincentes (um ponto geral). Não abra os links; confira sua conta por um favorito. Mais em O que é phishing.

O que a empresa confirmou é que o histórico de chat, as configurações e os logs de 18 agentes legados foram obtidos e que, separadamente, as chaves de API de dois clientes do Cloud ficaram expostas em logs (não se diz que foram levadas). Ela também diz que as requisições de usuários no servidor comprometido em 8 de novembro puderam ser observadas.

Se você já colocou uma chave de API, uma senha ou uma string de conexão nas configurações de um agente ou em um chat, troque-a com quem a emitiu, por precaução. Não precisa esperar para saber se foi vista. Sobre o manuseio de chaves, veja Variáveis de ambiente e chaves de API: o básico.

A empresa diz que as chaves expostas em logs pertenciam a dois clientes do Cloud e foram revogadas. O relatório não traz orientação sobre as chaves de outros clientes. Revise onde você usa suas chaves, apague as que não usa mais e confira se não as escreveu em logs ou históricos (nossa opinião).

O que conferir na sua própria infraestrutura de inferência e de agentes à luz deste incidente está resumido abaixo, em «O que operadores de infraestrutura de IA devem revisar».

Neste relato, a execução de código em um servidor de inferência levou a outra infraestrutura. Não dar a um servidor de inferência credenciais nem conexões com sistemas de gestão internos e outros servidores, e limitar seu tráfego aos destinos de que precisa, pode reduzir até onde uma máquina comprometida se espalha (nossa opinião).

Os dados de conta que foram levados estavam em um sistema interno por trás do Private Chat, já descontinuado. Num serviço que você deixa de usar, não basta desligá-lo: apague os dados, revogue as credenciais e retire-o da rede. O que você mantém é o que fica exposto quando ocorre uma violação (nossa opinião).

Os 18 agentes estavam em uma implantação legada que não rodava no ambiente de computação confidencial. Fortalecer um ambiente novo deixa o legado como o lado fraco. Migre-o ou defina um prazo para desativá-lo, e aplique nesse meio-tempo os mesmos limites de permissão (nossa opinião).

A empresa diz que as chaves de API de dois clientes do Cloud ficaram expostas em logs. Não grave nos logs os cabeçalhos das requisições nem as configurações como estão, mascare chaves e tokens e limite o acesso ao local onde os logs ficam. Prepare de antemão os passos para revogar uma chave rapidamente caso ela apareça em um log (nossa opinião). Outro caso centrado no manuseio de chaves é O incidente de segurança da Northflank.

A empresa implantou a correção em todos os servidores de inferência e comunicou a falha ao projeto SGLang. Se você usa um mecanismo de inferência de código aberto, manter uma via de implantação que leve rápido a todos os servidores uma correção publicada, e um inventário das versões que roda, encurta o tempo entre perceber e corrigir (nossa opinião). Outra invasão a infraestrutura de IA é tratada em A invasão ao Hugging Face (em inglês).