Este artículo tiene como objetivo analizar el incidente de Euler Finance que ocurrió el 13 de marzo aproximadamente a las 08:50 UTC de manera imparcial e identificar la causa raíz.

Análisis de vulnerabilidad

La vulnerabilidad que se aprovechó se deriva de cómo Euler Finance permite que se realicen donaciones sin una verificación de estado de cuenta adecuada.

El código vulnerable se introdujo en eIP-14 ¹ que introdujo múltiples cambios en todo el ecosistema de Euler. La falla radica en el primer cambio realizado a la ETokenimplementación ( EToken::donateToReservescaracterística ²).

La lógica dentro del Liquidationmódulo intentará pagar la deuda total del infractor; sin embargo, si la garantía que posee no satisface el rendimiento de pago esperado, el sistema utiliza por defecto la garantía que tenga el usuario ³.

El supuesto de este bloque de código establece que la garantía disponible de un prestatario será insuficiente solo cuando:

Esto puede suceder cuando el prestatario tiene múltiples garantías y la incautación de todas estas no devolverá la solvencia al infractor.

Esta garantía de seguridad no está respaldada por el mecanismo de donación que permite al usuario crear "deudas incobrables" en forma de apalancamiento sin garantía mediante la donación de sus ETokenunidades sin afectar su DTokensaldo⁴.

Problema central

El protocolo Euler Finance permite a sus usuarios crear un apalancamiento artificial acuñando y depositando activos en la misma transacción a través de EToken::mint. Este mecanismo permite acuñar tokens que superan la garantía que posee el propio protocolo Euler Finance.

El mecanismo de donación introducido por Euler Finance en eIP-14 ¹ ( EToken::donateToReserves) permite a un usuario donar su saldo al reserveBalancetoken con el que está realizando la transacción. La falla radica en que no realiza ningún control de salud en la cuenta que está realizando la donación.

Como una donación hará que la deuda de un usuario ( DToken) permanezca sin cambios mientras que su ETokensaldo de capital ( ) disminuya, una liquidación de su cuenta hará que una parte de DTokenlas unidades permanezca en el usuario creando así una deuda incobrable.

La falla anterior permite al atacante crear una posición sobreapalancada y liquidarla él mismo en el mismo bloque al hacer que se “hunda” artificialmente.

Cuando se violatorliquidan, se aplica un descuento basado en porcentajes que hará que liquidatorincurran en una porción significativa de ETokenunidades con descuento, lo que garantiza que estarán "sobre el agua" e incurrirán solo en la deuda que coincida con la garantía que adquirirán. .

El resultado final es una violatorcantidad significativa de "deuda incobrable" ( DToken) y una liquidatorgarantía excesiva de su deuda ( DToken> EToken) debido a los incentivos de liquidación basados ​​en porcentajes que posee el Protocolo de Euler ⁵. Como se evidencia en la propia transacción⁶, durante la liquidación del ataque se aplicó el descuento máximo del 20%.

Escenario de ataque

Para que el atacante pudiera liquidarse a sí mismo, tuvo que implementar al menos dos contratos para explotar la vulnerabilidad. La transacción de ataque ⁶ enviada aproximadamente el 01 de febrero de 2023 a las 06:29:18 UTC invoca un contrato que se había implementado en una transacción anterior⁷.

Este contrato realiza los siguientes pasos durante la ejecución de la transacción de ataque:

a. Contrato principal:

• Adquirir un flash-loan de 30m DAI de AAVE V2
• Despliegue los dos contratos ( violator⁸& liquidator⁹) para el ataque
• Transferir el saldo total del préstamo DAI de 30 millones alviolator

• Deposita 20m DAI al DAI ETokende Euler Finance, recibiendo ~19,56m eDAItokens
• Crear un eDAIapalancamiento artificial de 200m, acuñando ~195,68m eDAIy 200m dDAIalviolator
• Reembolse 10 millones de DAI en la violatorposición de , lo que hace que su dDAIsaldo sea de 190 millones
• Crear otro eDAIapalancamiento artificial de 200m, acuñando ~195,68m eDAIy 200m dDAIalviolator
• Donar 100m eDAIa la reserva de laEToken

• eDAI: ~310,93m
• dDAI: 390m

Como se indicó anteriormente, el Liquidationmódulo se liquidará hasta el saldo colateral del usuario. Por lo tanto, pueden liquidatorliquidar el violator, incurriendo en su eDAIsaldo total de ~310,93m pero solo en una parte de su dDAIsaldo, exacerbado aún más por el descuento de liquidación de Euler Finance⁵.

Como se aplicará el descuento máximo a esta posición debido a lo bajo que es su nivel de salud, incurrirá liquidatoren un eDAIsaldo de ~310,93m con una tasa de conversión de 1.25 eDAItokens por dDAI. En última instancia, esto se evaluará en un dDAIsaldo posterior a la tarifa de ~ 259,31 millones.

liquidatorContrato:

• Liquidar la posición, adquiriendo ~310,93m eDAItokens y ~259,31m dDAItokens
• Retirar la reserva completa de DAItokens quemando los eDAItokens correspondientes

Como tal, se utiliza una tasa de cambio de aproximadamente 0,97 eDAIper para el reembolso. DAIComo el usuario ya está "sobre el agua" debido al descuento de liquidación máximo del 20 % que se aplicó durante su liquidación, puede "quemar" los ~38 millones necesarios eDAIpara liberar los ~38,9 millones DAIque retiene el contrato.

En última instancia, el atacante pudo retener los siguientes activos después de la ejecución de su transacción:

• +~8,877,507 DAI=~8,779,854.423 USD

Podemos evaluar el impacto financiero del DAIactivo y calcular una ganancia estimada de aproximadamente ~8,779,854.423 USDel 13/03/2023 a las 12:42:00 UTC.

El ataque se ha replicado en muchos otros activos. Como tal, la advertencia de depósito se aplica a los siguientes ETokenactivos :DAIWETH

Auditoría de seguridad

Omniscia ha realizado múltiples auditorías de seguridad del protocolo Euler Finance. Los cambios en cuestión, sin embargo, se introdujeron en eIP-14 . Como se evidencia en el tablero de mensajes, Omniscia realizó una auditoría solo del componente de integración de Chainlink que está disponible públicamente aquí .

La EToken::donateToReservecaracterística que está en el centro de esta vulnerabilidad no estaba dentro del alcance de ninguna auditoría realizada por Omniscia. Como tal, el código que causa la vulnerabilidad nunca estuvo dentro del alcance de ninguna auditoría realizada por nuestro equipo.

La función donateToReserves fue auditada por el equipo de Sherlock en julio de 2022. Euler Finance y Sherlock confirmaron que Euler tenía una política de cobertura activa con Sherlock en el momento del exploit.

Conclusión

En última instancia, el ataque surgió de un mecanismo de donación incorrecto y no tuvo en cuenta la salud de la deuda del donante, lo que les permitió crear una DTokendeuda sin respaldo que nunca se liquidará.

Fuentes

1. Propuesta de mejora de Euler 14:https://forum.euler.finance/t/eip-14-contract-upgrades/305
2. Propuesta de mejora de Euler 14 Delta:https://euler-xyz.github.io/euler-contracts-upgrade-diffs/eip14/EToken.html
3. LiquidatorLógica predeterminada de garantía de Euler :https://github.com/euler-xyz/euler-contracts/blob/fa9398728165676a5666939d8c34a7578d8e1919/contracts/modules/Liquidation.sol#L139-L151
4. ETokenMecanismo de donación defectuoso de Euler :https://github.com/euler-xyz/euler-contracts/blob/fa9398728165676a5666939d8c34a7578d8e1919/contracts/modules/EToken.sol#L356-L386
5. Descuento por liquidación de Euler:https://docs.euler.finance/euler-protocol/eulers-default-parameters#maximum-liquidation-discount
6. Enlace de transacción de ataque Etherscan:https://etherscan.io/tx/0xc310a0affe2169d1f6feec1c63dbc7f7c62a887fa48795d327d4d2da2d6b111d
7. Dirección de Etherscan del contrato principal:https://etherscan.io/address/0xebc29199c817dc47ba12e3f86102564d640cbf99
8. Dirección Etherscan del contrato infractor:https://etherscan.io/address/0x583c21631c48d442b5c0e605d624f54a0b366c72
9. Dirección de Etherscan del contrato del liquidador:https://etherscan.io/address/0xa0b3ee897f233f385e5d61086c32685257d4f12b
10. Cálculo del tipo de cambio de Euler BaseLogic:https://github.com/euler-xyz/euler-contracts/blob/fa9398728165676a5666939d8c34a7578d8e1919/contracts/BaseLogic.sol#L292-L296

Fundada a principios de 2021 por veteranos de ciberseguridad de blockchain, omniscia.io es pionera en seguridad Web3, utiliza años de experiencia, desarrolla herramientas patentadas y un enfoque probado para asegurar contratos inteligentes y protocolos descentralizados complejos, incluido el le gusta Aave, YFI, Lien, 1inch, Fetch, Compound, Synthetix y muchos otros.

Nuestros clientes, socios y patrocinadores incluyen actores líderes del ecosistema como L'Oréal, Polygon, AvaLabs, Morpho, Euler, CLabs, Olympus DAO, Fetch.ai, LimitBreak y muchos más.

Asegúrese de seguir nuestras redes sociales y suscríbase a nuestro boletín para obtener más actualizaciones:

Twitter / LinkedIn / Boletín