Hack Analysis

Orion Protocol Hack Analysis

Orion Protocol Hack Analysis

Orion Protocol is a liquidity aggregator that connects to major cryptocurrency exchanges and swap pools, both centralized and decentralized. This allows users to obtain the best price for their trades from a single platform. On February 2, 2023, the Orion Protocol was exploited on both Ethereum and BNB Chain, leading to a loss of approximately $3 million in assets due to a reentrancy vulnerability in one of its core contracts.

Hack Impact

The attackers exploited a reentrancy vulnerability in the Orion Protocol’s core contract, ExchangeWithOrionPool, by constructing a fake token (ATK) with self-destruct capability that led to the transfer() function. They then carried out the attack by depositing 0.5 USDC and using a flash loan of 191,606 USDC to swap through the Orion pool via the path (USDC-ATK-USDT).

Understanding Reentrancy Attack

A reentrancy attack is a type of security vulnerability in a smart contract, where a malicious actor exploits the contract’s logic to repeatedly call a function before the previous function call finishes. This can lead to unintended consequences, such as stealing funds or locking them indefinitely.

Function Explanation: doSwapThroughOrionPool


The purpose of the doSwapThroughOrionPool function is to perform a token swap using the Orion Pool, a decentralized exchange (DEX) that allows users to trade tokens based on the provided swap data.

This function is called by external contracts or users to initiate a token swap. The doSwapThroughOrionPool function takes the following parameters:

user: The address of the user initiating the swap.

to: The recipient address where the swapped tokens will be sent.

swapData: A struct containing the swap data, including path, amount to spend, amount to receive, whether it’s an exact spend or exact receive, and the supporting fee.

Vulnerability: Insufficient Validation of Path Addresses

The primary issue in the doSwapThroughOrionPool function is the insufficient validation of the path addresses provided in the swapData parameter. The function allows a malicious user to provide a path that includes an arbitrary contract address, which can potentially execute unintended actions.

The code snippet below shows where the new path is created, and the addresses in the provided path are copied to the new path:

The function does not validate whether the addresses in the path are legitimate tokens, pools, or factories. An attacker can exploit this vulnerability by including a malicious contract address in the path that manipulates the token transfers or performs other unexpected actions when called within the swap process.

Breaking Down the Attack

Preparation

The attacker creates a malicious token contract (ATK) with a transfer() function that has a callback mechanism. They transfer and authorize the ATK token in preparation for the attack.

Flash loan

The attacker takes a flash loan of 191,606 USDC from a lending platform.

Swap tokens

The attacker calls the doSwapThroughOrionPool() function of the vulnerable smart contract to swap the borrowed 191,606 USDC using the exchange path [USDC, ATK, USDT]. The ATK token is the malicious token created by the attacker, which will be used for the callback.

Trigger callback

As the doSwapThroughOrionPool() function in Orion protocol executes the token swap, it triggers the transfer() function of the malicious ATK token. The transfer() function of the ATK token then calls back the depositAsset() function of the vulnerable smart contract through the callback mechanism.

Exploit reentrancy

Due to the lack of reentrancy protection in the depositAsset() function of Orion protocol, the attacker is able to re-enter the depositAsset() function through the ATK token’s transfer() function during the token swap. As a result, the smart contract records the attacker’s deposit amount as the full flash loan amount of 191,606 USDT, inflating the balance of tokens in the contract.

Price increase

The inflation of the attacker’s deposit amount in the Orion protocol’s smart contract, combined with the token swap, creates an artificial price increase for the USDT tokens. The smart contract calculates the difference in USDT token balance before and after the swap, resulting in the attacker receiving more USDT tokens than they should have.

Withdraw profits

After accumulating a significant deposit amount, the attacker calls the withdrawal function of the vulnerable smart contract to withdraw 5,689,532 USDT, which includes their inflated deposit and the profit from the exploit.

Pay back the flash loan

The attacker pays back the original flash loan amount of 2,853,326 USDT, keeping the remaining profit for themselves.

Convert and transfer profits

The attacker swaps their remaining profit of 2,836,206 USDT for 1,651 WETH and transfers it to their wallet or another platform for further anonymity.the attacker transferred approximately 1100 ETH into Tornado Cash, a privacy-focused protocol, to obfuscate their tracks.
The attacker replicated this attack on the BNB Chain, generating an additional profit of $191,434. Consequently, the total profit amassed from both attacks reached approximately $3 million, with $191,434 earned on the BNB Chain and $2,836,206 on the Ethereum network.

Mitigation Strategies for Reentrancy Attacks

Use reentrancy guards

Implement reentrancy guards in your smart contracts, such as the nonReentrant modifier provided by OpenZeppelin. This will prevent functions from being called multiple times before the original call has completed.

Implement a checks-effects-interactions pattern

Ensure that your smart contract functions follow the checks-effects-interactions pattern, where you first perform checks, then update the contract state, and finally interact with external contracts. This can prevent unexpected state changes during external contract interactions.

Transactions Involved


BNB Chain Details:


Conclusion

Reentrancy attacks are a significant threat to smart contracts. They potentially cause substantial financial losses and damage to the reputation of projects. By understanding the nature of these attacks and implementing the recommended mitigation strategies, developers can significantly reduce the risk of such vulnerabilities in their smart contracts.

It is crucial to follow best practices in smart contract development and stay updated on the latest security techniques. Regular audits, testing, and code reviews are essential to identify potential vulnerabilities and ensure the safety and integrity of your smart contracts.

Finally, to ensure the highest level of security for your smart contracts, consider partnering with professional auditing firms like BlockApex.io. Their expertise in smart contract audits and security assessments can provide invaluable insights and help safeguard your projects from potential threats and vulnerabilities.

Explore further Hack Analysis:

BonqDAO Hack Analysis

DEUS DAO Hack Analysis

Dexible Hack Analysis

SafeMoon Hack Analysis

Gul Hameed

Share
Published by
Gul Hameed

Recent Posts

ADOT Finance Audit Case Study

ADOT Finance integrates a blockchain-based marketplace and bridging system that facilitates the exchange and creation…

2 months ago

UniBtc Hack Analysis

Bedrock is a multi-asset liquidity re-hypothecation protocol that allows the collateralization of assets like wBTC,…

2 months ago

NFT Bears to DeFi Bulls Unpacking Berachain’s POL Mechanism and Potential Pitfalls

What is Berachain? Berachain is a high performance, EVM-identical Layer 1 blockchain leveraging Proof of…

2 months ago

Onyx DAO Hack Analysis

On September 3, 2024, Onyx DAO, a protocol derived from Compound Finance, suffered a severe…

3 months ago

17 Best Crypto Launchpads and IDO Platforms to Watch in 2024

The cryptocurrency world continues to expand rapidly, offering new investment opportunities almost daily. One of…

3 months ago

What is Data Tokenization and Why is it Important?

In today's digital age, where data is the new currency, safeguarding sensitive information has become…

3 months ago

This website uses cookies.