Back to Blog

Hack de US$ 1,5 Bilhão na Bybit: Análise Detalhada do Ataque de Atualização Maliciosa da Carteira Safe

Phalcon
February 25, 2025
7 min read

A Bybit Exchange foi hackeada por volta das 14:00 UTC no dia 21 de fevereiro de 2025, resultando em perdas próximas a 1,5 bilhão – o maior incidente de segurança na história das criptomoedas até o momento. Ao contrário de violações de segurança anteriores, este roubo não foi causado por problemas com permissões de contratos inteligentes, mas sim por uma atualização maliciosa da carteira multisig Safe utilizada pela Bybit. O atacante enganou múltiplos operadores da carteira Safe para que assinassem uma transação de atualização da carteira, assumindo assim com sucesso o controle da carteira Safe. Uma vez no controle, o atacante esvaziou os fundos.

Descobrimos que este ataque foi uma operação meticulosamente planejada visando a Bybit, com o atacante tendo implantado e testado o contrato de ataque on-chain dois dias antes de lançar o ataque final. Nesta publicação do blog, começaremos com uma introdução à carteira Safe, analisaremos todo o processo do ataque e, por fim, ofereceremos algumas recomendações de segurança.

O que é uma Carteira Multisig Safe

Uma Carteira Multisig Safe é um tipo de carteira de contrato inteligente cuja característica principal é o uso de múltiplas chaves para autorizar transações. Essa carteira requer que múltiplos usuários (tipicamente detentores de chaves pré-designados) assinem uma transação antes que uma transferência ou outra operação possa ser executada, aumentando assim a segurança e prevenindo um ponto único de falha ou o comprometimento de uma única chave.

Quando a carteira é criada, múltiplas chaves são configuradas (geralmente usando um modelo "n-de-m"), significando que entre os múltiplos detentores de chaves, um certo número de assinaturas é necessário para que uma transação seja executada. Por exemplo, uma carteira multisig "3-de-5" significa que, dos cinco detentores de chaves, pelo menos três assinaturas são necessárias para que a transação seja válida.

Embora existam métodos para construir transações sem depender do site oficial da Safe, do ponto de vista da experiência do usuário, a maioria dos usuários opta por construir e assinar transações pelo site da Safe. Normalmente, os usuários acessam https://app.safe.global para criar transações. Ao usar uma carteira Safe para construir e assinar uma transação, os usuários primeiro simulam a transação para entender seu resultado potencial quando on-chain, e para verificar se ela está alinhada com suas expectativas. Somente se o resultado for o esperado é que o operador prosseguirá para concluir o processo de assinatura.

Abaixo está uma captura de tela da interface de construção de transações na carteira Safe. Como o site da Safe está atualmente indisponível temporariamente, a captura de tela a seguir foi obtida da internet (fonte: https://milkroad.com/reviews/safe-wallet/).

Na prática, ao usar uma carteira Safe, existem os seguintes riscos de segurança:

  • Longa cadeia de segurança: Os usuários devem confiar no site oficial da Safe, no aplicativo e nos serviços de backend, bem como em seu próprio computador e navegador, e por fim na carteira usada para assinar (seja uma extensão de navegador ou uma carteira de hardware). Se qualquer um desses componentes for comprometido por um atacante, o operador poderá receber informações incorretas (por exemplo, você pode estar assinando uma transação de atualização enquanto a interface exibe uma transação de transferência normal).

  • Falta de análise de transações em carteiras de hardware: As carteiras de hardware geralmente não possuem a capacidade de analisar transações Safe. Isso significa que, se os usuários forem induzidos em erro pela interface Safe, eles não têm meios de fazer uma verificação cruzada durante a assinatura final, levando ao que é conhecido como "assinatura às cegas."

Processo do Ataque

Antes de lançar o ataque final, o atacante já havia implantado e testado o contrato de ataque on-chain. Múltiplos endereços diferentes estavam envolvidos em todo o processo do ataque.

Passo 1: Obtenção de Fundos

O atacante primeiro precisava adquirir os fundos iniciais para o ataque. Tipicamente, os atacantes obtêm fundos por meio de plataformas de mistura (por exemplo, Tornado Cash) para ocultar seus rastros. No entanto, neste caso, os fundos do atacante vieram da Binance. Acreditamos que este pode ser o método do atacante para ocultar sua identidade, pois fundos e endereços de serviços de mistura geralmente são monitorados de perto por empresas de segurança, enquanto fundos provenientes de exchanges são monitorados com menos rigor. Além disso, embora os fundos tenham se originado de uma exchange, é possível que a conta da exchange não tenha passado por KYC, ou que suas informações de KYC tenham sido falsificadas.

https://metasleuth.io/result/eth/0x3b48fa59c2bBdF8D00D70aC40B2CdA576fC519E3?source=5d9ab32c-e958-4a8d-864f-f1f4e79d0d0c

Passo 2: Implantação e Teste do Contrato

Antes de lançar o ataque real, o atacante conduziu uma série de testes. Esses testes incluíram a implantação de uma carteira Safe, a implantação do contrato de ataque e o uso da carteira Safe auto-implantada para realizar uma operação de atualização, bem como a extração de fundos da carteira Safe atualizada. Além disso, durante os testes, o atacante experimentou apenas com uma faixa limitada de ativos – ativos que correspondiam àqueles na carteira que foi finalmente esvaziada na Bybit. Isso indica que o atacante visou especificamente a carteira Safe da Bybit.

O atacante criou uma carteira Safe para fins de teste; um dos endereços da carteira Safe de teste foi:
0x509b1eDa8e9FFed34287ccE11f6dE70BFf5fEF55

O atacante testou a atualização do contrato Safe. Podemos visualizar as informações relevantes pelo Phalcon Explorer no seguinte link:

https://app.blocksec.com/explorer/tx/eth/0x50a51f781567a003662b933fc1224a35d824ba695edce7687473800299c7d1ef

Após testar a atualização, o atacante prosseguiu para testar o processo de retirada. Eles extraíram diretamente ativos stEth do contrato Safe atualizado no endereço:

0x509b1eda8e9ffed34287cce11f6de70bff5fef55

https://app.blocksec.com/explorer/tx/eth/0xa284658ddbe5af54bf056ea32147f0842990555510c5b752e3814dbfe0210e0c

Passo 3: Enganando Usuários para Construir e Assinar a Transação de Atualização

Após concluir os testes, o atacante precisava enganar os usuários para que construíssem e assinassem a transação de atualização do contrato Safe. Como os testes foram realizados dois dias antes, o engano provavelmente ocorreu dentro dos dois dias seguintes aos testes. Ainda não foi confirmado publicamente se isso foi alcançado por meio de um ataque aos servidores da Safe ou aos computadores dos operadores da carteira.

Passo 4: Lançamento do Ataque

Uma vez que o atacante obteve um número suficiente de assinaturas, ele submeteu a transação on-chain e executou com sucesso a atualização do contrato. Após a atualização, o atacante extraiu os fundos. Descobrimos que a transação de atualização maliciosa era idêntica à transação de teste anterior.

https://app.blocksec.com/explorer/tx/eth/0x46deef0f52e3a983b67abf4714448a41dd7ffd6d32d32da69d62081c68ad7882

Lições e Reflexões

Na verdade, ataques semelhantes ocorreram duas vezes no ano passado – incluindo os roubos da Radiant e da exchange indiana WazirX (com perdas superiores a $200 milhões) – ambos resultantes de transações maliciosas assinadas usando carteiras Safe. A diferença neste incidente é que a transação assinada desta vez foi uma transação de atualização de contrato. Portanto, aprender lições com esses incidentes de segurança e prevenir ataques futuros continua sendo um desafio que exchanges e equipes de projetos que detêm grandes quantidades de ativos digitais devem enfrentar. Isso pode ser alcançado por meio da melhoria das operações cotidianas, da gestão de processos internos, dos protocolos de segurança para operações sensíveis e das configurações de descentralização para reduzir o risco de ser atacado.

Em segundo lugar, a questão de como as carteiras podem participar melhor no processo de segurança durante a assinatura de transações permanece sem solução. Atualmente, especialmente as carteiras de hardware tipicamente não possuem a capacidade de analisar transações complexas. Além disso, como as carteiras de hardware não se conectam diretamente à internet, como realizar simulações de transações (e apresentar os resultados aos usuários de forma facilmente compreensível) para evitar a assinatura às cegas continua sendo um desafio.

Adicionalmente, é necessário implementar múltiplas medidas de segurança, como empregar plataformas de monitoramento de segurança como o BlockSec Phalcon para monitorar carteiras Safe, garantindo que qualquer comportamento anormal seja prontamente detectado e tratado. Na prática, o Phalcon já possui a capacidade de monitorar carteiras Safe, e continuaremos a aprimorar nossos produtos para que tal monitoramento possa ser configurado automaticamente no futuro, ajudando os usuários a evitar riscos ao usar a Safe para gerenciar grandes quantidades de ativos. Embora este incidente tenha sido causado pelo uso de uma carteira Safe, não há necessidade de temer a "Safe"; ela continua sendo o padrão de fato para carteiras multisig, com sua segurança de contrato tendo sido comprovada ao longo do tempo.

Por fim, devemos enfatizar que a defesa de segurança nunca é um campo de batalha para avanços em um único ponto, nem existe uma bala de prata que funcione de uma vez por todas. Ao mesmo tempo em que garantem a segurança operacional e de negócios, os participantes do setor podem usar o BlockSec Phalcon como a última linha de defesa para proteger seus ativos.