Análise Técnica: Hack do Balancer de $120 milhões, qual foi a vulnerabilidade?

Original Article Title: " Análise Técnica da Vulnerabilidade do Hack de $120M da Balancer"
Original Source: ExVul Security

Prefácio

Em 3 de novembro de 2025, o protocolo Balancer foi atacado em múltiplas redes, incluindo Arbitrum e Ethereum, resultando numa perda de ativos de $120 milhões. O ataque ocorreu principalmente devido a uma dupla vulnerabilidade envolvendo perda de precisão e manipulação do Invariant.

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

A questão chave neste ataque reside na lógica do protocolo para lidar com pequenas transações. Quando os utilizadores realizam trocas com quantias pequenas, o protocolo invoca a função _upscaleArray, que utiliza mulDown para arredondar valores para baixo. Quando o saldo na transação e o valor de entrada atingem ambos um limite específico de arredondamento (por exemplo, na faixa de 8-9 wei), ocorre um erro de precisão relativo significativo.

Este erro de precisão propaga-se para o cálculo do valor Invariant D do protocolo, causando uma redução anormal no valor de D. A flutuação do valor de D reduz diretamente o preço do Balancer Pool Token (BPT) no protocolo Balancer. O hacker explorou este preço suprimido do BPT através de um caminho de negociação premeditado para realizar arbitragem, levando, em última análise, a uma grande perda 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, sendo a função de entrada correspondente a batchSwap, que internamente chama onSwap para trocas de tokens.

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

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

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

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

Análise do Padrão de Ataque

Mecanismo de Cálculo do Preço do BPT

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

No cálculo de trocas do pool:

A parte que atua como âncora do Preço do BPT é um valor imutável D, o que significa que controlar o Preço do BPT requer controlar D. Vamos analisar mais detalhadamente o processo de cálculo de D:

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

Causa Raiz da Perda de Precisão

Operação de Escalonamento:

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

Processo de Ataque Detalhado

Fase 1: Ajuste para o Limite de Arredondamento

Fase 2: Acionamento da Perda de Precisão (Vulnerabilidade Central)

Fase 3: Exploração do Preço Depressivo do BPT para Lucro

Acima, o atacante utiliza o Batch Swap para realizar múltiplas trocas numa única transação:

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

2. Segunda Troca: wstETH (8) → cbETH (aciona a perda de precisão)

3. Terceira Troca: Ativo Subjacente → BPT (realização de lucro)

Todas estas trocas ocorrem na mesma transação de batch swap, partilhando 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 isto leva ao acúmulo de perda de precisão? A resposta está no mecanismo de passagem do array de saldos.

Analisando 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 acumula-se, eventualmente causando uma diminuição significativa no valor do invariant D

Questão Chave:

Resumo

O ataque à Balancer pode ser resumido pelas seguintes razões:

1. Função de Escalonamento Usa Arredondamento para Baixo: _upscaleArray utiliza mulDown para escalonamento, o que resulta numa perda de precisão relativa significativa quando o saldo é muito pequeno (por exemplo, 8-9 wei).

2. Cálculo do Valor Invariant é Sensível à Precisão: O cálculo do valor invariant 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 Invariant: Durante o processo de swap, não houve validação para garantir que a mudança no valor invariant D estava dentro de um intervalo razoável, permitindo que atacantes explorassem repetidamente a perda de precisão para suprimir o preço do BPT.

4. Acúmulo de Perda de Precisão em Batch Swaps: Dentro do mesmo batch swap, a perda de precisão de múltiplas trocas acumula-se e eventualmente leva a perdas financeiras significativas.

Estas duas questões — perda de precisão e falta de validação — combinadas com o design cuidadoso das condições de fronteira pelo atacante, resultaram nesta perda.