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.