Analysis of Paralumi attack events
PARALUNI (Parallel Universe) is an anonymous project based on the Binance Smart Chain released by the Parallel Universe Foundation in Singapore. It redefines Defi2.0, with the mission of building a financial and economic system of the Metaverse, and is committed to building , a fair and autonomous Defi ecosystem that even ordinary people can participate in. At the same time, Paraluni also provides open interfaces for major front-end companies that want to build metaverse application scenarios. Anyone can use Paraluni to build their own metaverse economic system.
0x02 Event analysis
Attack information
Attacker wallet address:
https://bscscan.com/address/0x94bC1d555E63eEA23fE7FDbf937ef3f9aC5fcF8F
Main attack contract:
https://bscscan.com/address/0x4770b5cb9d51ecb7ad5b14f0d4f2cee8e5563645
UGT：https://bscscan.com/address/0xbc5db89ce5ab8035a71c6cd1cd0f0721ad28b508
UBT：https://bscscan.com/address/0xca2ca459ec6e4f58ad88aeb7285d2e41747b9134
Official MasterChef Contract：https://bscscan.com/address/0xa386f30853a7eb7e6a25ec8389337a5c6973421d#code
Step 1: The attack contract obtained BTCB and WBNB through flash loan borrowing in PancakeSwap, and then added liquidity to ParaPair to obtain about 31 Para-LPs. (Here, the obtained Para-LP is transferred to the UBT contract deployed by the attacker)
Step 2: The attacker adds liquidity through the official MasterChef contract, adds liquidity funds as the Token contract controlled by the attacker, and then deposits the real LP Token through a controllable Token address, and at the same time, two re-entry deposits of 31 tokens occur.
Step 3: Acquire 31 Para-LPs twice, for a total of 62 Para-LPs.
Step 4: Convert the obtained Para-LP to BTCB and WBNB, and finally repay the flash loan and handling fee. The attacker obtains 318 BNB and 3 BTC in this transaction.
The attackers exploited this attack flow to earn approximately $1.7 million by conducting more than 30 attacks on multiple pools in the official masterchef contract.
0x03 Vulnerability Details
The attacker adds liquid collateral tokens through the depositByAddLiquidity method in the official MasterChef contract. We follow up on this method:
Analyzing this method, the pid=9 passed in by the attacker in the parameter transfer here, the two token addresses are the UGT and UBT addresses controlled by the attacker, and the amount is both 1. The pid of 9 is the BTCB/WBNB pool in the current contract. It is clear from the above code logic that it is not determined whether the pid entered by the user corresponds to the two token addresses, and then the _doTransferIn method is called to transfer money.
Call depositByAddLiquidityInternal method after transfer
This method determines whether the pool has been added to the contract. Here the attacker passes in 9, which is the pool that exists in the contract. If the judgment condition is passed, continue to the addLiquidityInternal method for adding liquidity:
This method will judge the number of LP Tokens in the pool, that is, the LP Token balance after adding liquidity is greater than the balance before adding liquidity. Since the LP Token added by the attacker does not correspond to the pool here, it stands to reason that here The judgment cannot be passed, but when the addLiquidty method is called here to add liquidity, the attacker can control the token address, and the attacker transfers the real LP Token after the flash loan fund exchange to the token address he can control at the beginning of the attack. So here the attacker deposits the real LP Token into the contract deposit through the transferFrom method that he can control.
It can be seen from the final logic of the deposit method that the deposited LP Token is deposited with the caller’s balance, which is the attacker’s UBT contract.
Going back to the addLiquidityInternal method, the conditional judgment of require(vars.newBalance > vars.oldBalance, “B:E”); is passed, and the depositByAddLiquidityInternal method continues to call the _deposit method for the deposit operation. The deposit user here is an attack main contract.
The attacker then used the attacker’s main contract and the UBT contract to take two LP Token funds from the MasterChef contract, respectively.
So far, the contract vulnerability analysis of this attack is finished. The attackers mainly use the contract to not strictly check the Token address, resulting in the security vulnerability caused by the controllable Token contract method used by the project. Similarly, the method involving pledge deposits has not been re-entrant limit.
At present, through the preliminary analysis of the official masterchef contract, other methods of adding liquidity pledge in the contract also have this risk, and the Token passed in by the _doTransferIn method in the contract may also cause serious harm. Since the attacker can control the Token address passed in, So the logic attacker of the safeTransferFrom method here is controllable.
0x03 Summarize
Judging from this attack incident, the ultimate factor for the success of the attack is that Paraluni’s official MasterChef contract does not strictly verify the Token address and does not impose re-entry restrictions on the method of pledge deposits. Of course, the premise is that the Token is not strictly verified. , even if the re-entry restriction is added to this risk, the attacker can still threaten the project through Token control.
0x04 Security advice
• It is recommended to conduct a security audit before the project goes live
• It is recommended to strictly judge the access control problems of contract parameters
• It is recommended that no reentrancy restrictions be placed on methods involving pledged deposits
