تحليل حادثة ثغرة Euler Finance: هجوم القرض الفوري أدى إلى خسائر قدرها 1.97 مليار دولار
في 13 مارس 2023، واجه مشروع Euler Finance حدث أمان كبير. وفقًا لبيانات المراقبة على السلسلة، بسبب وجود ثغرة في فحص السيولة في دالة donateToReserves في Etoken، تعرض المشروع لهجوم القرض الفوري. قام المهاجمون من خلال عمليات متعددة لعملات مختلفة، مما أدى في النهاية إلى خسارة ضخمة تصل إلى 197 مليون دولار، تشمل 6 أنواع من الرموز. حتى الآن، لا تزال هذه الأموال في حساب المهاجم.
تحليل عملية الهجوم
استحوذ المهاجم أولاً على 30000000 Dai من القروض السريعة من منصة اقتراض ما، ثم نشر عقدين: واحد للإقراض والآخر للتصفية.
قام المهاجم بإيداع 20 مليون Dai المستعارة في عقد بروتوكول Euler، وحصل على حوالي 19.5 مليون eDAI.
استغل المهاجم ميزة الرافعة المالية 10 أضعاف من بروتوكول Euler وقام باقتراض 1.956 مليون eDAI و 2 مليون dDAI.
قام المهاجم بسداد جزء من الديون باستخدام 10000000 DAI المتبقية ودمر الكمية المعادلة من dDAI، ثم اقترض مرة أخرى 195600000 eDAI و200000000 dDAI.
الخطوات الأساسية: قام المهاجم باستدعاء دالة donateToReserves، وتبرع بمبلغ يعادل 10 أضعاف الأموال المستردة، وهو 100 مليون eDAI. بعد ذلك، قام المهاجم بتفعيل دالة التسوية، وحصل على 310 مليون dDAI و 250 مليون eDAI.
أخيرًا، قام المهاجم باستخراج 3890 ألف Dai، وأعاد 3000 ألف من القروض السريعة، وحقق في النهاية ربحًا يقارب 887 ألف Dai.
تحليل أسباب الثغرات
تكمن المشكلة الأساسية في هذا الهجوم في دالة donateToReserves. مقارنةً بالوظائف الأساسية الأخرى (مثل دالة mint)، تفتقر دالة donateToReserves إلى خطوة حيوية: checkLiquidity.
وظيفة checkLiquidity هي استدعاء وحدة RiskManager، لفحص المستخدم والتأكد من أن Etoken أكبر من Dtoken، مما يضمن حالة السيولة للمستخدم. في الظروف العادية، يحتاج كل إجراء إلى إجراء هذا الفحص. ومع ذلك، فإن وظيفة donateToReserves تفتقر إلى هذه الخطوة، مما يسمح للمهاجمين بوضع أنفسهم في حالة يمكن تصفيتها، ثم إكمال عملية التصفية.
نصائح أمنية
بالنسبة لمثل هذه الثغرات، نوصي الأطراف المعنية في المشروع بإجراء تدقيق أمني شامل قبل الإطلاق لضمان أمان العقد. بالنسبة لمشاريع الإقراض، يجب أن تركز بشكل خاص على الجوانب التالية:
سلامة آلية سداد الأموال
شمولية اختبار السيولة
أمان عملية تصفية الديون
فقط من خلال إجراء مراجعات أمان صارمة وتقييمات شاملة للمخاطر يمكن تقليل احتمال حدوث أحداث الأمان المماثلة إلى الحد الأدنى، وضمان أمان أموال المشروع والمستخدمين.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 16
أعجبني
16
3
مشاركة
تعليق
0/400
AirdropChaser
· 08-05 08:04
又 خداع الناس لتحقيق الربح 又 خداع الناس لتحقيق الربح 天天被割
شاهد النسخة الأصليةرد0
DefiSecurityGuard
· 08-05 08:04
*sigh* يوم آخر، بروتوكول آخر يتعرض للهجوم بسبب ثغرة donateToReserves الأساسية... لقد توقعت هذا قبل شهر بصراحة. تذكير مهم: ALWAYS sanitize liquidity checks ffs. هذه الأخطاء الهواة تستمر في تكلفة 9 أرقام smh
تعرضت Euler Finance لهجوم القرض الفوري بقيمة 1.97 مليار دولار بسبب ثغرة في دالة donateToReserves
تحليل حادثة ثغرة Euler Finance: هجوم القرض الفوري أدى إلى خسائر قدرها 1.97 مليار دولار
في 13 مارس 2023، واجه مشروع Euler Finance حدث أمان كبير. وفقًا لبيانات المراقبة على السلسلة، بسبب وجود ثغرة في فحص السيولة في دالة donateToReserves في Etoken، تعرض المشروع لهجوم القرض الفوري. قام المهاجمون من خلال عمليات متعددة لعملات مختلفة، مما أدى في النهاية إلى خسارة ضخمة تصل إلى 197 مليون دولار، تشمل 6 أنواع من الرموز. حتى الآن، لا تزال هذه الأموال في حساب المهاجم.
تحليل عملية الهجوم
استحوذ المهاجم أولاً على 30000000 Dai من القروض السريعة من منصة اقتراض ما، ثم نشر عقدين: واحد للإقراض والآخر للتصفية.
قام المهاجم بإيداع 20 مليون Dai المستعارة في عقد بروتوكول Euler، وحصل على حوالي 19.5 مليون eDAI.
استغل المهاجم ميزة الرافعة المالية 10 أضعاف من بروتوكول Euler وقام باقتراض 1.956 مليون eDAI و 2 مليون dDAI.
قام المهاجم بسداد جزء من الديون باستخدام 10000000 DAI المتبقية ودمر الكمية المعادلة من dDAI، ثم اقترض مرة أخرى 195600000 eDAI و200000000 dDAI.
الخطوات الأساسية: قام المهاجم باستدعاء دالة donateToReserves، وتبرع بمبلغ يعادل 10 أضعاف الأموال المستردة، وهو 100 مليون eDAI. بعد ذلك، قام المهاجم بتفعيل دالة التسوية، وحصل على 310 مليون dDAI و 250 مليون eDAI.
أخيرًا، قام المهاجم باستخراج 3890 ألف Dai، وأعاد 3000 ألف من القروض السريعة، وحقق في النهاية ربحًا يقارب 887 ألف Dai.
تحليل أسباب الثغرات
تكمن المشكلة الأساسية في هذا الهجوم في دالة donateToReserves. مقارنةً بالوظائف الأساسية الأخرى (مثل دالة mint)، تفتقر دالة donateToReserves إلى خطوة حيوية: checkLiquidity.
وظيفة checkLiquidity هي استدعاء وحدة RiskManager، لفحص المستخدم والتأكد من أن Etoken أكبر من Dtoken، مما يضمن حالة السيولة للمستخدم. في الظروف العادية، يحتاج كل إجراء إلى إجراء هذا الفحص. ومع ذلك، فإن وظيفة donateToReserves تفتقر إلى هذه الخطوة، مما يسمح للمهاجمين بوضع أنفسهم في حالة يمكن تصفيتها، ثم إكمال عملية التصفية.
نصائح أمنية
بالنسبة لمثل هذه الثغرات، نوصي الأطراف المعنية في المشروع بإجراء تدقيق أمني شامل قبل الإطلاق لضمان أمان العقد. بالنسبة لمشاريع الإقراض، يجب أن تركز بشكل خاص على الجوانب التالية:
فقط من خلال إجراء مراجعات أمان صارمة وتقييمات شاملة للمخاطر يمكن تقليل احتمال حدوث أحداث الأمان المماثلة إلى الحد الأدنى، وضمان أمان أموال المشروع والمستخدمين.