الخلفية

في 13 يناير 2025، وفقًا لـ Slow Mist MistEye Security اكتشف نظام المراقبة تعرض UniLend الموجود على سلسلة EVM للهجوم، مما تسبب في خسارة ما يقرب من 197000 دولار أمريكي. قام فريق أمان SlowMist بتحليل الحادثة وشارك النتائج على النحو التالي:

(https://x.com/SlowMist_Team/status/1878651772375572573)

معلومات ذات صلة

عنوان المهاجم: 0x55f5f8058816d5376df310770ca3a2e294089c33

عنوان العقد الضعيف: 0xc86d2555f8c360d3c5e8e4364f42c1f2d169330e

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

قلب الهجوم

جوهر هذا الهجوم هو أنه عندما يقوم العقد باسترداد الأصول، فإنه يستخدم مباشرة رصيد USDC القديم في المجمع لحساب عامل الصحة. يؤدي هذا إلى حساب عامل الصحة أعلى من الوضع الفعلي، مما يجعل النظام يعتقد خطأً أن حالة الإقراض الخاصة بالمستخدم آمنة. واستغل المهاجمون هذه الثغرة الأمنية لاقتراض كمية كبيرة من الأصول من خلال القروض السريعة، وتجاوز التحقق الصحيح من العوامل الصحية عند إيداع الأصول واستردادها، وبالتالي الحصول على الأصول المستهدفة دون المخاطرة الفعلية.

عملية الهجوم

1 الأصول المتقدمة: قام المهاجم بتحميل المعاملة في المقدمة (0xdaf42127499f878b62fc5ba2103135de1c36e1646487cee309c077296814f5ff) تعهد بمبلغ 200 USDC إلى UnilendV2Pool مقدمًا وحصل على USDC LendShare 150,237,398. ثم قام المهاجم بنقل LP Token استعدادًا لاسترداد الأموال لاحقًا.

2. اقتراض الأصول باستخدام القروض السريعة: اقترض المهاجم 60 مليون USDC و5 wstETH من خلال القروض السريعة، وقام بتحويل wstETH إلى 6 stETH.

3. إيداع الأصول للحصول على أسهم القرض: يستدعي المهاجم وظيفة الإقراض مرتين لإيداع USDC وstETH في LP المُعد مسبقًا، وبالتالي الحصول على الأسهم المقابلة. في الوقت الحالي، حصة المهاجم هي:

• USDC Lendshare: 150237398 + 45070847435535 = 45070997672933< /p>

• stETH Lendshare: 6663517741687683225

4. اقتراض الأصل المستهدف: نظرًا لأن المهاجم قام بإيداع مبلغ كبير من USDC مقدمًا، فيمكنه اقتراض 60 stETH بشكل طبيعي عن طريق استدعاء وظيفة الاقتراض. في هذا الوقت، وبسبب الاقتراض، تزيد قيمة stETH BorodShare إلى 60239272000126842038.

5. استرداد stETH المرهونة: يستدعي المهاجم وظيفة الاسترداد الأساسية لاسترداد جميع stETH المرهونة. نظرًا لأن المهاجم لم يقترض USDC مطلقًا، فإن USDC المقترضة هي 0، لذلك يمكن استرداد كل stETH مباشرة، ويعود stETH LendShare إلى الصفر.

6. استرداد USDC المرهون: يستدعي المهاجم وظيفة الاسترداد الأساسية مرة أخرى لاسترداد جميع USDC المرهونة. في وظيفة الاسترداد الأساسية، يتم استدعاء وظيفة _burnLPposition أولاً لتدمير LendShare المطابق لـ USDC. في هذا الوقت، لا يزال هناك 150237398 USDC LendShare. بعد ذلك، يتحقق العقد من عامل الصحة في وظيفة checkHealthFactorLtv1، وأخيرًا ينقل USDC المسترد إلى المستخدم.

من الناحية النظرية، قام المهاجم بالفعل بإقراض جزء من stETH مع USDC المرهون. عندما يريد استرداد كل USDC، يجب ألا يمر فحص عامل الصحة. ومع ذلك، ليس هذا هو الحال، دعونا نتابع وظيفة checkHealthFactorLtv1:

يمكننا أن نجد بسهولة من الشكل أعلاه أن الوظيفة تحصل أولاً على USDC LendBalance وstETH اقتراضBalance من خلال وظائف userBalanceOftoken0 وuserBalanceOftoken1، ثم تحسب عامل صحة USDC وتقارنه بالأمن العتبة لتحديد ما إذا كان استرداد USDC مسموحًا به.

تابع البحث في وظيفة userBalanceOftoken0 للتحقق من:

من الواضح أن هذا هو مفتاح المشكلة. يستخدم العقد بشكل مباشر رصيد USDC الحالي من تجمع وUSDC LendShare لحساب الإقراض. ومع ذلك، يتضمن هذا الرصيد مبلغ USDC الذي يكون المستخدم على استعداد لاسترداده، ولكن USDC LendShare قام بخصم الحصة التي يكون المستخدم على استعداد لاستردادها في وظيفة _burnLPposition السابقة. لذلك، يتغير رصيد الإقراض الخاص بـ USDC من 150237398*(728895404+4829907565)/4175666009 = 200001650 إلى 150237398*(60000728895404+4829907565)/4175666009 = 2158955960717، من الواضح أنه كبير جدًا، مما يتسبب في أن تكون قيمة الإرجاع لعامل الصحة أعلى بكثير من المتوقع، ويمكنه اجتياز التحقق بنجاح.

7. أكمل الهجوم وحقق ربحًا: في النهاية، أعاد المهاجم عملة USDC وwstETH التي اقترضتها قرض فلاش وحقق ربحًا. بسبب الثغرة الأمنية، يمكن للمهاجم الحصول على 60 stEth عن طريق الرهان بـ 200 USDC فقط.

الملخص

يكمن جوهر هذا الهجوم في تستخدم وظيفة الاسترداد الأساسية رصيد الرمز المميز القديم للتجميع لحساب عامل الصحة. في هذا الوقت، لم يتم نقل الرمز المميز للمستخدم خارج التجمع، مما تسبب في أن تكون نتيجة حساب عامل الصحة أعلى من الوضع الفعلي يعتقد النظام خطأً أن حالة استعارة المستخدم آمنة. وبالتالي فإن المهاجم قادر على تجاوز التحقق الصحيح من العوامل الصحية والحصول بشكل غير قانوني على الأصول المستهدفة. يوصي فريق أمان SlowMist بأن تضمن أطراف المشروع تحديثات في الوقت الفعلي لحالة الأصول أثناء عملية حساب عامل الصحة لتجنب المواقف المماثلة.