Ataque à Bybit: US$ 1,5 bilhão roubado via JavaScript malicioso

Em 21 de fevereiro de 2025, o mundo das criptomoedas testemunhou um dos maiores roubos cripto já registrados. Hackers roubaram US$ 1,5 bilhão da Bybit, uma das principais exchanges de criptomoedas. Eles se valeram de engenharia social, o que demonstra que a segurança como um todo vai muito além de senhas e firewalls.

Investigações conduzidas por empresas de segurança e um Comunicado de Serviço Público oficial do FBI apontam que esse ataque está ligado ao Lazarus Group, uma organização cibercriminosa norte-coreana conhecida por roubar grandes quantias para financiar as atividades do país (como, por exemplo, o assalto ao Banco de Bangladesh). O FBI denomina essa operação norte-coreana específica de "TraderTraitor."

O que aconteceu

A Bybit utiliza uma carteira multisignature para proteger seus fundos. Uma carteira multisig funciona como um cofre que exige múltiplas chaves de diferentes funcionários para ser aberto. Nenhuma pessoa sozinha consegue movimentar o dinheiro e as moedas.

No entanto, os hackers não acessaram o cofre diretamente. Em vez disso, eles alteraram a interface do usuário (o front end) que os funcionários utilizam para aprovar transações, enganando os detentores das chaves para que assinassem transações falsas sem perceber.

Como aconteceu

1) Ataque ao Front-End (Client-Side)

Os atacantes injetaram JavaScript malicioso na interface do site onde os funcionários da Bybit normalmente aprovam transações. Esse código malicioso estava oculto de tal forma que tudo parecia normal na tela — mas nos bastidores, ele alterava detalhes importantes.

A maioria das empresas foca exclusivamente na segurança do backend ou em carteiras de hardware. Mas se o front end for comprometido, ele pode alterar transações silenciosamente antes mesmo de o usuário clicar em "Aprovar". Foi por isso que criamos o cside: para permitir que sites monitorem dependências no navegador de seus usuários e evitem ataques como esse.

Os hackers usaram e-mails de phishing e mensagens falsas para convencer os funcionários de que as transferências eram rotineiras.

2) Truque com Delegatecall + Proxy

Mesmo que a Bybit utilizasse um "cofre" multisig, o JavaScript malicioso alterou o tipo de transação de uma "call" normal para algo chamado "delegatecall."

• O delegatecall permitiu que os hackers executassem seu próprio código como se ele fizesse parte do contrato do cofre.
• Eles usaram isso para alterar o endereço do "master copy" do cofre — um componente essencial do funcionamento dessa carteira específica — apontando-o para o contrato dos atacantes.
• Com essa alteração, os atacantes puderam executar funções especiais de "sweep" que esvaziaram o cofre de US$ 1,5 bilhão.

Análise técnica detalhada

Com base na análise de @S1r1u5_ no X.

Veja o passo a passo técnico de como a Safe{Wallet} foi comprometida:

1. JavaScript Malicioso Injetado

• Os atacantes adicionaram código malicioso em app.safe.global/_next/static/chunks/pages/_app-4f0dcee809cce622.js. Em essência, um dos desenvolvedores comprometidos o enviou para produção.

2. Alvo: executeTransaction()

• O JS malicioso só era ativado se reconhecesse uma lista predefinida de signatários (neste caso, os proprietários da multisig da Bybit).

3. Troca para delegatecall

• Em vez de uma call normal, o código malicioso alterava a operação para 1, que corresponde ao delegatecall. Isso delegava a execução para um contrato do atacante.

4. Alteração do Storage da Safe

• Ao usar delegatecall, o contrato do hacker efetivamente reescrevia o slot de storage masterCopy da carteira Safe.

5. Novo Master Copy Drena os Fundos

• O novo contrato malicioso de "master copy" continha as funções sweepETH() e sweepERC20(), permitindo ao atacante drenar US$ 1,5 bilhão em criptomoedas.

Essa cadeia de eventos permitiu ao atacante contornar todas as proteções normais de multisignature, já que a transação aparecia na interface da carteira como válida.

Em resumo:

1. Ataques ao Front-End São Subestimados As pessoas costumam focar nos servidores de backend, mas uma simples alteração no código do site pode induzir usuários a assinar qualquer coisa.
2. Erro Humano A engenharia social se aproveita de pessoas que estão com pressa ou que confiam no conteúdo de e-mails. Uma mensagem falsa bem elaborada pode enganar até equipes bem treinadas.
3. Delegatecall + Padrões de Proxy Muitas carteiras cripto e protocolos DeFi utilizam contratos "proxy" para maior flexibilidade. Infelizmente, se um atacante redirecionar o ponteiro para seu próprio código, ele pode assumir o controle total.
4. Interfaces Enganosas A interface exibia tudo como "legítimo", então os signatários não tinham como saber que estavam aprovando transações maliciosas.
5. Sistemas Complexos Mesmo com múltiplas camadas de segurança, uma única falha na conscientização do usuário ou na integridade do front end pode comprometer tudo.

Por que ataques client-side são difíceis de investigar

Quando hackers atacam por meio de código client-side (o JavaScript e o HTML que rodam no navegador), coletar evidências forenses depois pode ser especialmente complicado:

1. Dados Efêmeros:

• Sessões de navegador têm vida curta, e os registros de quais arquivos JavaScript foram carregados — e como foram alterados — podem estar incompletos ou simplesmente não existir. Ao contrário dos logs do lado do servidor, os logs de front end frequentemente não são armazenados de forma persistente.

2. Implantação e Atualizações Rápidas:

• Aplicações web modernas atualizam ou reimplantam código com frequência. Quando um atacante injeta scripts maliciosos, ele pode revertê-los com a mesma rapidez — deixando apenas uma janela de tempo muito curta para capturar evidências.

3. Logs de Servidor Limitados:

• Mesmo que o lado do servidor esteja seguro, a ação real acontece no navegador do usuário. Os logs padrão do servidor podem mostrar que um arquivo foi servido, mas não necessariamente quais alterações foram feitas nesse arquivo ou como ele se comportou após a execução.

4. Falta de Transparência no Controle de Versão:

• Algumas equipes não mantêm um registro público de cada build de front end. Se a alteração maliciosa foi introduzida por meio de um pipeline de build comprometido, as equipes forenses precisam de históricos detalhados de versões — e esses registros podem ser mal rastreados ou facilmente manipulados.

5. Dependência de Terceiros:

• O código client-side frequentemente carrega bibliotecas externas ou CDNs. Se o script malicioso foi injetado por meio de um serviço de terceiros, as equipes forenses precisam coordenar com fornecedores externos que podem não manter logs detalhados ou ser lentos para cooperar.

Para investigadores forenses, tudo isso significa que reconstruir um ataque client-side pode envolver reunir fragmentos de caches de navegador, logs do console do desenvolvedor, históricos de implantação e quaisquer dados de versionamento disponíveis no pipeline de build. É possível — mas é significativamente mais desafiador do que investigar um comprometimento tradicional do lado do servidor, onde normalmente há logs mais claros e acesso direto ao sistema comprometido.

Como o cside poderia ter ajudado

O cside é uma solução que analisa scripts client-side de primeira parte e faz proxy de JavaScript de terceiros antes que eles sejam executados no seu site. Armazenamos os scripts por até um ano, oferecendo forense completa onde hoje você tem um ponto cego. Se a Bybit tivesse usado o cside, qualquer modificação inesperada ou maliciosa na interface da carteira Safe poderia ter sido detectada e bloqueada, potencialmente impedindo todo esse ataque.

Referências: https://x.com/lookonchain/status/1892965762186522975 https://x.com/lookonchain/status/1892971811807387877 https://x.com/lookonchain/status/1893223657838633177