Em 21 de fevereiro de 2025, a Bybit perdeu aproximadamente US$ 1,5 bilhão após um invasor comprometer a máquina de um desenvolvedor do Safe{Wallet} por meio de engenharia social. O invasor injetou JavaScript malicioso no bucket AWS S3 do Safe{Wallet}, visando especificamente as transações da Bybit. O código injetado alterou o conteúdo das transações durante o processo de assinatura: a interface do Safe{Wallet} exibia uma transação legítima, enquanto o payload real enviado aos dispositivos Ledger dos signatários atualizava o contrato Safe da Bybit para uma implementação maliciosa, dando ao invasor controle total. Uma vez assinado e executado, o invasor drenou todos os ativos do contrato. Uma análise técnica detalhada está disponível em nosso relatório anterior [1].
Contexto
O Safe{Wallet} (também conhecido como GnosisSafe) é uma infraestrutura de carteira multisig que utiliza um modelo n-de-m: executar uma transação requer pelo menos n assinaturas de m signatários no total.
Cada carteira Safe é implantada como um contrato proxy. Duas variáveis de armazenamento são centrais para este incidente:
masterCopy(slot 0): o endereço do contrato de implementação. Este contrato contém toda a lógica de execução, incluindo verificação de assinaturas e mecanismos de atualização. O proxy delega todas as chamadas aomasterCopyviadelegatecall.threshold(slot 4): o número mínimo de assinaturas (n) necessárias. Para o Safe da Bybit, esse valor era 3.
Como o proxy utiliza delegatecall, qualquer função chamada no masterCopy é executada no contexto de armazenamento do proxy. Isso significa que um alvo de delegatecall pode sobrescrever diretamente o masterCopy no slot 0, substituindo toda a implementação em uma única transação.
Análise de Vulnerabilidade
O caminho do ataque atravessou três camadas do sistema, cada uma apresentando uma condição estrutural que o invasor explorou:
Modelo de entrega do frontend. O JavaScript do frontend do Safe{Wallet} era servido a partir de um bucket AWS S3. Nessa arquitetura, qualquer pessoa com acesso de escrita ao bucket pode modificar o código que constrói as transações para os signatários. Mecanismos de verificação de integridade, como hashes de integridade de sub-recursos (SRI) ou assinatura de código, podem mitigar esse risco, mas ainda não são práticas padrão para a maioria dos frontends de dApps. O invasor obteve acesso de escrita por meio da máquina do desenvolvedor comprometida e modificou silenciosamente o JavaScript servido.
Lacuna entre a exibição na interface e o payload de assinatura. O JavaScript injetado exibia uma transação de aparência legítima na interface do Safe{Wallet}, enquanto enviava um payload diferente para as carteiras hardware Ledger. Os detalhes da transação exibidos na tela do Ledger seriam diferentes dos mostrados na interface, mas interpretar dados brutos de transação na tela de uma carteira hardware não é simples, especialmente para operações multisig complexas. Essa lacuna permitiu que o invasor coletasse três assinaturas válidas para o payload malicioso.
Modelo de atualização de proxy. Conforme descrito no Contexto, o delegatecall executa o código do alvo no contexto de armazenamento do proxy. A arquitetura do proxy Safe roteia todas as chamadas por meio de um único ponteiro masterCopy no slot 0. Sobrescrever esse ponteiro redireciona o proxy para uma implementação completamente diferente, incluindo sua lógica de verificação de assinaturas, em uma única transação. O modelo n-de-m governa quem pode iniciar uma transação, mas uma vez que a transação é aprovada e executada, ela pode alterar a própria implementação. Se a nova implementação remover a verificação de assinaturas, a proteção multisig deixa de existir efetivamente para todas as transações subsequentes.
Análise do Ataque
O ataque ocorreu em três etapas: Injeção de Código Malicioso, Substituição da Implementação e Roubo de Ativos.
Etapa 1: Injeção de Código Malicioso
O invasor comprometeu a máquina de um desenvolvedor do Safe{Wallet} e injetou JavaScript malicioso no bucket AWS S3 que servia o frontend. O código injetado visava especificamente as transações do endereço Safe da Bybit. De acordo com o CEO da Bybit, Ben Zhou [2], a interface do Safe{Wallet} exibia uma transação legítima, enquanto um payload diferente era enviado aos dispositivos Ledger dos signatários. Os signatários aprovaram a transação conforme apresentada na interface, fornecendo ao invasor três assinaturas válidas para o payload malicioso.
Etapa 2: Substituição da Implementação
O invasor submeteu a transação maliciosa com as três assinaturas coletadas. O proxy Safe delegou a chamada ao masterCopy, cuja função execTransaction() validou as assinaturas e então executou o payload da transação: um delegatecall para o contrato do invasor (0x962214...5c7242). Como esse delegatecall é executado no contexto de armazenamento do proxy, a função transfer() do invasor sobrescreveu o valor do masterCopy no slot 0 com um endereço de implementação maliciosa (0xbDd077...9516). A partir desse ponto, todas as chamadas ao contrato Safe foram delegadas ao código do invasor.
Etapa 3: Roubo de Ativos
Com o masterCopy apontando agora para a implementação do invasor, o requisito de multisig deixou de se aplicar. O invasor chamou SweepERC20() e SweepETH() diretamente no contrato Safe. Essas funções, definidas no contrato de implementação do invasor, transferiram todos os ativos mantidos sem qualquer verificação de assinatura. Cinco transações de drenagem foram executadas, totalizando aproximadamente US$ 1,5 bilhão em perdas.
Contratos e Transações Relacionados
| Tipo | Descrição | Endereço / Hash |
|---|---|---|
| Contrato | Contrato Safe da Bybit | 0x1Db92e2EeBC8E0c075a02BeA49a2935BcD2dFCF4 |
| Contrato | O contrato masterCopy original | 0x34CfAC646f301356fAa8B21e94227e3583Fe3F5F |
| Contrato | O contrato masterCopy malicioso | 0xbDd077f651EBe7f7b3cE16fe5F2b025BE2969516 |
| Contrato | O contrato do invasor (isto é, transfer()) | 0x96221423681A6d52E184D440a8eFCEbB105C7242 |
| Transação | Tx que substituiu o contrato masterCopy | 0x46deef0f52e3a983b67abf4714448a41dd7ffd6d32d32da69d62081c68ad7882 |
| Transação | Tx que drenou 15.000 cmETH | 0x847b8403e8a4816a4de1e63db321705cdb6f998fb01ab58f653b863fda988647 |
| Transação | Tx que drenou 90.375 stETH | 0xa284a1bc4c7e0379c924c73fcea1067068635507254b03ebbbd3f4e222c1fae0 |
| Transação | Tx que drenou 8.000 mETH | 0xbcf316f5835362b7f1586215173cc8b294f5499c60c029a3de6318bf25ca7b20 |
| Transação | Tx que drenou 401.346 ETH | 0xb61413c495fdad6114a7aa863a00b2e3c28945979a10885b12b30316ea9f072c |
| Transação | Tx que drenou 90 USDT | 0x25800d105db4f21908d646a7a3db849343737c5fba0bc5701f782bf0e75217c9 |
Resumo
Este incidente demonstrou como o comprometimento de uma infraestrutura fora da cadeia pode se transformar em perdas catastróficas na cadeia. O invasor encadeou uma violação Web2, uma manipulação de frontend e uma atualização de proxy em um único caminho de ataque que contornou a proteção multisig sem explorar nenhuma vulnerabilidade na cadeia.
Principais lições:
- A integridade do frontend merece a mesma atenção que a segurança na cadeia. A cadeia de ataque começou na camada de entrega do frontend. À medida que os dApps cada vez mais intermediam transações de alto valor, proteger o código do frontend com verificação de integridade (SRI, assinatura de código, builds reproduzíveis) e monitoramento de alterações não autorizadas torna-se um requisito básico.
- A verificação em carteiras hardware continua difícil na prática. As carteiras hardware podem exibir o payload de assinatura real, mas interpretar dados complexos de transações multisig em uma tela pequena é um desafio de usabilidade conhecido. Melhorar a legibilidade dos resumos de transações exibidos no dispositivo é um problema em aberto para o ecossistema de carteiras.
- Os mecanismos de atualização de proxy são alvos de alto impacto. A arquitetura do proxy Safe roteia toda a lógica por meio de um único ponteiro atualizável. Qualquer mecanismo que permita a substituição da implementação em uma única etapa concentra o risco. Adicionar um timelock, uma etapa de confirmação secundária ou um guardião independente para atualizações pode reduzir o impacto de uma única transação comprometida.
Referências
Sobre a BlockSec
A BlockSec é uma provedora completa de segurança em blockchain e conformidade em criptoativos. Desenvolvemos produtos e serviços que ajudam nossos clientes a realizar auditorias de código (incluindo contratos inteligentes, blockchains e carteiras), interceptar ataques em tempo real, analisar incidentes, rastrear fundos ilícitos e cumprir obrigações de AML/CFT, ao longo de todo o ciclo de vida de protocolos e plataformas.
A BlockSec publicou diversos artigos de segurança em blockchain em conferências de prestígio, reportou vários ataques de dia zero em aplicações DeFi, bloqueou múltiplos ataques para resgatar mais de 20 milhões de dólares e protegeu bilhões em criptomoedas.
-
Site oficial: https://blocksec.com/
-
Conta oficial no Twitter: https://twitter.com/BlockSecTeam
