Full Report
EarningFarm is a set of smart contracts that manage crypto assets. It has a native token, EF, that is used to demonstrate the amount of funds put into the protocol. The amount of EF token is passed to the withdraw() function to determines the amount of Ether that can be withdrawn. Prior to performing the withdraw, the contract may not have the funds to perform it with the proper token. So, it may take out a flashloan from balancer in order to do this. The amount of the flashloan and withdrawal depends on the balance of the EF token held by the user. The callback for the flashloan does a sanity check to see if it's coming from balancer or not. A user can manually invoke the flashloan via balancer and use ENF as the recipient. This completely bypasses the withdrawal limits. This means that a large sum of ETH was believed to be OWNED by the contract. The attacker could withdraw a small sum of funds but withdraw() always sends the full amount, since the difference is extremely large. In essence, bad input validation wins the day again. Here, the authors didn't consider that somebody else could invoke the call for receiveFlashLoan.
Analysis Summary
# Vulnerability: EarningFarm EFLeverVault Flashloan Logic Flaw
## CVE Details
- **CVE ID**: N/A (Smart contract vulnerabilities often lack formal CVE assignments; tracking via PeckShield/Supremacy advisories)
- **CVSS Score**: 9.1 (Critical - Estimated based on direct loss of funds)
- **CWE**: CWE-20: Improper Input Validation; CWE-670: Always-Incorrect Control Flow Implementation
## Affected Systems
- **Products**: EarningFarm Protocol
- **Versions**: EFLeverVault smart contract
- **Configurations**: Contracts utilizing the Balancer flashloan callback mechanism without adequate caller/state verification.
## Vulnerability Description
The vulnerability exists in the `receiveFlashLoan` callback function within the `EFLeverVault` contract. While the contract performed a basic check to ensure the caller was the Balancer Vault, it failed to validate the transaction's initiation context.
Under normal operations, a user initiates a `withdraw()`, which triggers the contract to take a flashloan. However, the contract allowed any external user to trigger a Balancer flashloan and designate the `EFLeverVault` as the recipient. Because the contract assumed that any incoming flashloan in the callback was part of its own legitimate withdrawal flow, the attacker could manipulate the logic to bypass withdrawal limits and drain the contract’s Ether reserves.
## Exploitation
- **Status**: Exploited in the wild (October 2022).
- **Complexity**: Medium
- **Attack Vector**: Network (Blockchain/Smart Contract Call)
## Impact
- **Confidentiality**: None
- **Integrity**: High (Unauthorized manipulation of contract state and funds)
- **Availability**: High (Drainage of protocol liquidity)
- **Financial Loss**: Approximately 748 ETH (480 ETH via MEV Bot intervention and 268 ETH by the original attacker).
## Remediation
### Patches
- The EarningFarm team has reportedly paused or upgraded the affected vaults to prevent further exploitation. Users should ensure they are interacting with versioned contracts that include state-consistency checks.
### Workarounds
- **Caller Verification**: Implement a state variable (e.g., a boolean flag) that is set to `true` only when the contract itself initiates a flashloan and checked/reset within the callback.
- **Access Control**: Restrict the `receiveFlashLoan` callback to verify that the internal treasury logic expecting the funds is actually active.
## Detection
- **Indicators of Compromise**: Transactions involving the `EFLeverVault` where the flashloan initiator is not the contract itself.
- **Detection Tools**: Real-time monitoring via Forta or Tenderly to alert on large ETH transfers from `EFLeverVault` occurring within a single transaction block involving Balancer flashloans.
## References
- [x].com/SupremacyHQ/status/1581203875691069440
- [etherscan].io/tx/0x160c5950a01b88953648ba90ec0a29b0c5383e055d35a7835d905c53a3dda01e
- [peckshield].com/2022/10/15/earningfarm-incident-analysis/