Análise Técnica: Hack do Balancer de US$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

Introdução

Em 3 de novembro de 2025, o protocolo Balancer foi atacado em múltiplas redes, incluindo Arbitrum e Ethereum, resultando em uma 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 é dedicado a fornecer ferramentas de nível institucional para desenvolvedores.

A questão principal neste ataque reside na lógica do protocolo para lidar com transações pequenas. Quando os usuários 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 um limite específico de arredondamento (por exemplo, na faixa de 8-9 wei), ocorre um erro de precisão relativo perceptível.

Esse erro de precisão é propagado 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 esse preço suprimido do BPT através de um caminho de negociação premeditado para realizar arbitragem, levando, por fim, 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, 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 as 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 do Balancer, o Preço do 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 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 escalonados. Isso significa que é necessária uma operação 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 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á em uma perda significativa de precisão.

Detalhamento do Processo de Ataque

Fase 1: Ajuste para o Limite de Arredondamento

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

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

Acima, o atacante usa o Batch Swap para realizar múltiplas trocas em uma única transação:

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

2. Segunda Troca: wstETH (8) → cbETH (disparo da 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 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 estar incorreto)

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 do invariant D

Questão Chave:

Resumo

O ataque ao Balancer pode ser resumido pelos seguintes motivos:

1. Função de Escalonamento Usa Arredondamento para Baixo: _upscaleArray utiliza mulDown para escalonamento, o que resulta em uma perda relativa significativa de precisão 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 escalonados, 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 estivesse dentro de uma faixa 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 se acumula e eventualmente leva a perdas financeiras significativas.

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