O hack da Binance e uma lição de como gerir uma catástrofe

A 29 de outubro, foram roubados à Binance cerca de 6,34 mil milhões de dólares em ativos digitais, no maior roubo de cripto de que há registo. Segundo a empresa, 2,85 mil milhões foram congelados ou intercetados. A 3 de novembro publicou um primeiro relatório, a pedir desculpa e a descrever todo o processo, incluindo os próprios erros.

A Binance disse a 30 de outubro que não tinha encontrado indícios de fuga de nenhuma chave privada. Segundo o relatório, o atacante usou um acesso não autorizado a um serviço interno de assinatura para iniciar transações fora do processo normal de levantamentos.

Não creio que as pessoas estejam a perceber mal este hack. Mas, no geral, acho que não percebem bem que um serviço ter acesso a enviar transações para uma chave assinar é, em sentido prático, basicamente a mesma coisa que ter a chave comprometida. Como disse à WIRED Middle East, quando o software com permissões de assinatura é comprometido, pouco importa que a chave esteja segura.

O que aconteceu

Em junho, um engenheiro instalou uma versão adulterada do Homebrew. A Binance detetou a anomalia, trocou o computador e renovou as credenciais, mas a função dele e a da equipa de carteiras ficaram expostas ao atacante. Em setembro, outro engenheiro foi abordado numa plataforma de emprego e, depois de uma falsa entrevista, descarregou para o computador de trabalho um "exercício" com um repositório malicioso. A 20 de outubro, a partir desse computador e com uma ferramenta interna de IA, o atacante comprometeu mais dois engenheiros da equipa de carteiras, entre eles o de junho, que tinha um token para lançar contentores. A 29 de outubro lançou um contentor com um script malicioso. Esse contentor teria acesso privilegiado ao software que assina os levantamentos. A 30 de outubro, a Binance já tinha dito que o acesso a um contentor de serviço permitiu submeter levantamentos não autorizados.

Entre as 20:05 e as 20:09 UTC, cinco hot wallets enviaram 233 milhões de XRP. Na Ethereum, o atacante usou o serviço de assinatura para dar, através do EIP-7702, direitos parciais de execução sobre uma hot wallet a um contrato seu, com 50 autorizações pré-assinadas, uma para cada número de transação seguinte. Essa hot wallet usava MPC, sem uma chave privada única, e isso não impediu o roubo. A última transferência ficou concluída às 23:56 UTC, quase quatro horas depois das primeiras.

Onde podia ter sido travado

O maior problema de cibersegurança das empresas é sempre o mesmo: as pessoas. Há muito que se pode fazer para implementar uma forte cultura de segurança, porque, no final de contas, uma equipa com consciência dos riscos tem menos problemas do que o contrário. No entanto, uma empresa tem de reconhecer que os humanos são fracos e que, a determinada altura, vão errar. Daí que os seus sistemas de segurança tenham de ter isto em conta e procurar que a resiliência, dentro do possível, não dependa de nenhum humano.

Como se vê neste caso, há vários níveis de prevenção. Em primeiro lugar, os engenheiros devem saber que não podem fazer atividades pessoais no computador da empresa, e isso teria prevenido qualquer ficheiro malicioso vindo de uma falsa entrevista de emprego. Assumindo que estavam a par e que, na mesma, foram enganados, os sistemas de monitorização podem fazer um melhor trabalho a verificar os ficheiros que são descarregados para as máquinas, os sites de onde vêm e o tráfego de entrada e de saída, entre outras coisas. A Binance diz que o malware, que classifica como 0-day, não foi detetado pelas ferramentas de proteção dos computadores.

No fundo, o problema passa sempre pelas coisas mais standard de cibersegurança: o menor privilégio possível, a monitorização contínua de ficheiros e aplicações nos computadores dos funcionários, a rotação frequente das credenciais das contas de serviço e dos tokens, e garantir que essas contas só têm os privilégios de que precisam. Isto tudo é fácil de dizer, mas no fim de contas é difícil tapar todos os buracos, sobretudo quando é uma nação que procura entrar. O FBI atribui o ataque à Coreia do Norte.

Uma coisa é certa: se não é normal que sejam retiradas estas quantidades de dinheiro, o serviço devia ter entrado em bloqueio logo na primeira transação. Isso poderia não ter resolvido as autorizações postas on-chain na Ethereum, e o relatório diz que suspender os levantamentos não as invalidou automaticamente, mas pelo menos poderia ter prevenido algumas transações noutras blockchains. Entre a primeira transferência, em XRP, e o roubo de 1,47 mil milhões de dólares da hot wallet de Bitcoin passaram quinze minutos.

Dados: TRM Labs e Galaxy Research.

Também se podem implementar medidas que verifiquem de antemão quanto dinheiro uma transação vai extrair, e associada a que utilizador, e que a bloqueiem em casos suspeitos. Para assinar uma nova mensagem, é preciso identificar com clareza o que ela contém. No caso da autorização EIP-7702 usada na Ethereum, que deu acessos difíceis de revogar a um smart contract malicioso, é preciso pelo menos perceber a quem se vai dar tais autorizações, e bloquear tudo o que não seja desejado. A Binance diz que está a rever a cobertura das políticas de assinatura e os controlos das hot wallets.

Resta saber porque é que as credenciais comprometidas chegavam a este nível de acesso. O relatório não o explica, e avisa que alguns detalhes técnicos vão ficar confidenciais.

Cronologia segundo o relatório da Binance.

Como a Binance respondeu

Dito isto, dou 10 em 10 à forma como a Binance lidou com a situação depois do ataque. "Isto não devia ter acontecido", escreve, antes de pedir desculpa aos utilizadores, aos parceiros e ao setor. O relatório mostra transparência e detalhe. A Binance admite falhas de segurança na equipa e nos sistemas de monitorização, o que torna o anúncio muito mais genuíno. O que distingue este caso é a magnitude sem precedentes do hack e o modo exemplar como lidaram com uma catástrofe desta dimensão.

A 30 de outubro, disse à Bloomberg que, apesar da promessa de cobrir as perdas, teríamos de esperar para ver. Era uma afirmação pragmática. A 1 de novembro, a Binance dizia ter reposto cerca de 95% dos ativos afetados, e o relatório fala em 98%. A Galaxy calculava, a 30 de outubro, que a perda líquida rondava os 4% dos cerca de 144 mil milhões de dólares em ativos que a Binance tinha antes do ataque, embora avisasse que não consegue verificar toda a situação financeira da empresa. A empresa escreve que absorve o impacto financeiro, não os utilizadores. O que, mais uma vez, mostra como a Binance foi capaz de fazer justiça aos seus utilizadores e, em certa medida, preservar a relação de confiança com eles e com toda a indústria.

Há quem possa dizer que a primeira declaração da Binance, no próprio dia, garantia que os fundos dos utilizadores estavam "completamente seguros", e que a causa começou por ser o portátil de um engenheiro e afinal era uma cadeia de meses. Mas, nas primeiras horas de uma crise, ninguém tem o quadro completo, e a Binance foi corrigindo a explicação em público à medida que a investigação avançava. E a garantia aos utilizadores está a ser cumprida.

A investigação continua e falta a revisão independente que a empresa anunciou. Ainda assim, a resposta foi uma verdadeira lição de como gerir uma catástrofe. Se calhar as pessoas não se apercebem de quão bem a Binance geriu isto.