Questo articolo ha lo scopo di analizzare in modo imparziale l'incidente di Euler Finance che si è verificato il 13 marzo alle 08:50 UTC circa e di identificare la causa principale.

Analisi della vulnerabilità

La vulnerabilità sfruttata deriva dal modo in cui Euler Finance consente di effettuare donazioni senza un adeguato controllo dello stato dell'account.

Il codice vulnerabile è stato introdotto in eIP-14 ¹ che ha introdotto molteplici modifiche in tutto l'ecosistema di Eulero. Il difetto risiede nella prima modifica apportata all'implementazione EToken( EToken::donateToReservescaratteristica ²).

La logica all'interno del Liquidationmodulo tenterà di rimborsare l'intero debito del trasgressore, tuttavia, se la garanzia in suo possesso non soddisfa il rendimento di rimborso previsto, il sistema si imposta automaticamente sulla garanzia che l'utente ha ³.

Il presupposto di questo blocco di codice afferma che la garanzia disponibile di un mutuatario sarà insufficiente solo quando:

Ciò può accadere quando il mutuatario ha più garanzie collaterali e il sequestro di tutto questo non riporterà il trasgressore alla solvibilità

Questa garanzia di sicurezza non è supportata dal meccanismo di donazione che consente all'utente di creare "crediti inesigibili" sotto forma di leva non collateralizzata donando le proprie ETokenquote senza intaccarne il DTokensaldo⁴.

Problema fondamentale

Il protocollo Euler Finance consente ai suoi utenti di creare una leva artificiale coniando e depositando asset nella stessa transazione tramite EToken::mint. Questo meccanismo consente di coniare token che eccedono il collaterale detenuto dal protocollo Euler Finance stesso.

Il meccanismo di donazione introdotto da Euler Finance in eIP-14 ¹ ( EToken::donateToReserves) consente a un utente di donare il proprio saldo al reserveBalancetoken con cui sta effettuando transazioni. La falla sta nel fatto che non esegue alcun controllo sanitario sul conto che sta effettuando la donazione.

Poiché una donazione farà sì che il debito di un utente ( DToken) rimanga invariato mentre il suo ETokensaldo di capitale ( ) diminuisce, una liquidazione del suo account farà sì che una parte delle DTokenunità rimanga all'utente creando così crediti inesigibili.

Il difetto di cui sopra consente all'attaccante di creare una posizione con un indebitamento eccessivo e di liquidarla nello stesso blocco facendola andare artificialmente "sott'acqua".

Quando le violatorliquidazioni stesse, viene applicato uno sconto percentuale che farà in modo che liquidatorincorrano una parte significativa delle ETokenunità con uno sconto, garantendo che saranno "sopra l'acqua" e contrarranno solo il debito che corrisponde alla garanzia che acquisteranno .

Il risultato finale è un violatorcon una quantità significativa di "crediti inesigibili" ( DToken) e liquidatorcon una sovra-collateralizzazione del loro debito ( DToken> EToken) a causa degli incentivi di liquidazione basati sulla percentuale che il Protocollo di Eulero possiede ⁵. Come evidenziato nella transazione stessa⁶, lo sconto massimo del 20% è stato applicato durante la liquidazione dell'attacco.

Scenario di attacco

Affinché l'attaccante potesse liquidarsi, ha dovuto implementare almeno due contratti per sfruttare la vulnerabilità. La transazione di attacco ⁶ inviata all'incirca 2023-02-01 06:29:18 UTC richiama un contratto che era stato implementato in una transazione precedente⁷.

Questo contratto esegue i seguenti passaggi durante l'esecuzione della transazione di attacco:

UN. Contratto principale:

• Acquisisci un prestito flash DAI di 30 milioni da AAVE V2
• Distribuisci i due contratti ( violator⁸& liquidator⁹) per l'attacco
• Trasferisci l'intero saldo del prestito DAI di 30 milioni alviolator

• Deposita 20 milioni di DAI nel DAI ETokendi Euler Finance, ricevendo ~19,56 milioni eDAIdi token
• Crea una eDAIleva artificiale di 200m, coniando ~195,68m eDAIe 200m dDAIalviolator
• Rimborsa 10 milioni di DAI sulla violatorposizione di , portando il suo dDAIsaldo a 190 milioni
• Crea un'altra eDAIleva artificiale di 200m, coniando ~195,68m eDAIe 200m dDAIalviolator
• Dona 100 milioni eDAIalla riserva delEToken

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

Come affermato in precedenza, il Liquidationmodulo liquiderà fino al saldo collaterale dell'utente. Possono liquidatorquindi liquidare il violator, incorrendo nel loro intero eDAIsaldo di ~310,93 milioni ma solo in una parte del loro dDAIsaldo, ulteriormente esacerbato dallo sconto di liquidazione di Euler Finance⁵.

Poiché a questa posizione verrà applicato lo sconto massimo a causa del basso livello di salute, verrà liquidatoraddebitato un eDAIsaldo di ~310,93 milioni con un tasso di conversione di 1.25 eDAItoken per dDAI. Questo alla fine si tradurrà in un saldo al netto della commissione di ~ 259,31 milioni dDAI.

liquidatorContrarre:

• Liquida la posizione, acquisendo ~310,93 milioni eDAIdi token e ~259,31 milioni dDAIdi token
• Ritira l'intera riserva di DAIgettoni bruciando i eDAIgettoni corrispondenti

Pertanto, per il riscatto viene utilizzato un tasso di cambio di circa 0,97 eDAIper . DAIPoiché l'utente è già "sopra l'acqua" a causa dello sconto di liquidazione massimo del 20% applicato durante la liquidazione, è in grado di "bruciare" i ~38 milioni necessari eDAIper liberare i ~38,9 milioni DAItrattenuti dal contratto.

Alla fine, l'attaccante è stato in grado di conservare le seguenti risorse dopo l'esecuzione della transazione:

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

Possiamo valutare l'impatto finanziario dell'asset DAIe calcolare un profitto stimato approssimativamente ~8,779,854.423 USDal 2023-03-13 12:42:00 UTC.

L'attacco è stato replicato su molte altre risorse. Pertanto, l'avviso di deposito si applica alle seguenti ETokenattività : DAI,WETH

Audit di sicurezza

Omniscia ha eseguito più controlli di sicurezza del protocollo Euler Finance. Le modifiche in questione, tuttavia, sono state introdotte in eIP-14 . Come evidenziato nella bacheca stessa, Omniscia ha eseguito un audit solo del componente di integrazione Chainlink disponibile pubblicamente qui .

La EToken::donateToReservecaratteristica che è al centro di questa vulnerabilità non rientrava nell'ambito di alcun controllo condotto da Omniscia. Pertanto, il codice che causa la vulnerabilità non è mai stato oggetto di alcun controllo condotto dal nostro team.

La funzione donateToReserves è stata verificata dal team di Sherlock nel luglio 2022. Euler Finance e Sherlock hanno confermato che Euler aveva una politica di copertura attiva con Sherlock al momento dell'exploit.

Conclusione

L'attacco alla fine è nato da un meccanismo di donazione errato e non ha tenuto conto della salute del debito del donatore, consentendo loro di creare un DTokendebito non garantito che non sarà mai liquidato.

Fonti

1. Proposta di miglioramento di Eulero 14:https://forum.euler.finance/t/eip-14-contract-upgrades/305
2. Proposta di miglioramento di Eulero 14 Delta:https://euler-xyz.github.io/euler-contracts-upgrade-diffs/eip14/EToken.html
3. LiquidatorLogica predefinita collaterale di Eulero :https://github.com/euler-xyz/euler-contracts/blob/fa9398728165676a5666939d8c34a7578d8e1919/contracts/modules/Liquidation.sol#L139-L151
4. ETokenMeccanismo di donazione difettoso di Euler :https://github.com/euler-xyz/euler-contracts/blob/fa9398728165676a5666939d8c34a7578d8e1919/contracts/modules/EToken.sol#L356-L386
5. Sconto di liquidazione di Euler:https://docs.euler.finance/euler-protocol/eulers-default-parameters#maximum-liquidation-discount
6. Link transazione attacco Etherscan:https://etherscan.io/tx/0xc310a0affe2169d1f6feec1c63dbc7f7c62a887fa48795d327d4d2da2d6b111d
7. Indirizzo Etherscan del contratto principale:https://etherscan.io/address/0xebc29199c817dc47ba12e3f86102564d640cbf99
8. Indirizzo Etherscan del contratto del trasgressore:https://etherscan.io/address/0x583c21631c48d442b5c0e605d624f54a0b366c72
9. Indirizzo Etherscan del contratto del liquidatore:https://etherscan.io/address/0xa0b3ee897f233f385e5d61086c32685257d4f12b
10. BaseLogicCalcolo del tasso di cambio di Eulero :https://github.com/euler-xyz/euler-contracts/blob/fa9398728165676a5666939d8c34a7578d8e1919/contracts/BaseLogic.sol#L292-L296

Fondata all'inizio del 2021 da veterani della sicurezza informatica blockchain, omniscia.io è un pioniere nella sicurezza Web3, utilizzando anni di esperienza, sviluppando strumenti proprietari e un approccio collaudato per garantire contratti intelligenti e complessi protocolli decentralizzati là fuori, incluso il ama Aave, YFI, lien, 1inch, fetch, compound, synthetix e molti altri.

I nostri clienti, partner e sostenitori includono i principali attori dell'ecosistema come L'Oréal, Polygon, AvaLabs, Morpho, Euler, CLabs, Olympus DAO, Fetch.ai, LimitBreak e molti altri.

Assicurati di seguire i nostri social media e iscriviti alla nostra newsletter per ulteriori aggiornamenti:

Twitter / Linkedin / Newsletter