#2: Incidente de Euler Finance: El Mayor Hackeo de 2023

El 13 de marzo de 2023, nuestro sistema detectó que el pool de préstamos de Euler Finance había sufrido un ataque de préstamo flash, lo que resultó en pérdidas de 197 millones de dólares. Primero alertamos a la comunidad y luego proporcionamos un análisis para ayudar a identificar la causa raíz.

1/ @eulerfinance is attacked. The root cause is due to the lack of liquidity check in the function donateToReserves()https://t.co/stWtPWK900

See the detailed attack steps below. https://t.co/bm10OJHiXu pic.twitter.com/TDbYuzVWHe
— BlockSec (@BlockSecTeam) March 13, 2023

La causa raíz de este incidente se debe a la falta de verificación de insolvencia en la función donateToReserves(). Específicamente, el contrato vulnerable proporciona una funcionalidad para que los usuarios donen su colateral al protocolo sin verificar si la posición del usuario era solvente. Peor aún, para deshacerse de esta posición negativa, el protocolo ofreció un gran descuento para que los liquidadores pagaran menos deuda al liquidar esta posición. El atacante creó una posición grande y la volvió insolvente explotando esta funcionalidad. Luego, pudo comprar su colateral con descuento para obtener ganancias.

Antecedentes

Descripción general de Euler Finance

Euler Finance es un protocolo de préstamos en Ethereum que permite a los usuarios prestar y tomar prestados tokens específicos. Cuando los prestamistas depositan en el pool de liquidez de Euler, se acuña una cantidad correspondiente de ETokens (tokens ERC20 que generan intereses) y se les envía. Estos ETokens pueden canjearse por los activos subyacentes depositados.

Por otro lado, los prestatarios que toman liquidez reciben DTokens. Estos DTokens son compatibles con ERC20 e impiden que los titulares los quemen de forma independiente. Específicamente, en lugar de permitir que los tokens se envíen a cualquiera, pueden ser tomados por cualquiera, pero aceptarlos requiere aprobación. En cuanto al activo subyacente, los prestatarios son responsables de pagar intereses sobre sus préstamos, y una parte de estos intereses se utiliza para cubrir las deudas incobrables del protocolo.

Los mecanismos de apalancamiento de préstamos (también conocido como autopréstamo) y de liquidación suave de Euler Finance son dos conceptos clave que nos ayudan a comprender mejor la causa de este ataque.

Préstamo Apalancado

Euler Finance proporciona una función de préstamo apalancado, que permite a los usuarios simular una estrategia de préstamo recursivo. En pocas palabras, los usuarios pueden depositar colateral y acuñar ETokens, que luego pueden usarse como colateral para pedir prestados más ETokens. El contrato también acuñará una cantidad correspondiente de dTokens como tokens de deuda. La salud de la posición del usuario se calcula en función de los valores de los ETokens y dTokens. Según la documentación de Euler Finance, los usuarios pueden apalancarse hasta 19x. La función de préstamo apalancado jugó un papel crucial en este incidente. Sin la asistencia de esta función, el atacante no habría podido obtener ganancias. A través del préstamo apalancado, el atacante amplificó el tamaño de su posición a casi 11 veces los fondos iniciales obtenidos del préstamo flash.

Liquidación Suave

Como se describe en el libro blanco de Euler Finance, el mecanismo de liquidación suave permite a los liquidadores ayudar a la parte liquidada a repagar su deuda de manera flexible, en lugar de estar restringidos a un coeficiente fijo para la liquidación como el adoptado por protocolos como Compound y Aave. La liquidación suave significa que cuanto menor sea la salud de una posición, más colateral es elegible para liquidación—hasta el 75% en caso de deuda incobrable, según los datos de este incidente. La liquidación del colateral con un descuento sustancial permitió, por tanto, al atacante liquidar el préstamo flash y asegurar una ganancia.

Análisis de Vulnerabilidad

La vulnerabilidad principal, es decir, la falta de una verificación de insolvencia, existe dentro de la función donateToReserves(), que es utilizada por los usuarios para transferir ETokens de sus posiciones a la reserva del protocolo como donaciones. Para los usuarios habituales, normalmente no hay ningún incentivo o motivación para realizar tal acción. De hecho, la vulnerabilidad radica en que la función donateToReserves() no realiza una verificación de salud al transferir ETokens fuera de las posiciones de los usuarios. Esto permite a los atacantes donar directamente los ETokens de la posición grande creada mediante préstamo apalancado, lo que hace que la salud de la posición caiga por debajo del 100% y resulte en deuda incobrable.

Según el diseño, Euler Finance utiliza un factor de cierre dinámico para "liquidar suavemente" las posiciones. En resumen, cuanto menos saludable sea una posición, mayor será la proporción del colateral en esa posición que puede liquidarse. En el caso de deuda incobrable, el porcentaje de liquidación puede llegar hasta el 75% del colateral dentro de la posición (según el cálculo basado en la transacción de ataque real). Como resultado, la cantidad significativa de colateral con descuento que se liquida permite al atacante reembolsar el préstamo flash y obtener ganancias.

Análisis del Ataque

Hay múltiples transacciones de ataque dirigidas a diferentes pools:

0xc310a0affe2169d1f6feec1c63dbc7f7c62a887fa48795d327d4d2da2d6b111d (DAI)
0x71a908be0bef6174bccc3d493becdfd28395d8898e355d451cb52f7bac38617 (WBTC)
0x62bd3d31a7b75c098ccf28bc4d4af8c4a191b4b9e451fab4232258079e8b18c4 (wstETH)
0x465a6780145f1efe3ab52f94c006065575712d2003d83d85481f3d110ed13d9 (USDC)
0x3097830e9921e4063d334acb82f6a79374f76f0b1a8f857e89b89bc58df1f311 (stETH)
0x47ac3527d02e6b9631c77fad1cdee7bfa77a8a7bfd4880dccbda5146ace4088f (WETH)

Los pasos del ataque son los siguientes (tomando la primera transacción de ataque como ejemplo):

El atacante tomó prestados 30 millones de DAI en AAVE mediante un préstamo flash.
El atacante depositó 20 millones de DAI y recibió 20 millones de eDAI.
Dado que Euler Finance proporciona la capacidad de préstamo apalancado, el atacante pudo acuñar 195 millones de eDAI y 200 millones de dDAI. Ahora el atacante tiene 215 millones de eDAI y 200 millones de dDAI.
Continuando con lo anterior. Se reembolsaron 10 millones de deuda para que el atacante pudiera acuñar más eDAI. Ahora el atacante tiene 215 millones de eDAI y 190 millones de dDAI.
Se repitió el paso 3. Ahora el atacante tiene 410 millones de eDAI y 390 millones de dDAI.
El atacante invocó la función donateToReserve para donar 100 millones de eDAI. Sin embargo, durante este proceso, no se verificó el factor de salud del atacante. En este caso, la posición ahora puede liquidarse (310 millones de eDAI frente a 390 millones de dDAI), lo que deja la oportunidad de obtener ganancias.
El atacante liquidó la posición usando otro contrato de dirección como liquidador (0xa0b3...). El liquidador (0xa0b3...) recibió 310 millones de eDAI y 259 millones de dDAI.
El atacante quemó 38,9 millones de eDAI para retirar 38,9 millones de DAI (no se pueden retirar más debido a las verificaciones de insolvencia) en la posición del liquidador (0xa0b3...).
El atacante reembolsó el préstamo flash.

Los pasos clave del ataque 2-7 están etiquetados en el rastro de la transacción.

Resumen

Este fue el mayor hackeo en 2023, con un récord de 197 millones de dólares robados por un argentino de 20 años llamado Federico Jaime, quien proporcionó a los medios "una narrativa sinuosa, a veces confusa e incluso contradictoria". No obstante, "todos los fondos recuperables" fueron posteriormente restaurados a la dirección del tesoro de Euler Finance. Sin embargo, una pequeña parte (alrededor de 200.000 dólares) fue enviada "sin querer" al Grupo Lazarus—un presunto sindicato criminal norcoreano patrocinado por el Estado y sancionado por el Departamento del Tesoro de EE. UU. Puede consultar estos enlaces, es decir, enlace1 y enlace2, para conocer la historia detallada e interesante.

La causa raíz de este incidente fue la falta de verificaciones de insolvencia, lo que sirve como lección. De hecho, para un protocolo de préstamos, es crucial evaluar si se deben implementar verificaciones de salud de posición para cualquier procedimiento que pueda afectar las posiciones de los usuarios. Además, los equipos de proyecto deben monitorear proactivamente su protocolo de préstamos en busca de liquidaciones significativas y establecer sistemas de alerta efectivos para detectar y responder oportunamente a dichos eventos.