Analyse technique : Comment Balancer a été piraté pour 120 millions de dollars ?

Titre original de l'article : "Analyse technique de la faille du hack de 120M$ de Balancer"
Source originale : ExVul Security

Avant-propos

Le 3 novembre 2025, le protocole Balancer a été attaqué sur plusieurs chaînes, dont Arbitrum et Ethereum, entraînant une perte d'actifs de 120 millions de dollars. L'attaque était principalement due à une double vulnérabilité impliquant une perte de précision et une manipulation d'invariant.

L'infrastructure de Chainlink maintient depuis longtemps les normes les plus élevées dans l'espace Web3, ce qui en fait un choix naturel pour X Layer, qui se consacre à fournir des outils de qualité institutionnelle aux développeurs.

Le problème clé de cette attaque réside dans la logique du protocole pour gérer les petites transactions. Lorsque les utilisateurs effectuent des échanges avec de petits montants, le protocole appelle la fonction _upscaleArray, qui utilise mulDown pour arrondir les valeurs à l'inférieur. Lorsque le solde de la transaction et le montant d'entrée atteignent tous deux une limite d'arrondi spécifique (par exemple, la plage de 8-9 wei), une erreur de précision relative notable se produit.

Cette erreur de précision est propagée au calcul de la valeur d'invariant D du protocole, provoquant une réduction anormale de la valeur D. La fluctuation de la valeur D abaisse directement le prix du Balancer Pool Token (BPT) dans le protocole Balancer. Le pirate a exploité ce prix BPT supprimé via un chemin de trading prémédité pour effectuer de l'arbitrage, conduisant finalement à une perte massive d'actifs.

Transaction exploitée :

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

Transaction de transfert d'actifs :

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

Analyse technique

Vecteur d'attaque

Le point d'entrée de l'attaque était le contrat Balancer: Vault, la fonction d'entrée correspondante étant la fonction batchSwap, qui appelle en interne onSwap pour les échanges de tokens.

Du point de vue des paramètres et des restrictions de la fonction, plusieurs informations peuvent être obtenues :

1. L'attaquant doit appeler cette fonction via le Vault et ne peut pas l'appeler directement.

2. La fonction appellera en interne _scalingFactors() pour obtenir le facteur d'échelle pour les opérations de mise à l'échelle.

3. L'opération de mise à l'échelle est concentrée soit dans _swapGivenIn, soit dans _swapGivenOut.

Analyse du modèle d'attaque

Mécanisme de calcul du prix BPT

Dans le modèle de pool stable de Balancer, le prix BPT est un point de référence crucial qui détermine combien de BPT un utilisateur reçoit et combien chaque BPT reçoit en actifs.

Dans le calcul d'échange du pool :

Où la partie agissant comme ancre de prix BPT est une valeur immuable D, ce qui signifie que contrôler le prix BPT nécessite de contrôler D. Analysons plus en détail le processus de calcul de D :

Dans le code ci-dessus, le processus de calcul de D dépend du tableau des soldes mis à l'échelle. Cela signifie qu'une opération est nécessaire pour modifier la précision de ces soldes, conduisant à un calcul incorrect de D.

Cause profonde de la perte de précision

Opération de mise à l'échelle :

Comme indiqué ci-dessus, lors du passage par _upscaleArray, si le solde est très faible (par exemple, 8-9 wei), l'arrondi à l'inférieur dans mulDown entraînera une perte de précision significative.

Détail du processus d'attaque

Phase 1 : Ajustement à la limite d'arrondi

Phase 2 : Déclencher la perte de précision (vulnérabilité principale)

Phase 3 : Exploiter le prix BPT déprimé pour le profit

Ci-dessus, l'attaquant utilise Batch Swap pour effectuer plusieurs échanges en une seule transaction :

1. Premier échange : BPT → cbETH (ajustement du solde)

2. Deuxième échange : wstETH (8) → cbETH (déclencher la perte de précision)

3. Troisième échange : Actif sous-jacent → BPT (prise de profit)

Tous ces échanges se produisent dans la même transaction de batch swap, partageant le même état de solde, mais chaque échange appelle _upscaleArray pour modifier le tableau des soldes.

Manque de mécanisme de rappel

Le processus principal est initié par le Vault. Comment cela conduit-il à accumuler une perte de précision ? La réponse réside dans le mécanisme de passage du tableau des soldes.

En regardant le code ci-dessus, bien que Vault crée un nouveau tableau currentBalances chaque fois que onSwap est appelé, dans Batch Swap :

1. Après le premier swap, le solde est mis à jour (mais en raison de la perte de précision, la valeur mise à jour peut être inexacte)

2. Le deuxième swap poursuit le calcul sur la base du résultat du premier swap

3. La perte de précision s'accumule, provoquant finalement une diminution significative de la valeur d'invariant D

Problème clé :

Résumé

L'attaque de Balancer peut être résumée pour les raisons suivantes :

1. La fonction de mise à l'échelle utilise l'arrondi à l'inférieur : _upscaleArray utilise mulDown pour la mise à l'échelle, ce qui entraîne une perte de précision relative significative lorsque le solde est très faible (par exemple, 8-9 wei).

2. Le calcul de la valeur d'invariant est sensible à la précision : Le calcul de la valeur d'invariant D repose sur le tableau des soldes mis à l'échelle, et la perte de précision affecte directement le calcul de D, provoquant une diminution de D.

3. Manque de validation du changement de valeur d'invariant : Pendant le processus de swap, il n'y avait aucune validation pour garantir que le changement de la valeur d'invariant D se situait dans une plage raisonnable, permettant aux attaquants d'exploiter à plusieurs reprises la perte de précision pour supprimer le prix BPT.

4. Accumulation de la perte de précision dans les Batch Swaps : Au sein du même batch swap, la perte de précision due à plusieurs swaps s'accumule et conduit finalement à des pertes financières importantes.

Ces deux problèmes — perte de précision et manque de validation — combinés à la conception minutieuse des conditions aux limites par l'attaquant, ont entraîné cette perte.

Cet article est une contribution et ne représente pas les points de vue de BlockBeats.