Primer lanzamiento｜Éter de guante vacío: análisis de ataque del equilibrador

A las 2:03 a. m., hora de Beijing, del 29 de junio, el sistema CertiK Skynet (Skynet) detectó una anomalía en el contrato Balancer DeFi en el bloque 10355807. Los investigadores de seguridad intervinieron rápidamente en la investigación y el proceso de ataque salió a la luz.

A las 2:03 a. m. del 29 de junio, el atacante usó WETH prestado del préstamo flash dYdX para comprar una gran cantidad de tokens STA, lo que provocó que el precio de intercambio de STA y otros tokens aumentara considerablemente. Luego use la cantidad mínima de STA (el valor es 1e-18) para recomprar continuamente WETH, y después de cada recompra, use la laguna del contrato de Balancer para restablecer la cantidad de STA internas (el valor es 1e-18), para estabilizar STA precio alto.

Los atacantes continúan explotando las lagunas y usan STA de alto precio para comprar por completo un determinado token (WETH, WBTC, LINK y SNX), y finalmente usan WETH para pagar el préstamo flash, dejando una gran cantidad de STA, WETH, WBTC , LINK y SNX, y transfiera las ganancias ilegales a su propia cuenta a través de uniswap. El ataque generó una ganancia de alrededor de 900.000 RMB.

El retrato psicológico del atacante analizado por CertiK:

Después de llamar al saldo de STA, el atacante llamó rápidamente a la función swapExactAmountIn para comprar STA y usó otra función swapExactAmountOut en la transacción número 24 para comprar con precisión la cantidad mínima de STA (1e-18), maximizando así el potencial para ataques posteriores. En las primeras 6 transacciones, compré 3 veces y luego las vendí sin necesidad, y perdí 4 WETH, así que lo dudo. Y al poder ocultar los rastros de la etapa de préstamo flash, tiene las características de un hacker.

CertiK consideró que el atacante fue un intento de ataque de un equipo de piratas informáticos experimentado después de una preparación completa, y es muy probable que continúen atacando otros contratos de DeFi.

Fase 0: el atacante toma prestado del préstamo flash dYdX para obtener los fondos WETH iniciales.

Fase 1: el atacante usa WETH para comprar STA en Balancer lo más rápido posible y maximizar el precio de STA.

Los legisladores de EE. UU. proponen incluir las criptomonedas en las reglas de "venta de lavado": el 17 de septiembre, el Comité de Medios y Arbitrios del Comité Principal de Impuestos de la Cámara de Representantes de EE. UU. propuso el lunes incluir las criptomonedas en las reglas de "venta de lavado". Si se aprueba, las reglas se aplicarían a las transacciones de criptomonedas que ocurran después del 31 de diciembre. La disposición de "venta de lavado" en la nueva propuesta establece: Esta parte de la disposición cubre productos básicos, monedas y activos digitales bajo la regla de venta de lavado, una regla contra el abuso que se aplicaba anteriormente a acciones y otros valores. Las reglas de venta de lavado en la Sección 1091 evitan que los contribuyentes reclamen pérdidas fiscales mientras retienen un interés en los activos perdidos. Dado que el IRS considera que las criptomonedas son propiedad, actualmente están exentas de las reglas de venta ficticia, y la propuesta busca cerrar la laguna fiscal de las criptomonedas. (Noticias de Bitcoin) [2021/9/17 23:31:12]

Fase 2: el atacante utiliza la STA obtenida para recomprar WETH varias veces. Cada vez, se usa la cantidad mínima de STA (el valor es 1e-18) para comprar, y la función de vulnerabilidad interna gulp() de Balancer se usa para bloquear el número de STA y controlar el precio de STA a WETH. Repetir esta operación de recompra varias veces hasta vaciar WETH en el Balancer.

Fase 3: Cambia a otro token, repite la fase 2 con STA hasta que el token esté vacío. La fase 3 se repitió tres veces y un total de 4 tokens sufrieron pérdidas WETH, WBTC, LINK y SNX.

Fase 4: Pagar el Préstamo Flash dYdX y salir.

Fase 1:   Tomar todas las STA de Balancer

En las primeras 24 transacciones, el WETH prestado del préstamo flash se negoció como STA, lo que redujo la cantidad de STA en Balancer tanto como fue posible, lo que aumentó el precio de STA para otros tokens.  

Fase 2: cambie STA a WETH y use la vulnerabilidad de la función gulp para controlar el precio

Al comienzo de la fase 2, la función gulp siempre restablece el número total de STA al 1e-18 anterior. Cuando la STA se intercambia por WETH a través de la función swapExactAmountIn por primera vez, el atacante establece deliberadamente la cantidad de transacciones de STA entre 1e y 18. Dado que la cantidad de STA es extremadamente pequeña en el modelo de transacción, el precio de STA será extremadamente bajo en comparación con otros tokens alto. Después de completar la primera transacción, la cantidad de STA en Balancer debe ser 2e-18.

Antes de intercambiar STA por WETH a través de swapExactAmountIn por segunda vez, el atacante llama a la función gulp para sobrescribir el número de STA actual (2e-18) con el 1e-18 registrado internamente para el número de STA en Balancer. Por lo tanto, al comprar WETH, STA aún puede mantener un precio alto. Sin embargo, después de comprar WETH, la cantidad de WETH disminuye y los ingresos ilegales de cada ataque disminuyen gradualmente. Después de 18 ataques, WETH en Balancer se roba por completo.

Fase 3: Metas cambiantes

Cuando el WETH en Balancer fue robado por completo, el atacante usó la misma vulnerabilidad para repetir el ataque en otros tokens de Balacner (WBTC, LINK y SNX), robó los 4 tokens y se escondió.

El atacante obtiene beneficios

Dirección del ataque del ataque:

0x81D73c55458f024CDC82BbF27468A2dEAA631407

Dirección de recepción final del ataque:

0xbf675c80540111a310b06e1482f9127ef4e7469a

Beneficio final del atacante: 565,5326240837032 ETH, alrededor de 900 000 RMB (precio a las 9:30 a. m. hora de Beijing 20200630)

La función gulp() del contrato Balancer se usa para sobrescribir el valor de registro interno de un determinado token en el número real actual del token, pero está configurado incorrectamente en una función externa sin límite. La función gulp() no debe ser externa, ni debe agregar restricciones de verificación o protección para usuarios específicos o propietarios de contratos inteligentes.

Referencias:

1. Equilibrador Github:

https://github.com/balancer-labs/balancer-core/blob/140df49361a58e6c79b395964be98387702a7c0d/contracts/BPool.sol#L334

https://github.com/balancer-labs/balancer-core/blob/140df49361a58e6c79b395964be98387702a7c0d/contracts/BMath.sol#L28

https://github.com/balancer-labs/balancer-core/blob/140df49361a58e6c79b395964be98387702a7c0d/contracts/BPool.sol#L423

2. Historial de transacciones de ataque:

https://ethtx.info/mainnet/0x013be97768b702fe8eccef1a40544d5ecb3c1961ad5f87fee4d16fdc08c78106

3. Informe oficial del ataque:

https://medium.com/balancer-protocol/incident-with-non-standard-erc20-deflationary-tokens-95a0f6d46dea

Más información

Información general: info@certik.org

Auditoría & Asociaciones: bd@certik.org

Sitio web: certik.org

Twitter: @certik.org

Telegrama: t.me/certik.org

Medio: medium.com/certik

Bihu: bihu.com/people/1093109

Tags：

ICP