Full Report
Conic uses the Curve protocol for trying to earn rewards. It has a concept of omnipools where the same underlying asset is distributed among multiple Curve pools. Currently, I'm not seeing the benefit of this from reading their docs. First, Immunefi spotted an exploit that occurred in the function _airdrop(). The code takes in three parameters: from, to and amount. These parameters have calculations done on them to determine the airdrop address. This includes an XOR with the block number, from address and to address. Eventually, this is used for the address of a balance call with the amount provided by amount in the function. It should be noted, there is no check on who the airdrop address is besides the manipulations that occur. The bug is that an attacker can set this to be an arbitrary user. Most importantly, they can set the address to be the address of the pairContract used for a pool. By setting this to 1 and calling sync() the pools price is very messed up, leading to an opportunity to make money. The second vulnerability exists in the integration between Curve and Conic. The reentrancy protection on the Omnipool was only turned in in the case of ETH pools being used. This was checked by calling checking CurveHandlerV3() to see if the pool had interacted with ETH. The check was made by seeing if it was 0xeee...ee, which is a standard for ETH address. However, in reality, this used the WETH address. Since the wrong address was being validated against, the reentrancy protection was broken. There is a known bug in Curve pools, which is read-only reentrancy. By manipulating the Curve pool then calling Omnipool contract for ETH allowed for an attacker to trick the pool into minting more cncETH LP tokens than they should have been rewarded. It's weird that this wasn't found in testing... The protocol had reentrancy protections in place. On top of this, they also had a mechanism to ensure that imbalanced Curve pools could not be interacted with. However, the threshold was not tight enough, which allowed the attacker to slowly drain the pool. I thought this was a great idea that just did not work because of the ability to preform this attack several times. Overall, two really interesting bugs! Manipulation of a pool by setting the amount of a particular contract to 1. Then, a known read-only reentrancy vulnerability exploit in Curve by finding a flaw in the prevention of this exact attack. What's the takeaway? Test your code to ensure it works!
Analysis Summary
# Vulnerability: Conic Finance Omnipool Multi-Vector Exploits
## CVE Details
- **CVE ID:** Not Assigned (DeFi Protocol Incident)
- **CVSS Score:** 8.8 (High) - Estimated based on total loss of funds.
- **CWE:** CWE-667 (Improper Locking), CWE-682 (Incorrect Calculation), CWE-841 (Improper Enforcement of Behavioral Workflow).
## Affected Systems
- **Products:** Conic Finance Omnipools
- **Versions:** All deployments prior to July 21, 2023.
- **Configurations:**
- **ETH Omnipool:** Specifically pools using `CurveHandlerV3` and interacting with Curve v2 pools.
- **crvUSD Omnipool:** Pools integrated with Curve where slippage/imbalance thresholds were loosely defined.
## Vulnerability Description
Conic Finance suffered two distinct exploits resulting in a total loss of approximately $4.1M:
1. **Read-Only Reentrancy (ETH Omnipool):** The protocol implemented a reentrancy guard that only triggered if a pool contained ETH (checked via `_isETH`). The logic incorrectly checked for the native ETH address (`0xeee...eee`) while Curve v2 pools use the WETH address. This failed check allowed an attacker to bypass reentrancy guards during a Curve LP price manipulation, tricking the Omnipool into minting an inflated amount of `cncETH` LP tokens.
2. **Imbalanced Pool Sandwich/Drain (crvUSD Omnipool):** The protocol failed to enforce sufficiently tight bounds on Curve pool imbalances. Attackers performed a series of coordinated exchanges, deposits, and withdrawals that leveraged favorable exchange rates caused by their own trades, essentially "sandwiching" the protocol's accounting logic to slowly drain funds.
## Exploitation
- **Status:** Exploited in the wild (July 21-22, 2023).
- **Complexity:** Medium to High (Requires sophisticated understanding of Curve oracles and reentrancy).
- **Attack Vector:** Network (Smart Contract Interaction via Ethereum Mainnet).
## Impact
- **Confidentiality:** None
- **Integrity:** High (Internal accounting and LP token minting were compromised).
- **Availability:** High (Omnipools were shut down, and deposits were disabled).
## Remediation
### Patches
- **Protocol Shutdown:** Conic Finance disabled deposits for all existing Omnipools immediately following the second exploit.
- **Contract Updates:** Remediation requires a redeployment of updated `CurveHandler` contracts with corrected ETH/WETH address validation and tightened imbalance thresholds.
### Workarounds
- **Withdrawal:** Existing Liquidity Providers (LPs) were advised that withdrawals remained safe and functioning.
- **Emergency Pause:** All new capital inflows were halted by the core team to prevent further loss.
## Detection
- **Indicators of Compromise:**
- High-frequency deposit/withdraw cycles within a single block or short time window.
- Discrepancies between `cncETH` minting rates and actual underlying asset value.
- Large-scale imbalances in Curve pools immediately preceding Conic Omnipool interactions.
- **Detection Methods:** On-chain monitoring for reentrant calls to Curve V2 pools and monitoring of slippage deviations exceeding 1-2%.
## References
- **Vendor Post-Mortem:** [https://medium.com/@ConicFinance/post-mortem-eth-and-crvusd-omnipool-exploits-c9c7fa213a3d](https://medium.com/@ConicFinance/post-mortem-eth-and-crvusd-omnipool-exploits-c9c7fa213a3d)
- **ETH Exploit TX:** [https://etherscan.io/tx/0x8b74995d1d61d3d7547575649136b8765acb22882960f0636941c44ec7bbe146](https://etherscan.io/tx/0x8b74995d1d61d3d7547575649136b8765acb22882960f0636941c44ec7bbe146)
- **Technical Analysis (ChainSecurity):** [https://chainsecurity.com/curve-lp-oracle-manipulation-post-mortem/](https://chainsecurity.com/curve-lp-oracle-manipulation-post-mortem/)