March 14, 2022
Attacked 40 Times and Lost Around $1.7 Million: An analysis of Paraluni’s Exploit
On March 13, 2022, Beosin Eagle Eye reported that the Paraluni contract was hacked with a loss of about $1.7 million. Our security technical team has conducted a relevant analysis of this incident.
Take the first attack transaction 0xd0b4a1d4964cec578516bd3a2fcb6d46cadefe1fea5a2f18eec4c0a496e696f9 as an example:
1. Borrow 224 BSC-USD, 224 BUSD from CakeSwap(0x7EFaEf62) via flash loan.
2. Add liquidity to Para-LP(0x3fD4FbD7) using the borrowed tokens from step 1 and specify the receive address of the obtained 222 liquidity tokens as the UBT(0xcA2ca459) address. This step is to prepare for the subsequent reentrancy.
Figure 1 Initial preparation
3. The attack contract (0x4770b5cb) calls the depositByAddLiquidity function of the ParaProxy contract to add liquidity staking mining, where the pid passed in is 18, corresponding to Para-LP (BSC-USD/BUSD) 0x3fD4FbD7a83062942b6589A2E9e2436dd8e134D4, but token0, token1 passed in are the UGT, UBT addresses, with number of 1e18.
Figure 2 Reentrancy attack
4. The normal logic here should be: add liquidity, and deposit the liquidity tokens into the liquidity staking pool with pid 18, but this function does not check in the code whether the liquidity tokens obtained from added liquidity token0 and token1 are the same as the address of the liquidity tokens corresponding to pid, which leads to the attack. Note that not all liquidity staking pools are with this risk, due to line 2524 of the code, the ticket of the pool needs to be a zero address to pass this check.
However, by controlling the execution logic, the actual logic is: Lines 2505,2506 transfer 1 UGT and 1 UBT tokens specified by the hacker to the ParaProxy contract. Then line 2535 code is used to add liquidity and line 2537 is to check the number of liquidity tokens added.
At this point, vars.oldBalance is the initial number of liquidity tokens. The attacker performs a reentrancy attack during the process of adding liquidity in order to pass the check on line 2537. Since the transferFrom function of the malicious crafted token is called when adding liquidity, the hacker only deposits the liquidity into the ParaProxy contract via the deposit function in the transferFrom function. This is also the reason why the attacking contract specifies the receive address of the liquidity token as the UBT contract in step 2.
During the reentrancy process, the UBT contract deposits 222 genuine LP tokens, which are credited to ParaProxy’s ledger. After the reentrancy is completed, 222 LP tokens are added to the ParaProxy contract address, which the ParaProxy contract treats as LPs added by the attack contract and credits to the ledger. At this point, both the UBT contract and the attack contract have added 222 LPs to their records.
Figure 3 ParaImpl contract-related code
The reentrancy-related process is shown in the following figure:
Figure 4 Attack process
5. The UBT contract and the attack contract each calls the withdraw function to extract 221 LPs (with partial fees) from the ParaProxy contract and aggregate to the attack contract, which removes the LPs from liquidity and obtains the corresponding BSC-USD and BUSD.
6. Return 225 BSC-USD, 225 BUSD from flash loan and send the profited 221 BSC-USD, 225 BUSD to the hacker’s address to complete the whole attack.
In total, around 40 attacks were conducted and the hacker made a total profit of about $1.7 million (665 ETH). The hacker transferred the funds to the Ethereum network via the cross-chain protocol and transferred 660 of the ETH to Tornado.Cash and another 5 ETH to the 0xDd52CE617cAF1b7C8cEaCC111DE2f1c54E20C1b0 address.
The hack made possible mainly due to the logic flaws in the contract code and lack of reentrancy prevention in the key functions for fund operations. It is recommended that contract developers conduct complete testing as well as third-party audits and use ReentrancyGuard contract from the Openzeppelin for reentrancy prevention.
Related Project Secure Score
Guess you like
A brief Analysis of the Li.Finance Attack
March 21, 2022
Beosin Research Series: Are Decentralized Exchanges (DEX) Safe Enough?
March 11, 2022
Beosin’s Analysis of the Arbitrum-based TreasureDAO exploit
March 03, 2022
Beosin: More than 19 typical security incidents Occurred in February 2022
March 01, 2022