Quando o MFA deixou de ser MFA: ataque à Retool comprometeu 27 clientes e levou ao roubo de 15 milhões de dólares

São Francisco, A Retool, plataforma de desenvolvimento de software usada por empresas como Amazon, Mercedes-Benz, DoorDash e Stripe, confirmou que 27 dos seus clientes cloud, todos do setor das criptomoedas, foram comprometidos num ataque de engenharia social em várias fases. Entre as vítimas esteve a Fortress Trust, a quem foram roubados cerca de 15 milhões de dólares em criptomoeda, segundo noticiou a CoinDesk.

Um SMS, uma chamada, uma conta Google

O ataque, a 27 de agosto de 2023, começou com uma campanha de phishing por SMS dirigida a funcionários da Retool. As mensagens faziam-se passar pelo departamento de TI e alegavam um problema de conta que impediria a inscrição no plano de saúde da empresa, com um link disfarçado do portal interno de identidade. O timing foi cirúrgico: coincidiu com uma migração de logins para a Okta que a empresa tinha anunciado internamente.

A maioria dos funcionários ignorou a mensagem. Um clicou, entrou no portal falso e introduziu a password e um código do Google Authenticator. Pouco depois, recebeu uma chamada de alguém que se apresentou como membro da equipa de TI, e que conhecia a planta do escritório, os nomes dos colegas e os processos internos. Nessa chamada, o funcionário forneceu um código MFA adicional.

O multiplicador: os códigos estavam todos na nuvem

Foi aqui que o incidente passou de mau a catastrófico. O funcionário tinha ativa a sincronização na nuvem do Google Authenticator, funcionalidade introduzida pela Google em abril de 2023. Ao controlar a conta Okta, o atacante chegou à conta Google; e ao controlar a conta Google, obteve todos os códigos OTP guardados no autenticador desse funcionário.

Nas palavras do responsável de engenharia da Retool, Snir Kodesh, o que a empresa tinha implementado como autenticação multifator tinha-se tornado, silenciosamente e sem conhecimento dos administradores, autenticação de fator único. A Retool classificou a funcionalidade de sincronização como um «dark pattern».

Com acesso aos sistemas internos de administração, o atacante assumiu o controlo das contas de 27 clientes, alterando os emails associados e redefinindo as palavras-passe. A Retool revogou todas as sessões internas, restringiu as contas afetadas e sublinhou que os clientes on-premise não foram afetados.

A lição: centralizar sim, mas num sistema desenhado para isso

Este caso é frequentemente lido como um argumento contra a centralização de códigos 2FA. É precisamente o contrário: é um argumento contra a centralização acidental, feita numa app pessoal, sincronizada com uma conta de email, sem que ninguém na organização saiba ou controle.

Três falhas estruturais tornaram o ataque possível:

1. Os seeds TOTP viajaram para fora do dispositivo sem conhecimento da empresa, colados a uma conta pessoal que era, ela própria, phishável.
2. Comprometer um único cofre entregou os dois fatores. Quando os códigos vivem ao lado das credenciais que os protegem, o MFA é uma ilusão.
3. Não havia forma de revogar ou auditar. A empresa não sabia onde estavam os seeds, quem os tinha, nem conseguia cortá-los num clique.

Um sistema de 2FA pensado para equipas resolve exatamente estes três pontos: os seeds ficam num cofre dedicado e nunca são expostos aos utilizadores, cada acesso é individual e registado, e a revogação é imediata. A diferença entre a Retool e uma equipa protegida não é usar ou não usar TOTP, é saber, a cada momento, onde estão as chaves e quem lhes pode tocar.