Ataque à Bybit: US$ 1,5 mil milhões roubados através de JavaScript malicioso

Resumo: cronologia da injeção na interface Safe Wallet da Bybit

• A interface de assinatura falhou: O multisig não falhou à Bybit. A interface de assinatura falhou. Os atacantes reescreveram o que o assinante via no navegador, e cinco aprovadores assinaram, sem questionar, um delegatecall que apontava para código do atacante.
• Um ano de histórico de scripts: O script malicioso só era acionado para uma lista predefinida de signatários e moveu 1,5 mil milhões de dólares depois de o delegatecall trocar o master copy. O cside guarda cada script de terceiros durante até um ano, para que possa ver o build exato injetado depois do incidente.
• Monitorize o JavaScript de tesouraria: Se a sua interface de tesouraria carrega algum JavaScript de terceiros, monitorize-o em runtime já hoje. Se não carrega, presuma mesmo assim que o fornecedor da interface da carteira carrega, porque a Safe carregava.

Sem tempo? Veja o bloqueio in-browser de Magecart e skimmers da cside. Cobre tudo o que se segue numa única implementação.

Em 21 de fevereiro de 2025, o mundo das criptomoedas testemunhou um dos maiores roubos de criptoativos até hoje. Os hackers roubaram 1,5 mil milhões de dólares da Bybit, uma das principais exchanges de criptomoedas. Recorreram à engenharia social, o que mostra que a segurança, no seu todo, vai muito além de palavras-passe e firewalls.

Investigações conduzidas por empresas de segurança e um comunicado oficial de serviço público do FBI afirmam que este ataque está ligado ao Lazarus Group, uma organização cibercriminosa norte-coreana conhecida por roubar grandes quantias para financiar as atividades do país (por exemplo, o assalto ao Bangladesh Bank). O FBI designa esta operação norte-coreana específica como "TraderTraitor."

O que aconteceu

A Bybit utiliza uma carteira multisignature (multiassinatura) para proteger os seus fundos. Uma carteira multisig é como um cofre que precisa de várias chaves de diferentes funcionários para ser aberto. Nenhuma pessoa sozinha consegue movimentar o dinheiro e as moedas.

No entanto, os hackers não acederam diretamente ao cofre. Em vez disso, alteraram a interface do utilizador (o front end) que os funcionários usam para aprovar transações, enganando os detentores das chaves para que assinassem transações falsas sem perceberem.

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. Este código malicioso estava oculto de tal forma que tudo parecia normal no ecrã, mas, nos bastidores, alterava detalhes importantes.

A maioria das empresas foca-se exclusivamente na segurança do backend ou em carteiras de hardware. Mas, se o front end for comprometido, este pode alterar transações silenciosamente antes mesmo de o utilizador clicar em "Aprovar". Foi por isso que criámos o cside: para permitir que os sites monitorizem dependências no navegador dos seus utilizadores e evitem ataques como este.

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

Ainda 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 o seu próprio código como se este fizesse parte do contrato do cofre.
• Usaram isto para alterar o endereço do "master copy" do cofre, um elemento essencial do funcionamento desta carteira específica, apontando-o para o contrato dos atacantes.
• Com essa alteração feita, os atacantes conseguiram executar funções especiais de "sweep" que esvaziaram o cofre de 1,5 mil milhões de dólares.

Análise técnica detalhada

Com base na análise de @S1r1u5_ no X, eis um resumo passo a passo 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, depois de um dos programadores comprometidos o ter enviado para produção.
2. Ataque direcionado ao executeTransaction(): o JS malicioso só era acionado se reconhecesse uma lista predefinida de signatários (neste caso, os proprietários da multisig da Bybit).
3. Mudança para delegatecall: em vez de uma call normal, o código malicioso alterava a operação para 1, que corresponde ao delegatecall, delegando a execução a um contrato do atacante.
4. Alteração do storage da Safe: ao usar o delegatecall, o contrato do hacker reescreveu o slot de storage masterCopy da carteira Safe.
5. O novo master copy drena os fundos: o novo contrato malicioso de "master copy" continha as funções sweepETH() e sweepERC20(), permitindo ao atacante drenar 1,5 mil milhões de dólares em criptomoedas.

Esta cadeia de eventos permitiu ao atacante contornar todas as proteções normais de multiassinatura, uma vez que a transação surgia na interface da carteira como válida.

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

Quando os hackers atacam através de código client-side (o JavaScript e o HTML executados no seu navegador), recolher provas forenses depois pode ser particularmente complicado:

1. Dados efémeros: as sessões de navegador têm vida curta, e os registos de exatamente que ficheiros 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 do front end muitas vezes não são armazenados de forma persistente.
2. Implementação e atualizações rápidas: as aplicações web modernas atualizam ou reimplementam código com frequência. Quando um atacante injeta scripts maliciosos, pode revertê-los com a mesma rapidez, deixando apenas uma janela de tempo muito curta para capturar provas.
3. Logs de servidor limitados: mesmo que o lado do servidor esteja seguro, a ação real está a acontecer no navegador do utilizador. Os logs padrão do servidor podem mostrar que um ficheiro foi servido, mas não necessariamente que alterações foram feitas a esse ficheiro nem como se comportou depois de ser executado.
4. Falta de transparência no controlo de versões: algumas equipas não mantêm um registo público de cada build de front end. Se a alteração maliciosa foi introduzida através de um pipeline de build comprometido, as equipas forenses precisam de históricos de versões detalhados, e estes podem estar mal registados ou ser facilmente manipulados.
5. Dependência de terceiros: o código client-side frequentemente recorre a bibliotecas externas ou CDNs. Se o script malicioso foi injetado através de um serviço de terceiros, as equipas forenses têm de coordenar-se com fornecedores externos que podem não manter logs detalhados ou podem ser lentos a cooperar.

Para os investigadores forenses, tudo isto significa que reconstruir um ataque client-side pode implicar juntar fragmentos de caches de navegador, logs da consola do programador, históricos de implementação e quaisquer dados de versionamento disponíveis no pipeline de build. É possível fazê-lo, mas é significativamente mais desafiante do que investigar um comprometimento tradicional do lado do servidor, onde normalmente existem logs mais claros e acesso direto ao sistema comprometido.

Como o cside poderia ter ajudado

O cside analisa scripts client-side de primeira parte e obtém e analisa o JavaScript de terceiros do nosso lado antes de este ser executado no seu site. Guardamos ainda os scripts durante até um ano, oferecendo forense completa onde hoje existe um ponto cego. Se a Bybit tivesse usado o cside, qualquer modificação inesperada ou maliciosa na interface da carteira Safe poderia ter sido detetada e bloqueada, potencialmente evitando todo este ataque.

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