On January 8, 2025, the Mosca contract on BSC was hacked because of a flaw when updating user’s balance, resulting in a loss of approximately $19,485.
Overview
Attacker address: 0xb7d7240c207e094a9be802c0f370528a9c39fed5
Attacker’s contract: 0x851288dcfb39330291015c82a5a93721cc92507a
Attack transaction: 0x4e5bb7e3f552f5ee6ee97db9a9fcf07287aae9a1974e24999690855741121aff
Vulnerable contract: 0x1962b3356122d6a56f978e112d14f5e23a25037d
Analysis
When users join(), they are added to a rewardQueue. From now, they will gain rewards whenever other users buy() or swap() tokens.
When users decide to leave, exitProgram() is invoked. It loops through rewardQueue, when the user is match, it calls withdrawAll() to transfer all pending rewards to user.
In withdrawAll(), the total reward of user is calculated as:balance = user.balance + user.balanceUSDT + user.balanceUSDC
However, in exitProgram(), only user.balance is set to 0, user.balanceUSDT and user.balanceUSDC still hold values after user exit. The hacked exploited this vulnerability in the hack.
The hacker first join() the protocol and successfully deposits some assets (step 4). Then, they leverage a pool to perform a flash loan (step 15) and create a ‘fake’ buy() operation (step 23) to gain rewards for themselves. Finally, they repeatedly invoke join() and exitProgram() to drain USDC from the contract.
Conclusion
The developers violated the Checks-Effects-Interactions pattern and deployed the Mosca contract only a few days before the hack, which may indicate they are under high time-pressure and the product is lack of testing. To prevent such issues, we strongly recommend implementing robust audit processes from the initial stages of development and throughout the entire lifespan of the project. Regular security audits, code reviews, and vulnerability assessments should be standard practice to identify and address potential risks before they are exploited.