SharkTeam: تحليل مبدأ هجوم MIM_SPELL

المصدر: SharkTeam

في 30 يناير 2024، تعرضت MIM_SPELL لهجوم قرض سريع. وبسبب ثغرة أمنية في الحسابات الدقيقة، خسر المشروع 6.5 مليون دولار.

استجاب فريق SharkTeam لهذه الحادثة على الفور بالتحليل الفني، وملخصًا للاحتياطات الأمنية، على أمل أن تتعلم المشاريع اللاحقة من هذا وأن تبني بشكل مشترك خطًا أمنيًا لصناعة blockchain.

1. تحليل معاملات الهجوم

< /p>

0x13AF445F81B0DEcA5dCb2Be6A4C691F545c95912

0xe59b54a9e37ab69f6e9312a9b3f72539ee184e5a

العقد تحت الهجوم:

0x7259e152103756e 16 16A77Ae982353c3751A6a90

معاملة الهجوم:

0x26a83db7e28838dd9fee6fb7314ae58dcc6aee9a20bf224c386ff5e80f7e4cf2

0xdb4616b89ad82062787a4e924d520639791302476484b9a6eca5126 f79 b6d877

عملية الهجوم:

1. اقترض المهاجم (0x87F58580) 300000 رمز MIM من خلال قرض سريع.

2. ثم أرسل رسالة إلى المهاجم أرسل العقد (0x7259e1520) 240.000 رمز MIM للخطوة التالية المتمثلة في سداد قرض المستخدم.

3. ثم يتصل المهاجم (0x87F58580) تقوم وظيفة repayForAll بسداد قروض المستخدمين الآخرين، ثم تستدعي وظيفة السداد لسداد قروض المستخدمين الآخرين من أجل تقليل المتغير المرن إلى 0.

4. بعد تقليل المتغير المرن إلى 0، يقوم المهاجم (0x87F58580) بإنشاء عقد هجوم جديد (0xe59b54a9) ويستدعي بشكل مستمر وظائف الاقتراض والسداد حتى المرونة = 0 والقاعدة = 120080183810681886665215049728.

5. ثم قام المهاجم (0x87F58580) باستدعاء وظيفة الاقتراض ووظيفة السحب لعقد DegenBox لإقراض 5,000,047 MIM الرموز.

6. يقوم المهاجم (0x87F58580) بإرجاع تم استخدام وظيفة القرض لتبادل 4,400,000 رمز MIM إلى 1,807 ETH، وكان الربح من هذه المعاملة حوالي 450 واط.

2. تحليل الثغرات الأمنية

< p>جوهر الهجوم هو أن هناك مشكلة في الدقة عند حساب متغيرات القروض، مما يتسبب في التلاعب بالمتغيرات الرئيسية المرنة والقيم الأساسية وعدم توازن النسب، مما يؤدي إلى مشاكل عند حساب الضمانات ومبالغ القروض، و في النهاية الإفراط في الإقراض لرموز MIM.

تعتمد كل من دالة الاقتراض ووظيفة السداد في العقد المهاجم (0x7259e1520) طريقة التقريب التصاعدي عند حساب المتغيرات المرنة والأساسية.

قام المهاجم (0x87F58580) أولاً بتعيين المتغير المرن والمتغير الأساسي على التوالي عن طريق سداد قروض المستخدمين الآخرين. 0 و 97.

ثم استمر في استدعاء وظيفة الاقتراض والسداد الدالة ومبلغ المعلمة هو 1. عند استدعاء دالة الاقتراض لأول مرة، نظرًا لأن المرونة = 0، سيتم تنفيذ منطق if أعلاه وإعادته إلى وظيفة الإضافة. وينتج عن ذلك المرونة = 1، القاعدة = 98.

ثم يستدعي المهاجم (0x87F58580) دالة الاقتراض ويمرر الرقم 1. وبما أن المرونة = 1، فسيتم تنفيذ المنطق الآخر وتكون قيمة الإرجاع المحسوبة 98. وبهذه الطريقة، عند العودة إلى الإضافة دالة مرنة= 2. المتغير الأساسي هو 196.

ولكن في هذا الوقت يستدعي المهاجم (0x87F58580) دالة السداد ويمرر 1. بما أن المرونة=2، فسيتم تنفيذ المنطق الآخر، و المتغير المرن المحسوب هو في الأصل 1*2 /98 =0، ولكن نظرًا لخطوة التقريب التصاعدي أدناه، فإن قيمة الإرجاع المحسوبة هي 1، لذلك عند العودة إلى الوظيفة الفرعية، يتغير المتغير المرن مرة أخرى إلى 1، والمتغير الأساسي هو 195.

يمكن ملاحظة أنه بعد حلقة الاقتراض والسداد، يظل المتغير المرن دون تغيير ويتضاعف المتغير الأساسي تقريبًا. ومن خلال الاستفادة من هذه الثغرة الأمنية، يقوم المتسللون في كثير من الأحيان بتكرار وظيفة سداد الاقتراض، وأخيراً استدعاء السداد وأخيرًا، المرونة = 0 القاعدة = 120080183810681886665215049728.

عندما تكون النسبة بين المتغيرات المرنة والأساسية بعد في حالة عدم التوازن الشديد، يمكن للمهاجم (0x87F58580) إقراض كمية كبيرة من رموز MIM المميزة عن طريق إضافة القليل من الضمانات لتمرير القيود في معدّل المذيبات.

3. توصيات الأمان

< p>ردًا على هذا الهجوم، يجب علينا اتباع الاحتياطات التالية أثناء عملية التطوير:

1. عند تطوير المنطق المتعلق بالحسابات الدقيقة، فكر بعناية في الدقة والتقريب.

2. قبل أن يصبح المشروع متاحًا عبر الإنترنت، يحتاج فريق تدقيق محترف تابع لجهة خارجية إلى إجراء تدقيق ذكي للعقد.