Analisi tecnica: Balancer ha subito un furto di 120 milioni di dollari, dove si trova la vulnerabilità?

Titolo originale: "Analisi tecnica della vulnerabilità da $120M rubati su Balancer"
Fonte originale: ExVul Security

Prefazione

Il 3 novembre 2025, il protocollo Balancer è stato vittima di un attacco hacker su più blockchain tra cui Arbitrum ed Ethereum, causando una perdita di asset pari a 120 milioni di dollari. Il nucleo dell’attacco deriva da una doppia vulnerabilità: perdita di precisione e manipolazione dell’invariante.

L’infrastruttura di Chainlink mantiene da tempo i più alti standard nel settore Web3, diventando così la scelta naturale per X Layer, impegnata a fornire strumenti di livello istituzionale agli sviluppatori.

Il problema chiave di questo attacco risiede nella logica con cui il protocollo gestisce le transazioni di piccolo importo. Quando un utente effettua uno scambio di basso valore, il protocollo richiama la funzione _upscaleArray, che utilizza mulDown per arrotondare i valori verso il basso. Se il saldo e l’importo in ingresso della transazione si trovano entrambi su un particolare limite di arrotondamento (ad esempio nell’intervallo 8-9 wei), si genera un errore relativo di precisione significativo.

L’errore di precisione si trasmette nel calcolo dell’invariante D del protocollo, portando a una riduzione anomala del valore di D. La variazione di D abbassa direttamente il prezzo del BPT (Balancer Pool Token) nel protocollo Balancer. L’hacker ha sfruttato questo prezzo BPT artificialmente basso, completando un percorso di trading predefinito per ottenere un arbitraggio e causando infine una perdita di asset su larga scala.

Transazione di exploit della vulnerabilità:

Transazione di trasferimento degli asset:

Analisi tecnica

Punto di ingresso dell’attacco

Il punto di ingresso dell’attacco è il contratto Balancer: Vault, con la funzione di ingresso batchSwap, che internamente richiama onSwap per effettuare lo scambio di token.

Dall’analisi dei parametri e delle restrizioni della funzione, emergono alcune informazioni:

1. L’attaccante deve richiamare questa funzione tramite Vault, non può richiamarla direttamente.

2. All’interno della funzione viene richiamato _scalingFactors() per ottenere il fattore di scala e applicare la scalatura.

3. Le operazioni di scalatura sono concentrate in _swapGivenIn o _swapGivenOut.

Analisi della modalità d’attacco

Meccanismo di calcolo del prezzo BPT

Nel modello di pool stabile di Balancer, il prezzo del BPT è un riferimento importante, determinando quanti BPT riceve l’utente e quanti asset corrispondono a ciascun BPT.

Nella logica di calcolo dello scambio nel pool:

La parte che funge da riferimento per il prezzo del BPT è l’invariante D, quindi per manipolare il prezzo del BPT bisogna manipolare D. Analizziamo il processo di calcolo di D:

Nel codice sopra, il calcolo di D dipende dall’array balances scalato. Ciò significa che è necessaria un’operazione che alteri la precisione di questi balances, portando a un errore nel calcolo di D.

Origine della perdita di precisione

Operazione di scalatura:

Come mostrato sopra, durante l’esecuzione di _upscaleArray, se il saldo è molto basso (ad esempio 8-9 wei), l’arrotondamento verso il basso di mulDown causa una perdita di precisione significativa.

Dettaglio del processo d’attacco

Fase 1: Regolazione sul limite di arrotondamento

Fase 2: Innesco della perdita di precisione (vulnerabilità principale)

Fase 3: Profitto sfruttando il prezzo BPT abbassato

Come mostrato sopra, l’attaccante esegue più scambi in una singola transazione tramite Batch Swap:

1. Primo scambio: BPT → cbETH (regolazione del saldo)

2. Secondo scambio: wstETH (8) → cbETH (innesco della perdita di precisione)

3. Terzo scambio: asset sottostante → BPT (profitto)

Tutti questi scambi avvengono nella stessa transazione batch swap, condividendo lo stesso stato dei saldi, ma ogni scambio richiama _upscaleArray per modificare l’array balances.

Mancanza del meccanismo di Callback

Il processo principale è avviato da Vault, ma come si accumula la perdita di precisione? La risposta sta nel meccanismo di trasmissione dell’array balances.

Analizzando il codice sopra, sebbene Vault crei un nuovo array currentBalances a ogni chiamata di onSwap, nel Batch Swap:

1. Dopo il primo scambio, il saldo viene aggiornato (ma a causa della perdita di precisione, il valore aggiornato potrebbe non essere accurato)

2. Il secondo scambio continua il calcolo basandosi sul risultato del primo

3. La perdita di precisione si accumula, portando infine a una riduzione significativa dell’invariante D

Problema chiave:

Conclusione

L’attacco a Balancer può essere riassunto nei seguenti punti:

1. La funzione di scalatura utilizza l’arrotondamento verso il basso: _upscaleArray utilizza mulDown per la scalatura; quando il saldo è molto basso (ad esempio 8-9 wei), si verifica una perdita di precisione relativa significativa.

2. Il calcolo dell’invariante è sensibile alla precisione: il calcolo dell’invariante D dipende dall’array balances scalato; la perdita di precisione si trasmette direttamente nel calcolo di D, riducendolo.

3. Mancanza di verifica delle variazioni dell’invariante: durante lo scambio non viene verificato se la variazione di D rientra in un intervallo ragionevole, permettendo all’attaccante di sfruttare ripetutamente la perdita di precisione per abbassare il prezzo del BPT.

4. Accumulo della perdita di precisione nel Batch Swap: in uno stesso batch swap, la perdita di precisione di più scambi si accumula, amplificandosi infine in una grande perdita finanziaria.

Questi due problemi — perdita di precisione e mancanza di verifica — uniti alla progettazione accurata delle condizioni limite da parte dell’attaccante, hanno causato questa perdita.