SharkTeam: MIM_SMELL was analyzed by the principle of attack event

Source: Sharkteam

On January 30, 2024, MIM_Spell was attacked by Lightning Loan. Due to accuracy, the project party lost $ 6.5 million.

Sharkteam conducted a technical analysis of the incident as soon as possible and summarized the means of security precautions. I hope that subsequent projects can be regarded as precepts to build a security defense line in the blockchain industry.

1. Attack transaction analysis

Attack address:

0x87F585809CE79AE39A5FA0C7C96D0D159EB678C9

Attack contract:

0xe1091d17473B049CCCD65C54F71677DA85B77A45

0x13AF445F81B0DECA5DCB2BE6C691F545C95912

0xe59b54a9e37ab69F6E9312A9B3F7253EE184E5A

Being attacked contract:

0x7259e152103756e1616a77ae982353C3751A6A90

Attack transaction:

0x26a83db7e288838dd9fee6fb7314AE58DCC6AEE9A20BF224C386FF5E80F7E4CF2

0xdb4616B89AD82062787A4E924D520639791302476484B9A6ECA5126F79B6D8777

Attack process:

1. The attacker (0x87F58580) borrowed 300,000 MIM tokens through Lightning Loan.

2. Then send 2,40,000 MIM tokens to the attacked contract (0x7259E1520) for the next step to repay the borrowing of users.

3. The attacker (0x87F58580) then called the repayFrall function to repay the borrowing of other users, and then called the repay function to repay the borrowing of other users in order. The purpose is to reduce the Elastic variable to 0.

4. After the Elastic variables are reduced to 0, the attacker (0x87F58580) creates a new attack contract (0xe59b54a9) and continuously calls the calls of BORROW and the REPAY function until Elastic = 0, BASE = 1200801838188666666521504972888 End.

5. Subsequent attacker (0x87F58580) calls the Withdraw function of the BORROW function and Degenbox contract borrowed 5000047 MIM tokens.

6. The attacker (0x87F58580) returned the Lightning Loan function and converted 4400,000 MIM tokens to 1807 ETH, and this transaction made a profit of about 450W.

Second, vulnerability analysis

The essence of the attack is that the accuracy of the borrowing variable is calculated, so that the proportion of key variable Elastic and base values is unbalanced, resulting in problems when calculating the number of mortgages and borrowings, and eventually borrowed MIM token.

The BORROW function and the repay function in the attacked contract (0x7259e1520) use the upward method to calculate the two variables of Elastic and Base.

The attacker (0x87F58580) first set the Elastic variables and base variables to 0 and 97 by repaying other user borrowing.

Subsequently, the BORROW function and the repay function are continuously called and the parameter amount is 1. When the BORROW function first calls the BORROW function, the above IF logic will be executed and returned to the ADD function when Elastic = 0.This will cause elastic = 1, base = 98.

The attacker (0x87F58580) then calls the BORROW function and passed into 1. Because Elastic = 1 will execute Else logic, the calculated return value is 98. When returning to the ADD function, elastic = 2, the base variable is 196.

But at this time the attacker (0x87F58580) called the repay function and passed into 1. Since Elastic = 2, the ELSE logic will be executed., Resulting in the calculated return value 1, so that when returning to the SUB function, the Elastic variable change back 1, and the base variable is 195.

It can be seen that after experiencing the BORROW-REPAY loop, the Elastic variables remain unchanged and the base variable is almost doubled. Using this vulnerability, the hacker frequently perform the BORROW-Re guay function loop, and finally call the repay again, and finally make elastic = 0 base =120080183810681886665215049728.

When the proportion between Elastic and Base variables is seriously imbalance, the attacker (0x87F58580) can be added with a little mortgage to borrow a large number of MIM tokens through the restrictions in the Solvent modifier.