Full Report
Crema is an Automated Market Maker (AMM) that allows users to concentrate their funds into a specific zones for trading. This allows users to use of their resources, instead of a small fraction of them. With this model, liquidity providers can specify price ranges for when their liquidity should be traded. The issue was susceptibility to flash loan attacks. First, the attacker created a tick account. This is an account dedicated to storing the price data of the AMM. Next, they took out a large flash loan to add the liquidity to Crema. The calculation of the fees relies on the data from the tick account. Since the tick could be controlled by the attacker, this was sending out malicious data. Particularly, it sent that the fee for a transaction was gigantic, stealing a large amount of capital in the process. Since the attacker took out the flash loan, the impact was quite dramatic. They owned a large amount of the transaction fees (with their large capital) and the tick account with the large transaction fee being provided. This resulted in a large amount of money from the protocol being stolen. My question is how does somebody get to set the price of the transaction fee? That seems really strange that an account can be created and simply do that. The protocol has some verification steps, but this was trivial bypassed.
Analysis Summary
# Incident Report: Crema Finance Concentrated Liquidity Exploit
## Executive Summary
On July 2, 2022, Crema Finance, a Solana-based concentrated liquidity protocol, was exploited for approximately $8.7 million. The attacker utilized a flash loan and a malicious "tick account" to manipulate transaction fee calculations, allowing them to claim inflated fees. Following negotiations, the attacker returned the majority of the funds in exchange for a $1.4 million white-hat bounty.
## Incident Details
- **Discovery Date:** July 2, 2022
- **Incident Date:** July 2, 2022
- **Affected Organization:** Crema Finance
- **Sector:** Decentralized Finance (DeFi)
- **Geography:** Global / Solana Ecosystem
## Timeline of Events
### Initial Access
- **Date/Time:** July 2, 2022
- **Vector:** Exploitation of insufficient validation on "tick accounts."
- **Details:** The attacker created a malicious tick account (price data storage) and bypassed the protocol’s routine owner verification checks.
### Lateral Movement
- **Process:** The attacker deployed a custom smart contract and secured a large flash loan from Solend to provide massive liquidity to a Crema CLMM pool. By controlling the tick account associated with this liquidity, they could manipulate the data used to calculate transaction fees.
### Data Exfiltration/Impact
- **Financial Loss:** The attacker triggered a fee calculation that referenced the malicious tick data, resulting in a "gigantic" fee payout.
- **Asset Movement:** Drained assets were converted into 69,422.9 SOL and 6,497,738 USDCet via the Jupiter aggregator, then bridged to Ethereum and swapped for 6,064 ETH.
### Detection & Response
- **Detection:** Identified via anomalous protocol outflows and liquidity imbalances.
- **Response:** Operations were halted protocol-wide. The team initiated on-chain negotiations with the attacker.
- **Resolution:** After a counter-offer by the hacker, a bounty of 45,455 SOL (~$1.4M) was agreed upon, and remaining funds were returned.
## Attack Methodology
- **Initial Access:** Smart contract vulnerability exploitation (Tick account spoofing).
- **Persistence:** Not applicable (Atomic transaction/Flash loan).
- **Privilege Escalation:** Bypassing "owner-check" verification steps to gain write-access to price/fee data.
- **Defense Evasion:** Manipulating internal protocol price oracle data (ticks) to make theft appear as a legitimate fee claim.
- **Discovery:** Identifying that the protocol did not strictly validate the authenticity of the tick account address during fee calculation.
- **Impact:** Protocol insolvency via drainage of liquidity pools.
## Impact Assessment
- **Financial:** Total initial loss of ~$8.7M. Net loss after recovery (bounty payment) was ~$1.1M - $1.4M.
- **Data Breach:** None (non-custodial protocol).
- **Operational:** Full halt of all Crema Finance trading and liquidity services.
- **Reputational:** Significant; necessitated a compensation plan using 1.5% of total CRM token supply (15,000,000 CRM) to restore user trust.
## Indicators of Compromise
- **Behavioral indicators:** Creation of unauthorized tick accounts; highly disproportionate fee-to-liquidity ratios; massive flash loan originating from Solend.
- **Transaction/Address (Defanged):**
- Attacker bridged funds to Ethereum Network.
- Swapped assets via Jupiter Aggregator.
## Response Actions
- **Containment:** Protocol-wide halt of all smart contract operations.
- **Eradication:** Deployment of patches to fix the tick account verification bypass.
- **Recovery:** Negotiation with the attacker to secure a refund; implementation of a CRM-token-based compensation plan for affected users.
## Lessons Learned
- **Bypass Vulnerabilities:** Routine "owner checks" are insufficient if the protocol can be tricked into referencing an entirely different, attacker-controlled account (spoofing).
- **Flash Loan Sensitivity:** Concentrated liquidity models are highly sensitive to sudden capital influxes; fee calculation logic must be hardened against manipulation.
- **Oracle Integrity:** Input data for financial calculations (like ticks) must be rigorously validated against a whitelist or internal registry.
## Recommendations
- **Strict Account Validation:** Implement rigorous checks to ensure tick accounts belong to the legitimate protocol registry before performing fee calculations.
- **Continuous Auditing:** Conduct professional security audits not just at launch, but after every major update or integration.
- **Flash Loan Protections:** Implement "slow-mode" withdrawals or multi-block fee calculations to prevent atomic flash loan exploitation.