Análise técnica: Como o Balancer foi hackeado em 120 milhões de dólares?

Título original do artigo: "Análise técnica da vulnerabilidade do hack de 120M$ do Balancer"
Fonte original: ExVul Security

Prefácio

Em 3 de novembro de 2025, o protocolo Balancer foi atacado em várias redes, incluindo Arbitrum e Ethereum, resultando em uma perda de ativos de 120 milhões de dólares. O ataque deveu-se principalmente a uma vulnerabilidade dupla envolvendo perda de precisão e manipulação de invariante.

A infraestrutura da Chainlink mantém há muito tempo os mais altos padrões no espaço Web3, tornando-a uma escolha natural para a X Layer, que se dedica a fornecer ferramentas de nível institucional para desenvolvedores.

O problema chave neste ataque reside na lógica do protocolo para lidar com pequenas transações. Quando os usuários realizam trocas com pequenos valores, o protocolo invoca a função _upscaleArray, que usa mulDown para arredondar valores para baixo. Quando o saldo na transação e o valor de entrada atingem um limite de arredondamento específico (por exemplo, a faixa de 8-9 wei), ocorre um erro de precisão relativa notável.

Este erro de precisão é propagado para o cálculo do valor invariante D do protocolo, causando uma redução anormal no valor D. A flutuação do valor D reduz diretamente o preço do Balancer Pool Token (BPT) no protocolo Balancer. O hacker explorou este preço BPT suprimido através de um caminho de trading premeditado para conduzir arbitragem, levando finalmente a uma perda massiva de ativos.

Transação explorada:

https://etherscan.io/tx/0x6ed07db1a9fe5c0794d44cd36081d6a6df103fab868cdd75d581e3bd23bc9742

Transação de transferência de ativos:

https://etherscan.io/tx/0xd155207261712c35fa3d472ed1e51bfcd816e616dd4f517fa5959836f5b48569

Análise técnica

Vetor de ataque

O ponto de entrada do ataque foi o contrato Balancer: Vault, com a função de entrada correspondente sendo a função batchSwap, que internamente chama onSwap para trocas de token.

Do ponto de vista dos parâmetros e restrições da função, várias informações podem ser obtidas:

1. O atacante precisa chamar esta função através do Vault e não pode chamá-la diretamente.

2. A função chamará internamente _scalingFactors() para obter o fator de escala para operações de escala.

3. A operação de escala está concentrada em _swapGivenIn ou _swapGivenOut.

Análise do padrão de ataque

Mecanismo de cálculo de preço BPT

No modelo de pool estável do Balancer, o preço BPT é um ponto de referência crucial que determina quanto BPT um usuário recebe e quanto cada BPT recebe em ativos.

No cálculo de troca do pool:

Onde a parte que atua como âncora de preço BPT é um valor imutável D, o que significa que controlar o preço BPT requer controlar D. Vamos analisar o processo de cálculo de D mais a fundo:

No código acima, o processo de cálculo de D depende do array de saldos escalados. Isso significa que uma operação é necessária para alterar a precisão desses saldos, levando a um cálculo incorreto de D.

Causa raiz da perda de precisão

Operação de escala:

Como mostrado acima, ao passar pelo _upscaleArray, se o saldo for muito pequeno (por exemplo, 8-9 wei), o arredondamento para baixo no mulDown resultará em uma perda de precisão significativa.

Processo de ataque detalhado

Fase 1: Ajuste ao limite de arredondamento

Fase 2: Gatilho de perda de precisão (vulnerabilidade principal)

Fase 3: Explorando o preço BPT deprimido para lucro

Acima, o atacante usa Batch Swap para realizar várias trocas em uma transação:

1. Primeira troca: BPT → cbETH (ajuste de saldo)

2. Segunda troca: wstETH (8) → cbETH (gatilho de perda de precisão)

3. Terceira troca: Ativo subjacente → BPT (realização de lucro)

Todas essas trocas ocorrem na mesma transação de batch swap, compartilhando o mesmo estado de saldo, mas cada troca chama _upscaleArray para modificar o array de saldos.

Falta de mecanismo de callback

O processo principal é iniciado pelo Vault. Como isso leva ao acúmulo de perda de precisão? A resposta reside no mecanismo de passagem do array de saldos.

Olhando para o código acima, embora o Vault crie um novo array currentBalances cada vez que onSwap é chamado, no Batch Swap:

1. Após a primeira troca, o saldo é atualizado (mas devido à perda de precisão, o valor atualizado pode ser impreciso)

2. A segunda troca continua o cálculo com base no resultado da primeira troca

3. A perda de precisão se acumula, eventualmente causando uma diminuição significativa no valor invariante D

Problema chave:

Resumo

O ataque ao Balancer pode ser resumido pelos seguintes motivos:

1. A função de escala usa arredondamento para baixo: _upscaleArray usa mulDown para escala, o que resulta em perda de precisão relativa significativa quando o saldo é muito pequeno (por exemplo, 8-9 wei).

2. O cálculo do valor invariante é sensível à precisão: O cálculo do valor invariante D depende do array de saldos escalados, e a perda de precisão afeta diretamente o cálculo de D, fazendo com que D diminua.

3. Falta de validação da mudança do valor invariante: Durante o processo de troca, não houve validação para garantir que a mudança no valor invariante D estivesse dentro de uma faixa razoável, permitindo que os atacantes explorassem repetidamente a perda de precisão para suprimir o preço BPT.

4. Acúmulo de perda de precisão em Batch Swaps: Dentro do mesmo batch swap, a perda de precisão de várias trocas se acumula e eventualmente leva a perdas financeiras significativas.

Esses dois problemas — perda de precisão e falta de validação — combinados com o design cuidadoso das condições de contorno pelo atacante, resultaram nesta perda.

Este artigo é uma contribuição e não representa as opiniões da BlockBeats.