#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 relámpago (flash loan), 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. Para empeorar las cosas, con el fin de deshacerse de esta posición problemática, el protocolo ofreció un gran descuento para que los liquidadores pagaran menos deuda al liquidar dicha 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.

Contexto

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 sus titulares los quemen de forma independiente. Específicamente, en lugar de permitir que los tokens se envíen a cualquier persona, cualquiera puede tomarlos, 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 préstamo apalancado (también conocido como autopréstamo) y 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 tomar 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 los dTokens. Según la documentación de Euler Finance, los usuarios pueden apalancar 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 hasta casi 11x los fondos iniciales obtenidos del préstamo relámpago.

Liquidación Suave

Como se describe en el whitepaper de Euler Finance, el mecanismo de liquidación suave permite a los liquidadores ayudar a la parte liquidada a reembolsar su deuda de manera flexible, en lugar de estar restringidos a un coeficiente fijo para la liquidación como lo 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 la liquidación: hasta el 75% en caso de deuda incobrable, según los datos de este incidente. La liquidación de colateral con un descuento sustancial permitió al atacante liquidar el préstamo relámpago 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, generalmente no hay incentivo ni 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 ser tan alto como el 75% del colateral dentro de la posición (calculado en base a 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 relámpago 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 30M DAI en AAVE mediante préstamo relámpago.
El atacante depositó 20M DAI y recibió 20M eDAI.
Dado que Euler Finance proporciona la capacidad de préstamo apalancado, el atacante pudo acuñar 195M eDAI y 200M dDAI. Ahora el atacante tiene 215M eDAI y 200M dDAI.
Continuando lo anterior. Se reembolsaron 10M de deuda para que el atacante pudiera acuñar más eDAI. Ahora el atacante tiene 215M eDAI y 190M dDAI.
Se repitió el paso 3. Ahora el atacante tiene 410M eDAI y 390M dDAI.
El atacante invocó la función donateToReserve para donar 100M eDAI. Sin embargo, durante este proceso, no se verificó el factor de salud del atacante. En este caso, la posición ahora puede liquidarse (310M eDAI vs. 390M 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ó 310M eDAI y 259M dDAI.
El atacante quemó 38.9M eDAI para retirar 38.9M DAI (no puede retirar más debido a las verificaciones de insolvencia) en la posición del liquidador (0xa0b3...).
El atacante reembolsó el préstamo relámpago.

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

Resumen

Este fue el hackeo más grande de 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 200K dólares) fue enviada "sin saberlo" al Grupo Lazarus, un presunto sindicato criminal norcoreano patrocinado por el estado y sancionado por el Tesoro de los EE. UU. Puede consultar estos enlaces, es decir, link2 y link2, 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 proyectos deben monitorear proactivamente su protocolo de préstamos en busca de liquidaciones significativas y establecer sistemas de alerta efectivos para detectar y responder con prontitud a dichos eventos.