Análisis del hackeo a Balancer: ¿Cómo ocurrió el robo de 120 millones de dólares?

Título original del artículo: "Análisis técnico de la vulnerabilidad del hackeo de $120M a Balancer"
Fuente original: ExVul Security

Prólogo

El 3 de noviembre de 2025, el protocolo Balancer fue atacado en múltiples cadenas, incluyendo Arbitrum y Ethereum, lo que resultó en una pérdida de activos de 120 millones de dólares. El ataque se debió principalmente a una doble vulnerabilidad que involucraba la pérdida de precisión y la manipulación del invariante.

La infraestructura de Chainlink ha mantenido durante mucho tiempo los estándares más altos en el espacio Web3, lo que la convierte en una opción natural para X Layer, que se dedica a proporcionar herramientas de grado institucional para desarrolladores.

El problema clave en este ataque radica en la lógica del protocolo para manejar transacciones pequeñas. Cuando los usuarios realizan intercambios con cantidades pequeñas, el protocolo invoca la función _upscaleArray, que utiliza mulDown para redondear hacia abajo los valores. Cuando el saldo en la transacción y la cantidad de entrada alcanzan un límite de redondeo específico (por ejemplo, el rango de 8-9 wei), ocurre un error de precisión relativa notable.

Este error de precisión se propaga al cálculo del valor invariante D del protocolo, causando una reducción anormal en el valor D. La fluctuación del valor D reduce directamente el precio del Balancer Pool Token (BPT) en el protocolo Balancer. El hacker explotó este precio de BPT suprimido a través de una ruta de trading premeditada para realizar arbitraje, lo que finalmente llevó a una pérdida masiva de activos.

Transacción explotada:

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

Transacción de transferencia de activos:

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

Análisis técnico

Vector de ataque

El punto de entrada del ataque fue el contrato Balancer: Vault, siendo la función de entrada correspondiente la función batchSwap, que internamente llama a onSwap para intercambios de tokens.

Desde la perspectiva de los parámetros de la función y las restricciones, se puede obtener información:

1. El atacante necesita llamar a esta función a través del Vault y no puede llamarla directamente.

2. La función llamará internamente a _scalingFactors() para obtener el factor de escala para las operaciones de escalado.

3. La operación de escalado se concentra ya sea en _swapGivenIn o _swapGivenOut.

Análisis del patrón de ataque

Mecanismo de cálculo del precio BPT

En el modelo de pool estable de Balancer, el precio BPT es un punto de referencia crucial que determina cuánto BPT recibe un usuario y cuánto recibe cada BPT en activos.

En el cálculo de intercambio del pool:

Donde la parte que actúa como ancla del precio BPT es un valor D inmutable, lo que significa que controlar el precio BPT requiere controlar D. Analicemos el proceso de cálculo de D más a fondo:

En el código anterior, el proceso de cálculo de D depende del array de saldos escalados. Esto significa que se necesita una operación para cambiar la precisión de estos saldos, lo que lleva a un cálculo incorrecto de D.

Causa raíz de la pérdida de precisión

Operación de escalado:

Como se muestra arriba, al pasar por _upscaleArray, si el saldo es muy pequeño (por ejemplo, 8-9 wei), el redondeo hacia abajo en mulDown resultará en una pérdida significativa de precisión.

Proceso de ataque detallado

Fase 1: Ajuste al límite de redondeo

Fase 2: Disparar la pérdida de precisión (vulnerabilidad central)

Fase 3: Explotar el precio BPT deprimido para obtener ganancias

Arriba, el atacante utiliza Batch Swap para realizar múltiples intercambios en una sola transacción:

1. Primer intercambio: BPT → cbETH (ajuste de saldo)

2. Segundo intercambio: wstETH (8) → cbETH (disparar pérdida de precisión)

3. Tercer intercambio: Activo subyacente → BPT (toma de ganancias)

Todos estos intercambios ocurren en la misma transacción de batch swap, compartiendo el mismo estado de saldo, pero cada intercambio llama a _upscaleArray para modificar el array de saldos.

Falta de mecanismo de callback

El proceso principal es iniciado por el Vault. ¿Cómo conduce esto a la acumulación de pérdida de precisión? La respuesta radica en el mecanismo de paso del array de saldos.

Mirando el código anterior, aunque Vault crea un nuevo array currentBalances cada vez que se llama a onSwap, en Batch Swap:

1. Después del primer swap, el saldo se actualiza (pero debido a la pérdida de precisión, el valor actualizado puede ser inexacto)

2. El segundo swap continúa el cálculo basado en el resultado del primer swap

3. La pérdida de precisión se acumula, eventualmente causando que el valor invariante D disminuya significativamente

Problema clave:

Resumen

El ataque a Balancer se puede resumir por las siguientes razones:

1. La función de escalado usa redondeo hacia abajo: _upscaleArray usa mulDown para escalar, lo que resulta en una pérdida de precisión relativa significativa cuando el saldo es muy pequeño (por ejemplo, 8-9 wei).

2. El cálculo del valor invariante es sensible a la precisión: El cálculo del valor invariante D depende del array de saldos escalados, y la pérdida de precisión afecta directamente el cálculo de D, causando que D disminuya.

3. Falta de validación del cambio del valor invariante: Durante el proceso de swap, no hubo validación para asegurar que el cambio en el valor invariante D estuviera dentro de un rango razonable, permitiendo a los atacantes explotar repetidamente la pérdida de precisión para suprimir el precio BPT.

4. Acumulación de pérdida de precisión en batch swaps: Dentro del mismo batch swap, la pérdida de precisión de múltiples swaps se acumula y eventualmente conduce a pérdidas financieras significativas.

Estos dos problemas —pérdida de precisión y falta de validación— combinados con el diseño cuidadoso de las condiciones de contorno por parte del atacante, resultaron en esta pérdida.

Este artículo es una contribución y no representa las opiniones de BlockBeats.