SharkTeam: Analysis of the principle of MIM_SPELL attack

Source: SharkTeam

On January 30, 2024, MIM_SPELL suffered a flash loan attack. Due to a precision calculation vulnerability, the project lost $6.5 million.

SharkTeam responded to this incident immediately Technical analysis, and a summary of security precautions, hoping that subsequent projects can learn from this and jointly build a security line for the blockchain industry.

1. Attack transaction analysis

Attacker address:

0x87F585809Ce79aE39A5fa0C7C96d0d159eb678C9

Attack contract:

0xe1091d17473b049cccd65c54f71677da85b77a4 5< /p>

0x13AF445F81B0DEcA5dCb2Be6A4C691F545c95912

0xe59b54a9e37ab69f6e9312a9b3f72539ee184e5a

The contract under attack:

0x7259e152103756e 1616A77Ae982353c3751A6a90

Attack transaction:

0x26a83db7e28838dd9fee6fb7314ae58dcc6aee9a20bf224c386ff5e80f7e4cf2

0xdb4616b89ad82062787a4e924d520639791302476484b9a6eca5126f79 b6d877

Attack process:

1. The attacker (0x87F58580) borrowed 300,000 MIM tokens through flash loan.

2. Then send a message to the attacked contract (0x7259e1520 ) sent 240,000 MIM tokens for the next step of repaying the user’s loan.

3. The attacker (0x87F58580) then calls The repayForAll function repays the loans of other users, and then calls the repay function to repay the loans of other users in order to reduce the elastic variable to 0.

4. After the elastic variable is reduced to 0, the attacker (0x87F58580) creates a new attack contract (0xe59b54a9) and continuously calls the borrow and repay functions until elastic = 0 and base = 120080183810681886665215049728.

5. Then the attacker (0x87F58580) called the borrow function and the withdraw function of the DegenBox contract to lend out 5,000,047 MIM tokens .

6. The attacker (0x87F58580) returns the lightning The loan function was used to exchange 4,400,000 MIM tokens into 1,807 ETH. The profit from this transaction was approximately 450W.

2. Vulnerability Analysis

< p>The essence of the attack is that there is an accuracy problem when calculating loan variables, which causes the key variables elastic and base values ​​to be manipulated and the proportions are imbalanced, resulting in problems when calculating collateral and loan amounts, and ultimately excessive lending of MIM tokens.

Both the borrow function and the repay function in the attacked contract (0x7259e1520) adopt an upward rounding method when calculating the elastic and base variables.

The attacker (0x87F58580) first set the elastic variable and base variable to respectively by repaying other users' loans. 0 and 97.

Then continue to call the borrow function and repay function And the parameter amount is all 1. When the borrow function is called for the first time, since elastic=0, the above if logic will be executed and returned to the add function. This results in elastic = 1, base = 98.

The attacker (0x87F58580) then calls the borrow function and passes in 1. Since elastic=1, the else logic will be executed and the calculated return value is 98. In this way, when returning to the add function, elastic= 2. The base variable is 196.

But at this time the attacker (0x87F58580) calls the repay function and passes in 1. Since elastic=2, the else logic will be executed, and the calculated elastic variable is originally 1*2 /98 =0, but due to the upward rounding step below, the calculated return value is 1, so when returning to the sub function, the elastic variable changes back to 1, and the base variable is 195.

It can be seen that after a borrow-repay loop, the elastic variable remains unchanged and the base variable is almost doubled. Taking advantage of this vulnerability, hackers frequently loop the borrow-repay function, and finally call repay again. Finally, elastic=0 base = 120080183810681886665215049728.

When the ratio between elastic and Base variables After a severe imbalance, the attacker (0x87F58580) can lend a large amount of MIM tokens by adding a little collateral to pass the restrictions in the solvent modifier.

3. Security recommendations

< p>In response to this attack, we should follow the following precautions during the development process:

1. When developing precision calculation-related logic, carefully consider precision and rounding.

2. Before the project goes online, a professional third-party audit team needs to conduct a smart contract audit.