Euler Finance Incident Post-Mortem

Omniscia
6 min readMar 13, 2023
omniscia.io

This article is meant to analyze the Euler Finance incident that occurred on the 13th of March at approximately 08:50 UTC in an impartial way and identify the root cause.

Vulnerability Analysis

The vulnerability that was exploited stems from how Euler Finance permits donations to be performed without a proper account health check.

The vulnerable code was introduced in eIP-14¹ which introduced multiple changes throughout the Euler Ecosystem. The flaw lies in the first change performed to the EToken implementation (EToken::donateToReserves feature²).

The logic within the Liquidation module will attempt to repay the full debt of the violator, however, if the collateral they possess would not satisfy the expected repayment yield, the system defaults to whatever collateral the user has³.

The assumption of this code block states that a borrower’s available collateral will be insufficient only when:

This can happen when borrower has multiple collaterals and seizing all of this one won’t bring the violator back to solvency

This security guarantee is not upheld by the donation mechanism which permits the user to create “bad debt” in the form of leverage that is uncollateralized by donating their EToken units without affecting their DToken balance⁴.

Core Problem

The Euler Finance protocol permits its users to create artificial leverage by minting and depositing assets in the same transaction via EToken::mint. This mechanism permits tokens to be minted that exceed the collateral held by the Euler Finance protocol itself.

The donation mechanism introduced by Euler Finance in eIP-14¹ (EToken::donateToReserves) permits a user to donate their balance to the reserveBalance of the token they are transacting with. The flaw lies in that it does not perform any health check on the account that is performing the donation.

As a donation will cause a user’s debt (DToken) to remain unchanged while their equity (EToken) balance decreases, a liquidation of their account will cause a portion of DToken units to remain at the user thus creating bad debt.

The above flaw permits the attacker to create an over-leveraged position and liquidate it themselves in the same block by artificially causing it to go “under-water”.

When the violator liquidates themselves, a percentage-based discount is applied that will cause the liquidator to incur a significant portion of EToken units at a discount, guaranteeing that the they will be “above-water” and incur only the debt that matches the collateral they will acquire.

The end result is a violator with a significant amount of “bad debt” (DToken) and a liquidator with an over-collateralization of their debt (DToken > EToken) due to the percentage-based liquidation incentives the Euler Protocol possesses⁵. As evidenced in the transaction itself⁶, the maximum 20% discount was applied during the attack’s liquidation.

Attack Scenario

In order for the attacker to be able to liquidate themselves, they had to deploy at least two contracts to exploit the vulnerability. The attack transaction⁶ submitted at approximately 2023–02–01 06:29:18 UTC invokes a contract that had been deployed in an earlier transaction⁷.

This contract performs the following steps during the attack transaction’s execution:

a. Primary Contract:

  • Acquire a 30m DAI flash-loan from AAVE V2
  • Deploy the two contracts (violator & liquidator) for the attack
  • Transfer the full 30m DAI loan balance to the violator

b. violator Contract:

  • Deposit 20m DAI to the DAI EToken of Euler Finance, receiving ~19,56m eDAI tokens
  • Create a 200m artificial eDAI leverage, minting ~195,68m eDAI and 200m dDAI to the violator
  • Repay 10m DAI on the violator’s position, causing their dDAI balance to go to 190m
  • Create another 200m artificial eDAI leverage, minting ~195,68m eDAI and 200m dDAI to the violator
  • Donate 100m eDAI to the reserve of the EToken

At this point, we have the following violator state:

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

In the above state, the violator contains a significantly larger amount of dDAI tokens than eDAI tokens that will never be collateralized as their backing was “erased” during the donation call. The liquidator will exploit this due to the calculations within the Liquidation module.

As stated earlier, the Liquidation module will liquidate up-to the collateral balance of the user. The liquidator can thus liquidate the violator, incurring their full ~310,93m eDAI balance but only a portion of their dDAI balance, further exacerbated by the liquidation discount of Euler Finance⁵.

As the maximum discount will be applied to this position due to how low its health level is, the liquidator will incur a ~310,93m eDAI balance with a conversion rate of 1.25 eDAI tokens per dDAI. This will ultimately evaluate to a post-fee ~259,31m dDAI balance.

liquidator Contract:

  • Liquidate the position, acquiring ~310,93m eDAI tokens and ~259,31m dDAI tokens
  • Withdraw the full reserve of DAI tokens by burning the corresponding eDAI tokens

At the withdrawal step, the eDAI to DAI exchange rate honored by EToken is skewed as the exchange rate calculated¹⁰ factors in the total borrows of the system which are artificially increased by the liquidation’s repayExtra value.

As such, an exchange rate of roughly 0,97 eDAI per DAI is utilized for the redemption. As the user is already “above-water” due to the maximum 20% liquidation discount that was applied during their liquidation, they are able to “burn” the ~38m eDAI required to release the ~38.9m DAI held by the contract.

Ultimately, the attacker was able to retain the following assets post-execution of their transaction:

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

The contracts the attacker utilized also possess non-zero eDAI and dDAI balances with a health factor of ~1.05 for the liquidator contract in particular. As such, users should avoid re-depositing DAI tokens to the EToken as they may still be vulnerable.

We can assess the financial impact of the DAI asset and calculate an estimated profit of roughly ~8,779,854.423 USD as of 2023-03-13 12:42:00 UTC.

The attack has been replicated to multiple other assets. As such, the deposit warning applies to the following EToken assets: DAI, WETH

Security Audit

Omniscia has performed multiple security audits of the Euler Finance protocol. The changes in question, however, were introduced in eIP-14. As evidenced in the message board itself, Omniscia performed an audit of only the Chainlink integration component that is publicly available here.

The EToken::donateToReserve feature that is at the crux of this vulnerability was not in scope of any audit conducted by Omniscia. As such, the code that causes the vulnerability was never in scope of any audit conducted by our team.

The donateToReserves function was audited by the Sherlock team in July 2022. Euler Finance and Sherlock have confirmed that Euler had an active coverage policy with Sherlock at the time of exploit.

Conclusion

The attack ultimately arose from an incorrect donation mechanism and did not account for the donator’s debt health, permitting them to create an unbacked DToken debt that will never be liquidated.

Sources

  1. Euler Improvement Proposal 14: https://forum.euler.finance/t/eip-14-contract-upgrades/305
  2. Euler Improvement Proposal 14 Delta: https://euler-xyz.github.io/euler-contracts-upgrade-diffs/eip14/EToken.html
  3. Euler Liquidator Collateral Default Logic: https://github.com/euler-xyz/euler-contracts/blob/fa9398728165676a5666939d8c34a7578d8e1919/contracts/modules/Liquidation.sol#L139-L151
  4. Euler EToken Faulty Donation Mechanism: https://github.com/euler-xyz/euler-contracts/blob/fa9398728165676a5666939d8c34a7578d8e1919/contracts/modules/EToken.sol#L356-L386
  5. Euler Liquidation Discount: https://docs.euler.finance/euler-protocol/eulers-default-parameters#maximum-liquidation-discount
  6. Etherscan Attack Transaction Link: https://etherscan.io/tx/0xc310a0affe2169d1f6feec1c63dbc7f7c62a887fa48795d327d4d2da2d6b111d
  7. Etherscan Address of Primary Contract: https://etherscan.io/address/0xebc29199c817dc47ba12e3f86102564d640cbf99
  8. Etherscan Address of Violator Contract: https://etherscan.io/address/0x583c21631c48d442b5c0e605d624f54a0b366c72
  9. Etherscan Address of Liquidator Contract: https://etherscan.io/address/0xa0b3ee897f233f385e5d61086c32685257d4f12b
  10. Euler BaseLogic Exchange Rate Calculation: https://github.com/euler-xyz/euler-contracts/blob/fa9398728165676a5666939d8c34a7578d8e1919/contracts/BaseLogic.sol#L292-L296

Omniscia.io is one of the fastest growing and most trusted blockchain security firms and has rapidly become a true market leader. To date, our team has collectively secured over $200+ billion worth of digital assets, worked with 260+ clients and detected over 1300+ high-severity issues in our clients’ smart contracts.

Founded at the start of 2021 by blockchain cybersecurity veterans, omniscia.io is a pioneer in Web3 security, utilizing years of experience, developing proprietary tooling and a tried-and-tested approach to securing smart contracts and complex decentralized protocols out there — including the likes Aave, YFI, lien, 1inch, fetch, compound, synthetix, and many others.

Our clients, partners and backers include leading ecosystem players such as L’Oréal, Polygon, AvaLabs, Morpho, Euler, CLabs, Olympus DAO, Fetch.ai, LimitBreak, and many more.

Be sure to follow our social medias and subscribe to our newsletter for more updates:

Twitter / LinkedIn / Newsletter

--

--

Omniscia

Team of experienced smart contract auditors & developers with deep expertise building & securing complex #decentralized networks & applications …