Paraluni Exploit— March 13th 2022 —Detailed Analysis Report

Overview

On March 13, 2022, Paraluni’s MasterChef contract, built on the Binance Smart Chain, fell victim to an attack. The attacker capitalized on a re-entrancy vulnerability within the project’s smart contract, resulting in the theft of approximately $1.7 million through a series of transactions.

About Paraluni

Paraluni is a well-known Metaverse project developed on the Binance Smart Chain (BSC). The platform enables users to provide liquidity in order to earn yields. The Total Value Locked in Paraluni at the time of writing is $469,836.

Root Cause of the Hack

The vulnerability exploited in the Paraluni hack stemmed from a reentrancy vulnerability found within the contract’s depositByAddLiquidity function. By utilizing a custom-crafted contract featuring a malicious transferFrom function, the attacker managed to exploit this vulnerability effectively.

Below are the relevant addresses associated with this incident:

Attacker address:
https://bscscan.com/address/0x94bc1d555e63eea23fe7fdbf937ef3f9ac5fcf8f

Attack transaction:
https://bscscan.com/tx/0x70f367b9420ac2654a5223cc311c7f9c361736a39fd4e7dff9ed1b85bab7ad54

Attack contract:
https://bscscan.com/address/0x4770b5cb9d51ecb7ad5b14f0d4f2cee8e5563645

UBT (Ukraine bad token) token contract:
https://bscscan.com/address/0xca2ca459ec6e4f58ad88aeb7285d2e41747b9134

UGT (Russia good token) token contract:
https://bscscan.com/address/0xbc5db89ce5ab8035a71c6cd1cd0f0721ad28b508

Masterchef (Victim) contract:
https://bscscan.com/address/0xa386f30853a7eb7e6a25ec8389337a5c6973421d

Detailed Technical Analysis

The breach was facilitated by a reentrancy bug, caused by the incorporation of a specifically crafted token contract, within the depositByAddLiquidity() function. This flaw allowed the hacker to double the credits they could claim, as illustrated in the image below:

Preparation Steps:

1. The attacker initially developed ERC20 token contracts named UBT and UGT, each with an altered transferFrom function. Within the UBT token contract, there are two dangerous external calls:

• The transferFrom() function has a call to the MasterChef’s deposit() function to deposit LP tokens.
• There is also a withdrawAsset() function that triggers the MasterChef’s withdraw() function to withdraw the deposited LP tokens.

2. Next, the attacker took approximately 157,000 USDT and 157,000 BUSD from PancakeSwap via a flash loan.

3. Following that, the attacker contributed liquidity to the ParaRouter contract and generated 155,000 Paraluni LP tokens through the UBT contract.

Exploitation Steps:

Then, the depositByAddLiquidity function invokes an internal depositByAddLiquidityInternal() function, which transfers the attacker’s deposit into the relevant pool. Yet, the pool ID value (_pid) utilized to locate the appropriate pool was not internally validated.

Here’s an explanation of how the attacker exploited the vulnerability:

Attacker-Controlled Contract: The attacker directed the deposit to an attacker-controlled contract. This contract contains a malicious transferFrom function. The input parameters “_pid” is set to 18, and “_tokens” are [UGT, UBT], both of which were created during the preparation stage.

Malicious transferFrom: When the transferFrom function is called, it takes advantage of the re-entrancy vulnerability. It quickly calls back the Masterchef’s deposit to deposit 155,935 LP tokens to the contract before the internal state is updated.

Re-entrancy Exploitation: Here’s where the magic (or rather, the exploit) happens. The attacker’s contract is credited with excess tokens between the initial deposit and the malicious transferFrom call. In this scenario, 155,935 LP tokens are deposited twice, resulting in the attacker having two separate “userInfo” records—one from UBT and the other from the attacker’s address.

Extracting More Value: Due to this excess token credit, the attacker can now withdraw more value from the contract than they initially deposited.

In simpler terms, the attacker tricked the contract into thinking they had more tokens than they did, allowing them to withdraw more funds than they had put in. This was possible because of the flaw in the contract’s logic that didn’t properly handle the validation of pool IDs, leading to a classic case of re-entrancy.

Eventually, the attacker withdrew the liquidity, repaid the flash loans, and obtained 310,000 USDT and 310,000 BUSD.

Fund Flow

After the event, the exploiter converted BNB to ETH. Following this, the attacker cross-chained ETH from BSC to Ethereum and then proceeded to deposit 660 ETH into Tornado over the course of 12 instalments.

Hack Aftermath

After the incident, the Paraluni team communicated with the hacker on-chain, as evidenced by some of the captured conversations.

Paraluni made a public declaration that they would consider this exploit as a white-hat hack and extended an offer of a reward to the attacker for discovering it, contingent upon the return of the stolen funds. Unfortunately, their efforts were unsuccessful as there was no response from the attacker.

Paraluni Team On Chain Message to the Exploiter:

Paraluni Hacker Response:

Mitigation Steps

• Use the Checks-Effects-Interactions Pattern: This is recommended by Solidity. Using it means validating inputs and conditions first, then performing state changes, and finally interacting with external contracts.
• Implement Reentrancy Guards: Utilize a ReentrancyGuard library, such as the one provided by OpenZeppelin. These libraries add a modifier to functions that ensure they cannot be called recursively.
• Opt for Pull Over Push Payments: In cases where possible, prefer a pull payment mechanism where the recipient withdraws funds rather than the contract pushing funds. This reduces the attack surface for reentrancy.
• Use the “transfer” and “send” Functions Wisely: Be cautious when using the “transfer” and “send” functions for transferring funds. These functions have a gas limit of 2,300 and do not allow for reentrancy.
• Separate State Changes and External Calls: Whenever possible, separate state changes from external calls. Ensure that no state is changed after an external call is made.
• Implement Withdrawal Pattern: Use the Withdrawal pattern for user balances. This pattern involves users withdrawing their funds instead of the contract pushing funds to them. This minimizes the risk of reentrancy.

Conclusion

In summary, the Paraluni hack highlighted the critical need for strong security protocols in smart contracts. The breach, arising from a reentrancy vulnerability, led to a loss of around $1.7 million. The vulnerabilities included the lack of validation for user input (_pid) and the presence of a reentrancy vulnerability. These are widely recognized vulnerabilities that could have been identified and mitigated.

Mitigation steps such as smart contract audits, implementation of reentrancy guards, and adherence to secure coding practices can greatly enhance the security posture of projects. By drawing insights from this incident and implementing proactive measures to mitigate vulnerabilities, projects can enhance their defence against similar attacks in the future, safeguarding both themselves and their users.