Rodeo Finance – Hack Analysis Report (July 11, 2023)

Introduction

Rodeo Finance is a unique addition to the DeFi landscape, operating as the ‘Decentralized Leverage Hub’ on the Arbitrum network. It offers diverse yield-earning opportunities through its innovative model catering to both liquidity providers and leverage farmers.

However, even as it helps users maximize their yield-earning potential, it recently faced a significant challenge ? a hack ? testing the platform’s resilience and security mechanisms.

Hack Impact

The hack that struck Rodeo Finance was a sobering reminder of the risks present in the rapidly expanding DeFi space. It used a sophisticated Price Oracle Manipulation technique, resulting in significant financial loss for the protocol.

The perpetrators exploited this vulnerability, extracting around 479 ETH from the system worth approximately $888,000 and the price of the RDO token dropped from $0.2 to $0.08.

The event has not only led to direct financial damage but has also triggered a comprehensive review of the platform’s security mechanisms to prevent similar occurrences in the future.

Understanding Leveraged Yield Farming

For those readers who are more interested in the technical aspects of the hack, feel free to skip to the following section. However, having a basic understanding of Leveraged Yield Farming will help in fully comprehending the nature of the exploit.

Leveraged Yield Farming is a unique strategy in the DeFi world, allowing users to amplify their potential gains. Here’s a simple analogy to explain it:

Imagine a traditional farm. You have a field where you plant seeds and grow crops. The more seeds you plant, the more crops you’ll harvest. In a similar vein, in DeFi farming, the ‘seeds’ are the digital assets or cryptocurrencies that you put into a protocol, and the ‘crops’ are the yields or returns that you earn.

Now, let’s say you want to grow more crops, but you don’t have enough seeds. In traditional farming, you might borrow seeds to plant. This is the essence of “leveraged” farming ? you are leveraging or borrowing additional assets to maximize your yield.

The “leverage” is the factor by which you multiply your initial assets to increase your position. For instance, if you have $100 and use 2x leverage, you are effectively farming with $200. The profits can be significant, but it’s important to note that the risks are also higher.

In Rodeo’s case, it offered users the ability to borrow up to 10 times their initial assets, a feature that unfortunately became a critical factor in the recent hack.

What are Price Oracles and TWAP?

Before diving into the hack, let’s quickly brush up on two important concepts in DeFi: Price Oracles and Time-Weighted Average Price (TWAP).

Price Oracles

In the context of blockchain and cryptocurrency, an oracle is a bridge that provides data to the blockchain that it can’t access on its own. A price oracle, specifically, is a data feed that provides real-time price information of cryptocurrencies. This information is crucial for many DeFi protocols to function correctly.

Price oracles are often trusted sources for this data, providing up-to-date and accurate market prices. They’re like the price tags in a supermarket, telling DeFi protocols how much a particular crypto asset is worth.

Time-Weighted Average Price (TWAP)

: TWAP is a statistical measure used by trading algorithms to execute bigger orders without disrupting the market. It’s essentially the average price of an asset over a specified time.

TWAP calculates the average price by taking price points at fixed time intervals (e.g., every minute, every 5 minutes, etc.) and then averaging these prices over the course of a trading day.

For example, let’s say you’re tracking the price of a token every hour for 4 hours. If the prices were $2, $4, $6, and $8 respectively, the TWAP would be the average of these: ($2+$4+$6+$8)/4 = $5. This smooths out the price and helps mitigate the impact of price volatility, providing a more stable reference price for traders.

In DeFi protocols like Rodeo, both Price Oracles and TWAP are used to ensure accurate, timely, and fair value calculations for trades and positions. However, as we’ll see in the next section, these mechanisms can be manipulated, leading to significant vulnerabilities.

Understanding Price Oracle Manipulation

Price oracle manipulation is a type of attack that involves an attacker artificially altering the data provided by the oracle, with the aim of profiting from trades based on the manipulated prices. This is sometimes also referred to as an “oracle attack.”

Let’s illustrate this with a simple example. Assume there’s a DeFi protocol that uses a price oracle to get the current price of ETH. Normally, the price of ETH is $2000, and the protocol functions accordingly.

Now, an attacker somehow manipulates the price oracle to report that the price of ETH is $3000 instead. The protocol, trusting the oracle’s data, now acts as if ETH is worth $3000. An attacker could exploit this to trade ETH at this inflated price, making a substantial profit when the actual market price is only $2000.

Understanding the Vulnerability and Root Cause of the Rodeo Finance Hack

The key vulnerability in the Rodeo Finance hack lay in the manipulation of the protocol’s TWAP Oracle. This Oracle was responsible for maintaining an accurate price record for the ETH-unshETH CLP strategy, which hadn’t yet been officially released.

The TWAP (Time-Weighted Average Price) Oracle calculates price by averaging the last four instances of updated price, with each update happening approximately every 45 minutes. In theory, this system should provide an accurate representation of the asset’s price over a given time period.

However, the attacker was able to manipulate the TWAP Oracle by deploying a “sandwich” attack. In the context of DeFi, a sandwich attack involves an attacker initiating a transaction, then closely following it with another transaction that influences the price of the first. This type of attack essentially “sandwiches” the victim’s transaction between two of the attacker’s transactions, hence the name.

In the case of the Rodeo Finance hack, the attacker used this technique to artificially inflate the price reported by the TWAP Oracle. Rodeo Farms, the liquidity provider side of the protocol, then used this manipulated price data for liquidity pool (LP) pricing.

The system’s health check mechanism, which is intended to prevent fraudulent or unhealthy transactions, was also bypassed due to this price manipulation. As a result, the attacker was able to borrow a large amount of funds from the USDC Pool, swap them for an inflated amount of unshETH, and then sell these tokens back to the pool at their true market value, effectively draining the pool of its assets.

It’s important to note that the attacker had control over the strategy that was exploited, which allowed them to bypass the checks in place. This points towards an implementation issue with the protocol’s TWAP Oracle and the way it handled updates and checks, which ultimately led to the attack.

So, to summarize, the root cause of the Rodeo Finance hack was a combination of poorly implemented Oracle price calculations, a successful sandwich attack, and the bypassing of the platform’s internal checks and balances. The attacker was able to exploit these weaknesses to execute large-scale swaps and make a profit from the resulting arbitrage opportunity.

Detailed Analysis of the Attack Steps

The Rodeo Finance hack was a sophisticated operation that exploited several key vulnerabilities in the system. Here’s a detailed step-by-step analysis of the actions the attacker took:

Step 1: Analyzing the Attack Transaction

The process began with the attacker executing a carefully planned transaction. The attacker, leveraging deep understanding of the platform’s architecture and the potential vulnerability in the Time-Weighted Average Price (TWAP) oracle, initiated the exploit.

Step 2: Manipulating the TWAP Oracle

The TWAP Oracle was used to track the price ratio between ETH and unshETH. However, the attacker was able to forcefully swap USDC for unshETH using the earn function linked to an unconfigured strategy address. This manipulation effectively bypassed the slippage control due to the faulty unshETH price oracle. In essence, the earn function was forced to swap from USDC to WETH to unshETH.

Step 3: Calculating TWAP Price

The TWAP price is determined by averaging the last four updated prices, each occurring every 45 minutes. The faulty price oracle, however, returned a manipulated price, which led the smart contracts to assume that the position was healthy. The function related to this operation is:

Step 4: Opening a Leveraged Position

Next, the attacker manipulated the TWAP Oracle by sandwiching the update, subsequently opening a leveraged position by calling the earn function from the Investor contract. They borrowed funds worth $400,000 in USDC. This process involved the following function:

Step 5: Swapping Assets

The attacker then swapped the borrowed assets into the underlying CamelotDEX pool while simultaneously selling their prepared unshETH back to the pool.

Step 6: Bypassing Execution Validation

The contract normally verifies if an operation is valid or not. However, as the attacker controlled this strategy, they easily bypassed this check. This allowed the attacker to exploit the manipulated position by selling the prepared unshETH back to the pool, effectively extracting liquidity from the platform.

Step 7: Bridging the Stolen Funds

Finally, the attacker moved the stolen funds from Arbitrum to Ethereum, swapping 285 ETH for unshETH, and then moved them back to Arbitrum to continue the hack. The stolen funds, worth 150 ETH, were then transferred to Tornado Cash, a privacy-focused Ethereum mixing service. The remaining 371.2 ETH, approximately worth $701,679, is still held at an address controlled by the attacker.

Solution and Mitigation Strategy

Here are some solutions to prevent such exploits in the future:

1. Implementing Robust Oracles:

A significant vulnerability in this attack was the flawed implementation of the price oracle. To prevent such exploits, DeFi protocols need to ensure their price oracles are correctly implemented and robust against manipulation.

The TWAP oracle in this case depended on the reserves of the WETH/unshETH pair, which had low liquidity and therefore, significant price volatility. A reliable oracle should not rely solely on the token pair ratio to calculate the price, especially if the pool has poor liquidity.

Multiple oracles or aggregated price feeds should be used for price queries to guarantee a more accurate reflection of asset prices. By diversifying the sources of pricing information, it will be more challenging for an attacker to manipulate the data.

A possible solution to this would be to use a decentralized oracle like Chainlink, which gathers data from various sources, reducing the chances of a single point of failure.

2. Ensuring Adequate Liquidity:

Ensuring adequate liquidity in any pools that the oracle uses for price determination is crucial. In this case, the poor liquidity of the WETH/unshETH pair allowed the attacker to manipulate the price of unshETH. Providing enough liquidity would make it much harder for an attacker to manipulate prices.

3. Implementing Better Slippage Controls:

The protocol’s slippage controls failed to stop the exploit due to the manipulated TWAP. Improved slippage controls and rigorous checks on transactions can be an effective measure against such manipulation.

4. Regular Audits:

Regular audits of the protocol’s smart contracts by reputable security firms like Immunebytes can help identify and address such vulnerabilities before they can be exploited.

The Arcade Exploit: A Simplified Analogy of the Rodeo Finance Hack

Let’s say you’re at an arcade. There’s a candy machine that gives out candies in exchange for tokens. You put in one token and get one candy.

Step 1: Finding a Faulty Machine (Flawed Price Oracle)

You notice that one of the candy machines is broken. Instead of giving one candy for one token, it gives out ten candies! This faulty candy machine is like the flawed price oracle used by Rodeo Finance.

Step 2: The Sneaky Kid (The Attacker)

A sneaky kid in the arcade, let’s call him Joe, notices the faulty machine too. Joe realizes that if he uses his tokens in this machine, he gets ten times more candy. This is similar to the attacker noticing the flaw in the oracle and manipulating it to get more unshETH tokens.

Step 3: Borrowing Tokens (Opening a Leveraged Position)

Joe doesn’t have enough tokens, so he goes to a friend and borrows some, promising to pay back later. In the actual Rodeo Finance attack, the attacker ‘borrowed’ USDC by opening a leveraged position.

Step 4: Getting More Candies (Arbitrage)

Joe uses the borrowed tokens in the faulty candy machine and gets a lot more candies than he should. He then sells these extra candies to other kids in the arcade. In Rodeo Finance’s case, the attacker exploited the flawed oracle to gain extra unshETH tokens and then sold them for a profit.

Step 5: Escaping with the Profits (Bridging the Stolen Funds)

Finally, Joe, with all the money he made, leaves the arcade before anyone realizes what happened. Similarly, the attacker in Rodeo Finance moved their stolen funds to a different network to avoid being caught.

In this way, the sneaky kid made a lot of money by exploiting a flaw in the system, much like the attacker did in the Rodeo Finance hack.

Transaction Details of the Rodeo Finance Hack

1. Attacker’s Address:

The wallet address of the attacker is known to be: 0x2f3788F239617061c46fC07BD0fcb91faAcE328. This address is the source of the malicious transactions that exploited the vulnerability in the Rodeo Finance smart contract.

2. Victim’s Contract:

The contract that was exploited during the attack is identified by the address: 0xE9544Ee39821F72c4fc87A5588522230e340aa54. This is the contract where the vulnerability existed and allowed the attacker to manipulate the price oracle.

3. Attack Transaction:

The specific transaction that exploited the vulnerability has been identified as: 0x98f1e234faac8b7f7ceaffe4e8e0581038678d95710b646db45ec3de47e6c3af. This transaction marked the beginning of the hack and led to the loss of funds from the Rodeo Finance protocol.

4. Flow of Funds:

After successfully exploiting the vulnerability, the attacker moved the stolen funds from the Arbitrum network to the Ethereum mainnet. They swapped 285 ETH for unshETH and then deposited them to Ankr: ETH2 Staking. An amount of 150 ETH was also moved to Tornado Cash, a service known for offering privacy to Ethereum transactions.

Fund FLow

5. Attacker’s Wallets:

Concluding Remarks and The Importance of Robust Security Measures

In conclusion, the Rodeo Finance attack underscores the importance of ensuring the utmost security in the implementation and operation of DeFi protocols. As we unravel the details of this complex exploit, it becomes evident that the implementation of robust, reliable, and tamper-resistant price oracles is an integral aspect of building secure decentralized finance applications. It is imperative to constantly validate and review the security measures in place, considering the potential vulnerabilities that can be exploited by malicious entities.

However, safeguarding the interests of users does not merely end with the implementation of advanced security features. It involves continuous monitoring, testing, and improvement of the system to ensure its resilience against evolving attack vectors. This highlights the vital role played by smart contract audit firms in maintaining the integrity and safety of the DeFi ecosystem.

In this context, ImmuneBytes emerges as a trusted partner for DeFi protocols. ImmuneBytes is a specialist in smart contract auditing and provides top-notch services to ensure that the smart contracts used by DeFi protocols are secure and free from vulnerabilities. With an experienced team that understands the complexity and novelty of the DeFi space, ImmuneBytes can help prevent exploits like the one we saw at Rodeo Finance, thereby safeguarding both the project and its users from potential threats.