A ferramenta de programação da Google ia guardar o modelo de inteligência artificial (IA) de um cliente numa morada que qualquer pessoa conseguia adivinhar à partida. Um investigador registou essa morada primeiro, esperou que o modelo lá chegasse e trocou-o por uma versão envenenada. Fez tudo em 1,4 segundos, antes de a própria Google chegar a ler o ficheiro.
A história vale menos pelo que diz sobre a Google e mais pelo que diz sobre a forma como tratamos a IA. Não houve aqui nenhuma inteligência derrotada, nem nenhum modelo «hackeado» por outra IA mais esperta. Houve um nome de pasta previsível e uma verificação que faltava. É um daqueles erros aborrecidos que arrastamos há vinte anos, agora sentados por baixo da corrida ao ouro da IA, onde quase ninguém olha para os canos por onde os modelos passam.
Uma morada que se escrevia de cor
A falha foi descrita pela Unit 42, a equipa de investigação da Palo Alto Networks, que lhe chamou «Pickle in the Middle» (um ataque pelo meio, no caminho). Afeta o kit de ferramentas de programação (SDK) do Vertex AI, a plataforma de IA da Google na cloud. Quando o programador não escolhia onde guardar o modelo, o SDK inventava sozinho o nome do «balde» de armazenamento (a pasta onde o ficheiro fica) a partir de dados públicos: o identificador do projeto e a região. O resultado era previsível ao ponto de se escrever de cor.
E o SDK verificava apenas se esse balde já existia, nunca se pertencia a quem o estava a usar. Bastava ao atacante criar primeiro um balde com esse nome na sua própria conta, uma técnica a que se chama bucket squatting, ocupar a morada antes do dono, para que os modelos da vítima fossem entregues, sem ruído, na conta dele.
É aqui que a coisa passa de roubo a controlo. Os modelos de IA em Python costumam ser guardados num formato chamado pickle, que executa código no momento em que é aberto. Quem controla o ficheiro pode esconder lá dentro ordens que correm na máquina que o for ler. Foi o que a Unit 42 demonstrou: uma função automática disparava no instante do envio e substituía o modelo legítimo por um envenenado em 1,4 segundos, dentro da janela de cerca de 2,5 segundos que existia até a Google ler o ficheiro. O fim da linha é execução de código remoto (RCE), correr os comandos do atacante dentro da infraestrutura da vítima, e a agravar tudo, entre clientes diferentes da mesma cloud. O atacante nunca precisou de entrar na casa de ninguém.
Não foi azar, foi padrão
A Google aceitou o relatório, classificou-o como prioridade máxima e corrigiu em duas fases: primeiro acrescentou um código aleatório ao nome do balde, em março, depois passou a verificar quem é o dono, na versão 1.148.0 do SDK, a 15 de abril. O detalhe que devia tirar-nos o sono é outro. Esta foi a segunda vez. Em fevereiro, a Google já tinha corrigido uma falha da mesma família no Vertex AI (a CVE-2026-2473, o nome público de uma vulnerabilidade conhecida), também por baldes com nomes previsíveis, também com troca de modelos entre clientes. Quando o mesmo erro aparece duas vezes no mesmo sítio, deixou de ser distração e passou a ser um traço de desenho.
Quem investiga incidentes conhece a regra: uma prova só vale se a cadeia de custódia estiver intacta, se soubermos por que mãos passou desde a origem. Um modelo de IA merece o mesmo cuidado. Entre o sítio onde foi treinado e o sítio onde corre, ninguém devia poder mexer-lhe sem deixar rasto. Aqui, a cadeia partiu-se logo no primeiro passo, e a plataforma serviu o ficheiro trocado como se nada fosse. É também por isto que a Europa começou a tratar a cadeia de fornecimento de software como matéria de segurança e não de logística: a diretiva NIS2 e o trabalho do Centro Nacional de Cibersegurança sobre risco na cadeia de abastecimento assentam no mesmo princípio, o de que confiar num fornecedor não é confiar em tudo o que ele monta por baixo.
Como te proteges
Para quem põe IA na cloud, há medidas concretas:
- Atualizar o SDK do Vertex AI para a versão 1.148.0 ou mais recente, onde a verificação de dono já existe.
- Nunca deixar a ferramenta escolher sozinha onde guarda os modelos: definir sempre, à mão, o balde de armazenamento de destino.
- Tratar um modelo como código, não como um ficheiro de dados inofensivo. Um modelo em pickle pode executar ordens ao ser aberto, por isso só deve vir de fonte de confiança e validada.
- Preferir formatos que não correm código ao serem abertos, como o safetensors, sempre que for possível.
- Vigiar as permissões das contas de serviço (a identidade que o sistema usa para se autenticar), para que um modelo comprometido não tenha por onde alastrar.
Gastamos o discurso todo a temer que a inteligência artificial se vire contra nós. Esta semana, para a sequestrar, bastou um nome previsível e uma verificação que ninguém fez. A ameaça mais avançada continua a entrar pela porta mais antiga.
Fonte original: Unit 42 (Palo Alto Networks).
#StaySafe
🙏🖖
