Full Report
EraLend, a lending platform on zkSync Era, was hacked. Within the SyncSwap project, there is an LP token. The EraLend protocol was using a price oracle from SyncSwap. Keeping all values in a good state is important. This is particular important when external calls are possible. In this case, the totalSupply is modified by a call to burn() but there is an external call prior to updating the reserves. When calculating the oracle price, it uses the reserves. Since the external call exists, an attacker could leave the contract in a state where the supply and reserve do not match. This results in the oracle inflating the price of the asset. I personally do not understand why being in this state benefits the attacker and I cannot seem to find code from Eraland. So, just going to take their word for it. What's funny, is that this behavior of the LP token is documented in the code and viewed as a feature. This is shown in the tweet. Read only reentrancy as a service!
Analysis Summary
# Incident Report: EraLend Price Oracle Manipulation
## Executive Summary
On July 25, 2023, EraLend, a decentralized lending protocol on zkSync Era, was exploited for approximately $3.4 million. The attacker leveraged a "read-only reentrancy" vulnerability within the SyncSwap LP token contract, which EraLend used as a price oracle. By manipulating the sequence of reserve updates during a liquidity burn, the attacker inflated collateral values to drain USDC from the protocol.
## Incident Details
- **Discovery Date:** July 26, 2023
- **Incident Date:** July 25, 2023
- **Affected Organization:** EraLend (formerly Nexon Finance)
- **Sector:** Decentralized Finance (DeFi) / Cryptocurrency
- **Geography:** Global / zkSync Era Layer 2
## Timeline of Events
### Initial Access
- **Date/Time:** July 25, 2023
- **Vector:** Smart Contract Vulnerability (Read-only Reentrancy)
- **Details:** The attacker exploited the `burn()` function in SyncSwap LP tokens. The code triggered an external callback before updating the pool's reserves (`update_reserves`).
### Lateral Movement
- **Details:** The attacker interacted with EraLend’s lending markets, using the manipulated LP token state to influence the price oracle.
### Data Exfiltration/Impact
- **Details:** The attacker successfully drained approximately $3.4 million in USDC deposits from the EraLend protocol. Funds were subsequently bridged to Ethereum (ETH), Arbitrum (ARB), and Optimism (OP).
### Detection & Response
- **Detection:** Security firms like BlockSec and PeckShield identified the malicious transactions on-chain.
- **Response Actions:** SyncSwap issued warnings to users to withdraw LP tokens from EraLend as a precaution. EraLend paused/affected operations while the community analyzed the breach.
## Attack Methodology
- **Initial Access:** Exploitation of logic flaw in SyncSwap LP token contract (reused code).
- **Impact:** The primary technique was **Read-only Reentrancy**. Specifically:
1. Attacker calls `burn()` on the LP token.
2. The contract burns the supply but triggers an external callback *before* updating the reserve values.
3. During this callback, the attacker queries the EraLend price oracle.
4. The oracle calculates the price using the decreased total supply but the *old* (higher) reserve values.
5. This results in an artificially inflated asset price, allowing the attacker to borrow against non-existent value.
## Impact Assessment
- **Financial:** ~$3.4 million total loss (attacker realized ~$2.66 million in profit).
- **Data Breach:** N/A (Smart contract exploit).
- **Operational:** Disruption of USDC lending markets on EraLend; permanent loss of liquidity for affected users.
- **Reputational:** High; it was noted that the vulnerability was documented in the code comments but never mitigated by the EraLend team or identified in their audit.
## Indicators of Compromise
- **Attacker Address:** `0xf1D076c9Be4533086f967e14EE6aFf204D5ECE7a`
- **Transaction Hash 1:** `0x7ac4da1ea1b0903dfabda56f713ea5e4a960a3fc34467a844d037f86ee8bfe98`
- **Transaction Hash 2:** `0x99efebacb3edaa3ac34f7ef462fd8eed85b46be281bd1329abfb215a494ab0ef`
## Response Actions
- **Containment:** Community alerts via Twitter/X advised users to withdraw liquidity.
- **Analysis:** External security firms (BlockSec) published technical post-mortems and warnings to other protocols using similar SyncSwap-based code.
- **Eradication:** Identification of the specific "read-only" vulnerability in the oracle logic.
## Lessons Learned
- **Code Comments Matter:** The SyncSwap code contained a comment explicitly stating reserves were not updated at a certain point to allow reading old values—a "feature" that became a critical bug when used as an oracle.
- **Audit Limitations:** Audits that "assume a trusted price oracle" take a significant risk, as oracle manipulation is a leading cause of DeFi exploits.
- **Read-Only Reentrancy Relevancy:** Even if a function does not change state (view functions), it can still be exploited if called while another contract is in an inconsistent state.
## Recommendations
- **Implement Reentrancy Guards:** Use `nonReentrant` modifiers even on "view" functions that are critical for price calculations.
- **Oracle Resilience:** Avoid using spot prices or internal LP reserves as a direct oracle source. Use Time-Weighted Average Prices (TWAP) or decentralized oracle networks (e.g., Chainlink).
- **Due Diligence on Forked Code:** When reusing or integrating with third-party code, verify that its internal logic (and documented "features") does not conflict with your protocol's security assumptions.