Review: Analysis of MOBOX Hacking

Written by: Doris, SlowMist Technology

Background

On March 14, 2024, according to the SlowMist MistEye security monitoring system alert, the decentralized lending protocol MOBOX on the Optimism chain was attacked, resulting in a loss of approximately $750,000. The SlowMist security team analyzed the attack and shared the results as follows:

(https://twitter.com/SlowMist_Team/status/1768167772230713410)

Related Information

Attacker addresses:

0x4e2c6096985e0b2825d06c16f1c8cdc559c1d6f8

0x96f004c81d2c7b907f92c45922d38ab870a53945

Attacked contract address:

0xae7b6514af26bcb2332fea53b8dd57bc13a7838e

Attack transaction:

0x4ec3061724ca9f0b8d400866dd83b92647ad8c943a1c0ae9ae6c9bd1ef789417

Core of the Attack

The core points of this attack mainly include two aspects. First, the attacker exploited a vulnerability in the borrow() function of the contract, where each call to this function would trigger a reward distribution to the referrer address. Since the reward calculation is based on the amount of tokens transferred, the attacker could increase the amount borrowed next time by transferring the rewards back to the attacked contract. Second, each call to the borrow() function would burn a portion of the MO tokens in the pool, thereby continuously raising the price of MO tokens, allowing the attacker to profit by repeatedly borrowing and stacking rewards.

Transaction Analysis

We can see that the entire attack process mainly involved repeatedly calling the vulnerable borrow() function, followed by an immediate call to redeem() for redemption, and then transferring the tokens allocated to the referrer back to the attack contract.

Following the borrow() function for analysis, it can be observed that each call to this function burns a portion of the MO tokens in the pool.

However, the amount of USDT borrowed is calculated based on the price of MO tokens in the pool. As the price of MO tokens continues to rise due to burning, it ultimately allows the attacker to borrow a large amount of USDT with a small number of MO tokens.

Additionally, each borrowing would provide a referral address with a reward, and this function is calculated based on the number of MO tokens passed in.

However, since the referrer address is also controlled by the attacker (0x96f004c81d2c7b907f92c45922d38ab870a53945), the attacker could transfer this portion of the reward back after completing the borrowing operation, thereby stacking the amount borrowed and the referral rewards for the next time.

After the above looping operations, the attacker raised the price of MO tokens, ultimately allowing them to borrow a large amount of USDT from the contract with a very small number of MO tokens and directly exchange all the USDT in the imbalanced pool, profiting and exiting.

Conclusion

The core of this attack lies in the mechanism where the attacker exploits the borrow() function that burns a portion of the tokens in the pool, continuously borrowing assets, raising the price of tokens in the pool, and obtaining referral rewards, then transferring the tokens back and borrowing again, thus continuously stacking rewards and manipulating prices. The SlowMist security team recommends that project parties add lock-up time restrictions in similar functional functions and consider multiple factors when designing the lending price model to prevent similar incidents from occurring again.