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
- ATK Token(Fake): 0x64acd987a8603eeaf1ee8e87addd512908599aec
- Attacker’s 1st Address: 0x3dabf5e36df28f6064a7c5638d0c4e01539e35f1
- Attacker’s 2nd Address: 0x837962b686fd5a407fb4e5f92e8be86a230484bd
- Attacker’s Contract(ETH): 0x5061F7e6dfc1a867D945d0ec39Ea2A33f772380A
- Vulnerable Contract: 0x420a50a62b17c18b36c64478784536ba980feac8
- Attack Txn (ETH): 0xa6f63fcb6bec8818864d96a5b1bb19e8bd85ee37b2cc9
BNB Chain Details:
- ATK Token(Fake): 0xc4da120a4acf413f9af623a2b9e0a9878b6a0afe
- Attacker’s 1st Address: 0x3dabf5e36df28f6064a7c5638d0c4e01539e35f1
- Attacker’s 2nd Address: 0x837962b686fd5a407fb4e5f92e8be86a230484bd
- Attacker’s Contract(BSC): 0x84452042cB7be650BE4eB641025ac3C8A0079b67
- Attack Txn (BSC): 0xfb153c572e304093023b4f9694ef39135b6ed5b251545317
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:
