Uma falha que ficou contida a um único nível
Os sistemas de segurança da Bitget detetaram transferências não autorizadas a partir de parte das suas hot wallets às 18h31 UTC de 24 de setembro. A corretora diz que as cold wallets e a grande maioria dos ativos da plataforma nunca foram tocados, e que o seu produto autocustodiado separado, a Bitget Wallet, não foi afetado. As transferências moveram ether, XRP, USDT, USDC, Avalanche e BNB em cinco redes.
A Bitget estimou a perda em 351,6 milhões de dólares e suspendeu os levantamentos por precaução enquanto a equipa de segurança realizava uma revisão completa. A diretora executiva Gracy Chen disse que os saldos das contas dos clientes permaneceram exatos e que os depósitos continuaram a ser processados normalmente, prometendo um relatório completo do incidente dentro de 24 horas.
A rede de segurança tinha um limite, e foi atingido
O User Protection Fund da Bitget existe precisamente para este cenário, e detinha cerca de 464 milhões de dólares antes da falha. Cobrir a totalidade da perda de 351,6 milhões apenas a partir desse fundo deixaria cerca de 112,4 milhões de dólares, abaixo dos 300 milhões que a Bitget declara manter como limite mínimo do fundo. À corretora não falta dinheiro. Falta-lhe a reserva específica construída para um dia exatamente assim.
Chen disse que a empresa detém mais de mil milhões de dólares em ativos próprios e que reporá o fundo, e que os fundos dos clientes permanecem cobertos a 100 por cento em qualquer caso. O buraco aberto por esta falha está a ser fechado pelo balanço da empresa, não pelos utilizadores.
| Valor | Montante |
|---|---|
| Fundo de proteção antes da falha | 464 milhões de dólares |
| Ativos roubados (cerca de 76 por cento do fundo) | 351,6 milhões de dólares |
| Fundo restante se a perda for paga na totalidade | 112,4 milhões de dólares |
| Limite mínimo declarado pela Bitget | 300 milhões de dólares |
Quem poderá estar por trás, e porque ainda não está confirmado
Chen disse que os investigadores encontraram endereços IP ligados a serviços VPN anteriormente associados a operações de pirataria norte-coreanas, e que o padrão do ataque lembrava campanhas anteriores atribuídas aos mesmos agentes. Um analista independente de blockchain seguiu o rasto de parte do XRP roubado até ao ataque à AFX em julho, já ligado pelos investigadores ao grupo Lazarus. A própria Bitget descreve a ligação à Coreia do Norte como uma hipótese de trabalho, não uma conclusão, e os investigadores dizem que a atribuição não foi confirmada de forma independente.
Essa cautela importa mais do que possa parecer. Os grupos ligados a estados visam especificamente infraestrutura cripto de custódia porque o ganho é elevado e o rasto forense é difícil de fechar depressa, e é exatamente por isso que a defesa tem de partir do princípio de que uma falha acabará por ter sucesso, em vez de apostar tudo em impedir cada uma delas.
O que qualquer empresa que guarde fundos de clientes deve retirar disto
A segmentação por níveis cumpriu a sua função. Distribuir os ativos entre armazenamento quente, morno e frio fez com que uma falha na camada exposta à internet não pudesse alcançar a maior parte dos fundos da plataforma, e essa contenção resistiu mesmo perante um atacante suficientemente capaz para ser um suspeito ator estatal. Essa parte do desenho é o modelo que vale a pena copiar, tanto para uma corretora cripto como para qualquer empresa que separa níveis de acesso à volta dos seus sistemas mais valiosos.
A parte que precisa de correção é o dimensionamento. Um fundo de reserva construído para cobrir uma falha também tem de continuar acima do seu próprio limite declarado depois do pagamento, e não apenas cobrir a perda em si. O fundo da Bitget conseguiu absorver esta falha, mas ainda assim precisou de um balanço de mil milhões de dólares por trás para não quebrar a sua própria regra. Dimensione a reserva para um mau dia mais o seu mínimo, não apenas para o mau dia sozinho.
Leia a seguir: Lazarus explorou um dia zero do Windows durante dez semanas | Investigadores externos descobriram três de quatro ataques da OpenAI



