Full Report
Osmosis is a very popular blockchain in the Cosmos ecosystem. Levana in a perpetual swap built on Cosmos (CosmWasm?). On December 26th, a large chain congestion occurred via a bad set of configurations. This timing was enough for a hacker to profit though. Levana uses the Pyth oracle to keep prices and things up to date. Usually, this occur on a per block basis but some leeway is allowed depending on the previous price. The market contract allow for a 120 second lag. If the market was highly volatile, this is plenty of attack to exploit the difference in price. This difference in price comes down to a price delta attack. In this, the attacker waits for the difference between the actual price and the marked price to be large enough that an attacker could profit solely from the trade. If the price is up, open a long. If it's short, then a low. Once the update goes through from Pyth, sell to get the profit with no risk. The system had many mitigations in place to prevent hits. First, the updates being so spread apart is just unlikely; normal trading would update the price. Second, there were maintainers with bots who were pushing these updates regularly from Pyth info. Now, the delta attack is simply a limitation of the design. However, the circumstances of the market are what led to this being viable. In particular, Osmosis was experiencing large congestions from insufficient fee errors. This came from the newly added fee mark mechanism. Apparently, at the same time, a DDoS attack was occurring on the Levana platform as well. During this timeframe, the authors launched a bot that was always updating the chain prices. Even with the bot and high gas prices, it was still not high enough to push it through. They also paused all markets. How do we actively mitigate this though? The team assumed that that they could land all on-chain price updates, which ended up not being the case in the high congestion times. So, they've decided to decouple these where there will be placing and execution in separate calls. By doing this, the Python update MUST occur within a given timeframe, or the call will timeout. This prevents the exploit above. Developers make assumptions about how a system runs. In these difficult times, it's important to think of worst case scenarios and extreme edge cases to ensure that the product is completely unhackable. Good read!
Analysis Summary
# Incident Report: Levana Protocol Price Delta Oracle Exploit
## Executive Summary
Between December 13 and December 26, 2023, the Levana Protocol on the Osmosis blockchain was targeted by a sophisticated "price delta" attack. Attackers leveraged extreme network congestion and a DDoS attack to delay Pyth oracle price updates, allowing them to trade against "stale" prices for guaranteed profit. The incident resulted in the extraction of approximately $1.146 million (10% of liquidity pool funds), leading to a temporary halt of market activities and an overhaul of the protocol’s update mechanism.
## Incident Details
- **Discovery Date:** December 26, 2023
- **Incident Date:** December 13, 2023 – December 26, 2023
- **Affected Organization:** Levana Protocol (on Osmosis)
- **Sector:** Decentralized Finance (DeFi) / Blockchain
- **Geography:** Global / Decentralized
## Timeline of Events
### Initial Access
- **Date/Time:** December 13, 2023
- **Vector:** Exploitation of Oracle Price Lag (Design Flaw)
- **Details:** Malicious actors began opening positions using accounts funded via centralized exchanges. They exploited a 120-second "leeway" window in the Pyth oracle price update mechanism.
### Lateral Movement
- **N/A:** As this was a decentralized protocol exploit rather than a traditional network breach, lateral movement was not applicable. The attackers scaled the exploit across multiple asset pools (BTC, ETH, ATOM, TIA).
### Data Exfiltration/Impact
- **Dec 13 - Dec 25:** Attackers drained roughly 4% of total liquidity through consistent, high-probability trades during market volatility.
- **Dec 26:** A surge in Osmosis chain congestion—caused by fee market configuration mismatches and a concurrent DDoS attack on Levana—allowed attackers to drain an additional 5% in a single day.
### Detection & Response
- **Dec 26:** Levana team identified that price staleness was causing unintended drainage of pools.
- **Dec 26:** Automated bots were launched to force price updates, but they failed to land due to high gas prices and chain congestion.
- **Dec 26/27:** All Levana markets were paused to prevent further drainage.
- **Jan 2024:** Developers began implementing a decoupled "place and execute" mechanism to fix the vulnerability.
## Attack Methodology
- **Initial Access:** Price Delta Attack; identifying discrepancies between the off-chain "actual" price and the on-chain "marked" price.
- **Persistence:** Multiple seemingly connected accounts funded via CEXs to bypass individual position limits.
- **Defense Evasion:** Blending malicious trades with "natural" bull market trading activity to avoid early detection.
- **Impact:** Use of network congestion (and an alleged DDoS) to ensure price updates remained stale, providing a "risk-free" window to open and close positions.
## Impact Assessment
- **Financial:** Estimated $1.146M loss (approx. 10% of total liquidity pools).
- **Data Breach:** None; focused on financial theft.
- **Operational:** Market operations halted; modification of positions disabled; emergency node reconfigurations required for validators.
- **Reputational:** High; required the announcement of an LP airdrop and fee redistribution to compensate impacted users.
## Indicators of Compromise
- **Behavioral indicators:**
- High-frequency trades immediately preceding oracle price updates.
- Large positions opened during periods of high "Insufficient Fee" errors on the Osmosis chain.
- Clustering of profitable accounts funded by the same centralized exchanges.
## Response Actions
- **Containment:** Market trading and position modifications were halted to freeze the remaining 90% of liquidity.
- **Eradication:** Synchronized validator fee market configurations to resolve chain congestion.
- **Recovery:** Development of a new market contract where execution and placement are separate calls, requiring a Python update to land within a strict timeframe or timeout.
## Lessons Learned
- **Assumptions are Vulnerabilities:** The team assumed on-chain price updates would always land, failing to account for extreme network congestion or DDoS scenarios.
- **Complexity of L1 Dynamics:** Inter-validator configuration mismatches (fee markets) can create exploit windows for DApps even if the DApp code itself is "bug-free."
- **Oracle Latency:** Any "leeway" or lag permitted in price updates is an attack vector in a high-volatility environment.
## Recommendations
- **Decouple Transactions:** Implement a multi-step trade process (Request -> Oracle Update -> Execution) to ensure trades occur at the most current price.
- **Dynamic Fee Management:** Enhance bot infrastructure to automatically outbid congestion during periods of high volatility.
- **Stress Testing:** Conduct "worst-case" scenario drills specifically focusing on chain-level failures (congestion, consensus lag) rather than just smart contract logic.