Em 12 de novembro, a Chainstack divulgou um relatório sobre o incidente. Em 26 de outubro, os invasores entraram no ambiente de desenvolvimento dessa provedora de infraestrutura de nós. No dia 29, acessaram alguns sistemas do ambiente de produção. O ataque foi detectado e interrompido no próprio dia 31, e a investigação foi concluída em 2 de novembro. É possível que informações das contas dos clientes tenham sido acessadas, e as credenciais dos nós foram tratadas como comprometidas. Os clientes estão sendo orientados a trocar as senhas, renovar as credenciais e gerar novas chaves de API. Os nós, o console e a API dos clientes não foram alterados. Como as informações de cartão bancário nem sequer eram armazenadas, elas não vazaram.

O ponto de entrada era incrivelmente vulnerável. Um cluster Kubernetes usado para desenvolvimento tinha um Grafana exposto à internet, com a senha padrão de administrador ainda ativa e sem autenticação única nem autenticação básica. O Grafana tem uma função de proxy de fontes de dados, que pode encaminhar solicitações para serviços da rede interna. Os invasores a usaram para chegar a um servidor de ferramentas MCP sem autenticação, cuja conta de serviço tinha permissões de administrador do cluster. Em 31 de outubro, os invasores leram em massa as chaves do cofre de chaves de produção e usaram uma chave VPN roubada para se conectar à rede do banco de dados e consultar o banco de dados de produção.

O aspecto mais digno de atenção nesta invasão são as ferramentas. A Chainstack afirma ter alta confiança de que os invasores usaram o ARTEX, uma estrutura de código aberto que coordena agentes de modelos de linguagem de grande escala para executar automaticamente etapas de invasão. As evidências do ataque estão repletas de marcas como artx e artex. O relatório também deixa claro que isso indica apenas quais ferramentas foram usadas, não quem as estava operando. Nenhuma vulnerabilidade de software foi explorada em toda a cadeia: o ataque combinou senhas padrão, falta de autenticação, permissões excessivas e credenciais de longa duração.

Os pequenos investidores normalmente não usam a Chainstack diretamente, mas carteiras, corretoras e serviços de nós funcionam por trás desse tipo de infraestrutura. Desta vez, os invasores não precisaram fazer tentativas um a um: um agente fez esse trabalho por eles. Quando erros básicos, como senhas padrão, permanecem no sistema, as máquinas podem transformá-los em incidentes de produção mais rápido do que as pessoas. Os nós dos clientes da Chainstack não foram alterados, e nenhum dinheiro foi movimentado. O que vazou foram informações de contas e credenciais. As credenciais de nós controlam os próprios nós; neste caso, foram tratadas como comprometidas. Até serem trocadas, qualquer pessoa que as tivesse poderia controlar os nós.

Minha opinião se resume a uma frase: para se proteger de ataques com IA, não adianta esperar que o outro cometa um erro; é preciso primeiro fechar a própria porta. Troque as senhas padrão, não deixe ambientes de teste expostos à internet, revogue permissões desnecessárias e troque regularmente as credenciais de longa duração. Os pequenos investidores podem fazer três coisas: mudar senhas reutilizadas em vários serviços, revogar autorizações que não usam e, ao receber um e-mail que supostamente é da plataforma, conferir o remetente antes de clicar. Nada disso é novidade, mas este incidente prova que ainda há muita gente cometendo esses erros.

Quando foi a última vez que você trocou suas senhas com cuidado e revogou autorizações que não usa?

#Chainstack #AI攻击 #Grafana #MCP #SegurançaDosNós

— Xiaokai, o investidor de varejo do Web3

Aviso: isto é apenas uma opinião pessoal e não constitui recomendação de investimento. O mercado de criptomoedas envolve riscos extremamente elevados; invista apenas o que você pode perder. Fontes dos fatos: relatório oficial da Chainstack sobre o incidente, Crypto Economy e CoinTime.