SharkTeam：MIM_SPELL攻撃事件の原理分析

0x13AF445F81B0DEcA5dCb2Be6A4C691F545c95912

0xe59b54a9e37ab69f6e9312a9b3f72539ee184e5a

Attacked Contract:

0x7259e152103756e1616A77Ae982353c3751A6a90

Attacked Transaction:

0x26a83db7e28838dd9fee6fb7314ae58dcc6aee9a20bf224c386ff5e80f7e4cf2

0xdb4616b89ad82062787a4e924d520639791302476484b9a6eca5126f79b6d877

攻撃プロセス:

1.攻撃者(0x87F58580)はライトニングクレジットで30万MIMトークンを借ります。

2. 攻撃されたコントラクト（0x7259e1520）は、次のために240,000のMIMトークンを送られました。MIMトークンが送られました。

3. 攻撃者(0x87F58580)は次にrepayForAll関数を呼び出します。を呼び出して他のユーザーの借入金を返済し、続いてrepay関数を呼び出して他のユーザーの借入金を順番に返済します。20240131184151931image.png">

4.elastic変数が0になった後、攻撃者(0x87F58580)は新しい攻撃契約(0xe59b54a9)を作成し、elastic = 0、base = 120080183810681886665215049728で終了するまで、借用と返済の関数呼び出しを続けます。

5.その後、攻撃者(0x87F58580)はborrow関数とDegenBoxコントラクトのwithdraw関数を呼び出し、500,047 MIMトークンを貸し出しました。

6. 攻撃者 (0x87F58580) はライトニングローン関数を返し、4400000MIMトークンを1807 ETHに変換し、この取引で約450Wの利益を得ます。

2 つの脆弱性分析

この攻撃の本質は、貸し出し変数の計算の精度に問題があり、主要な変数の弾性値と基本値が比例しないように操作され、担保と貸し出し数の計算に問題が生じ、最終的にMIMトークンが過剰に貸し出されるというものでした。

攻撃された契約（0x7259e1520）のborrow関数とrepay関数は、弾性変数と基本変数を計算する際に、どちらも上方四捨五入を使用します。

攻撃者(0x87F58580)は、elastic変数とbase変数をそれぞれ0と97に設定することで、お金を借りた他のユーザーに返済することから始めます。

その後、攻撃者はborrow関数とrepay関数を呼び続け、パラメータの金額は0x87F58580になります。borrow関数の最初の呼び出しでは、elastic = 0なので、上記のifロジックが実行され、add関数に戻ります。この結果、elastic = 1、base = 98となります。

攻撃者(0x87F58580)は再びborrow関数を呼び出し、1を渡します。elastic = 1なので、elseロジックを実行し、戻り値を98と計算します。そのため、add関数に戻ったとき、elastic = 2、base変数は196となります。

しかし、この時点で攻撃者は何をすべきかわかりません。p>

しかし、この時点で攻撃者(0x87F58580)はrepay関数を呼び出し、1を渡します。elastic=2であるため、elseロジックを実行し、計算されたelastic変数は1*2/98=0となるはずでしたが、次の上方四捨五入ステップのため、計算された戻り値が1となり、sub関数に戻ったときにelasticは1*2/98=0となります。

この抜け穴を悪用して、ハッカーは頻繁にborrow-repay関数をループし、最後にもう一度repayを呼び出し、最終的にelastic = 0になります。base = 120080183810681886665215049728.

elastic変数とBase変数の間に深刻な不均衡がある場合、少し担保を追加する攻撃者(0x87F58580)は、solvent修飾子の制約をパスすることができ、その結果、大量のMIMトークンを貸すことができます。

3 つのセキュリティに関する推奨事項

この攻撃に対して、私たちは次のことを行うべきです。

1.精密計算に関連するロジックを開発するときは、精度と丸めを慎重に検討する。

2.プロジェクトが本稼働する前に、スマートコントラクトに関する専門の第三者監査チームによる監査を受ける必要がある。

3.