SlowMist: دليل تدقيق الأمان AAVE V2

مقدمة

مع النمو السريع لنظام التمويل اللامركزي (DeFi)، يظل AAVE V2، باعتباره أحد بروتوكولات الإقراض اللامركزي الرائدة، في طليعة الصناعة في توفير حلول مبتكرة للإقراض وإدارة السيولة. إن آليتها الفريدة التي لا تعتمد على الثقة واستخدام رأس المال الفعال قد اجتذبت مشاركة عدد كبير من المستخدمين والمؤسسات. ومع ذلك، مع تعميم تطبيقه والتوسع التدريجي في حجم الأموال المعنية، أصبحت أهمية عمليات التدقيق الأمني ​​وتدابير التحكم في المخاطر بارزة بشكل متزايد. سوف يستكشف هذا الدليل بعمق التصميم الأساسي والوظائف الرئيسية ونقاط التدقيق ذات الصلة لبروتوكول AAVE V2. نظرة عامة على خلفية المشروع

AAVE V2 عبارة عن منصة إقراض مفتوحة مبنية على blockchain Ethereum والتي تسمح للمستخدمين بإيداع رموز ERC-20 المختلفة وكسب الفائدة منها، كما تسمح للمستخدمين أيضًا باقتراض الرموز في السوق في شكل مدفوعات فائدة. من خلال تقديم مفهوم "سوق أسعار الفائدة"، يحقق AAVE V2 إدارة لامركزية لمجموعات الأموال وآلية تعديل أسعار الفائدة الآلية. بالإضافة إلى ذلك، يوفر AAVE V2 أيضًا ميزات متقدمة مثل القروض السريعة، والرهن العقاري، ومقايضات الرموز لتلبية الاحتياجات المتنوعة للمستخدمين، مما يعزز مكانته الرائدة في مجال DeFi.

تحليل بنية المشروع

يدور التصميم المعماري الشامل لـ AAVE V2 حول وظائف رئيسية مثل المستخدمين وإدارة تدفق رأس المال وآلية الرهن العقاري وعملية التصفية واستراتيجية سعر الفائدة، بهدف توفير خدمات إقراض لامركزية فعالة وآمنة. فيما يلي تحليل شامل:

عملية تشغيل المستخدم

المستخدم:يمكن للمستخدمين إجراء عمليات مختلفة مثل الودائع والقروض والسداد والسحوبات وتبادل نموذج سعر فائدة القروض والقروض السريعة والائتمان الموثوق. عندما يتفاعل المستخدمون مع البروتوكول، يتم سك أو تدمير aTokens المقابلة تلقائيًا بناءً على عملياتهم، مما يمثل حقوق الإيداع الخاصة بهم في البروتوكول، ويحصلون على عوائد بناءً على استراتيجية سعر الفائدة.

الائتمان المفوض: يمكن للمستخدمين تفويض حدود الائتمان الخاصة بهم إلى مستخدمين آخرين، مما يؤدي إلى توسيع مرونة وسيناريوهات الاستخدام للبروتوكول.

المكونات الأساسية

LendingPool: بصفته الوحدة الأساسية، فهو مسؤول عن معالجة جميع طلبات عمليات المستخدم، بما في ذلك الودائع والاقتراض والسداد وتبادلات نموذج سعر الإقراض والقروض السريعة والتصفية وتحديث أسعار الفائدة والحالة.

مدير الضمانات:إدارة أصول الضمانات لضمان أن سلوك الاقتراض لدى المستخدمين آمن وقابل للسيطرة. عندما تكون الأصول الضمانية غير كافية، سيتم إطلاق عملية التصفية لحماية السيولة الإجمالية للنظام.

المكتبات: تغلف منطق الادخار، ومنطق التحقق، والمنطق الوظيفي العام، مثل حساب عمليات التصفية والإقراض، لتوفير الدعم لـ LendingPool. تحسب GenericLogic حالة المستخدم وتتحقق منها، بما في ذلك تقييم الأصول، وحساب قيمة الضمان، ومعامل الصحة والعمليات الأخرى. يستخدم ReserveLogic لإدارة مجموعة الاحتياطي، وتتبع وتحديث مبلغ الإيداع، ومبلغ الاقتراض، ومعدل الفائدة الحالي لكل أصل.

الديون والرمز المميز

رموز الديون:تُستخدم لتتبع التزامات الاقتراض الخاصة بالمستخدمين، بنسبة 1:1 مع مبلغ الأموال المقترضة. تتمتع رموز الديون بخيارات أسعار فائدة ثابتة ومتغيرة (مثل DebtDAI Stable، وDebtDAI Variable، وما إلى ذلك)، كما أن رموز الديون غير قابلة للتحويل.

aTokens: عندما يودع المستخدمون الأصول، سيتم إنشاء aTokens 1:1 لترسيخ الأصول الأساسية. ستستمر هذه aTokens في الارتفاع لتعكس الفائدة المكتسبة على الودائع. يتم تخزين المبلغ المقدم هنا مع الرصيد الأساسي كنسبة، تسمى الرصيد المدرج (ScB).

الصيغة هي كما يلي:

السعر ومعدل الفائدة

وكيل أوراكل:الاعتماد على أوراكل خارجية (Chainlink) لتوفير بيانات أسعار سوق الأصول، والتي تستخدم لتقييم قيمة أصول الرهن العقاري للمستخدمين وضمان دقة تسعير سلوك الإقراض واستقرار النظام.

معدل الإقراض Oracle: يوفر معدلات إقراض ديناميكية تعتمد على حالة النظام وظروف السوق لتحسين استخدام رأس المال والسيولة.

التكوين والإدارة

المكوِّن:يستخدم لتكوين معلمات النظام، مثل معلمات المخاطر وحدود الإقراض لأصول مختلفة، وإدارة العمليات المختلفة لصندوق الاحتياطي، بما في ذلك التنشيط والاقتراض والرهن العقاري والتجميد وتحديث المعلمات وتمكين أو تعطيل الوظائف في حالات الطوارئ. تأكد من إمكانية تعديل الاتفاقية ديناميكيًا وفقًا لتغيرات السوق.

وظائف رئيسية أخرى

مدير التصفية:عندما تنخفض قيمة الضمان الخاص بالمستخدم إلى ما دون عتبة التصفية، قم بإدارة عمليات التصفية وحماية الأمان المالي للنظام. يمكن للمصفيين الحصول على مكافآت من خلال عمليات التصفية.

أرصدة الاحتياطيات:تخزن بيانات أموال الاحتياطي للنظام، والتي تُستخدم لحساب وتعديل استراتيجيات أسعار الفائدة.

إستراتيجية أسعار الفائدة

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

على الرغم من وجود نموذجين لأسعار الفائدة (المستقرة والمتغيرة)، فإن حسابات النموذج الخاصة بهما تشبه نموذج نقطة الانعطاف. يتم حساب المنحدر1 تحت معدل الاستخدام الأمثل عند نقطة الانعطاف والمنحدر2 الذي يتجاوز معدل الاستخدام الأمثل في أقسام، وتحت هذا الشرط، يتم تقسيمهما أيضًا إلى نموذج معدل الفائدة الثابت ونموذج معدل الفائدة المتغير.

فهم العملية

الصيغة هي كما يلي:

ثم يتم استخدام reserve.updateInterestRates لتعديل سعر فائدة السيولة ومعدل الاقتراض المستقر ومعدل الاقتراض المتغير بشكل ديناميكي وفقًا لأحدث علاقة بين العرض والطلب (يتم حسابها وتحديثها جميعًا بواسطة وظيفة DefaultReserveInterestRateStrategy.calculateInterestRates). في مرحلة نقل الأصول، يقوم النظام بنقل الأصول الأساسية للمستخدم إلى عقد aToken، وفي الوقت نفسه يقوم بسك مبلغ مساوٍ من aToken إلى عنوان onBehalfOf الذي قدمه المستخدم. من بينها، يعتمد aToken آلية التوسع (الرصيد المتدرج) للتعامل مع تراكم الفائدة. إذا كانت هذه هي الإيداع الأول للمستخدم، فسوف يقوم النظام تلقائيًا بوضع علامة على هذا الأصل باعتباره ضمانًا للمستخدم.

مقارنةً بـ Compound، فإن عملية الإيداع في AAVE V2 تتميز بالميزات الرئيسية التالية:

يدعم تحديد عنوان المستلم (onBehalfOf). يتم التحقق من الإيداع من خلال عقد ValidationLogic.

تحديث مؤشر تراكم السيولة ومؤشر الاقتراض المتغير لحساب وتوزيع فائدة الخزانة المتفق عليها.

ضبط أسعار الفائدة الثلاثة للسيولة والاقتراض المستقر والاقتراض المتغير في نفس الوقت.

استخدم آلية التوازن المتدرجة في aToken للتعامل مع الفائدة.

يتم تلقائيًا وضع علامة على الإيداع الأول كضمان.

السحب

يقوم المستخدمون بسحب النقود عن طريق استدعاء وظيفة السحب. أولاً، احصل على بيانات الاحتياطي للأصل المحدد، بما في ذلك عنوان aToken المقابل، وتحقق من رصيد هذا المستخدم في aToken. بعد ذلك، قم باستدعاء وظيفة ValidationLogic.validateWithdraw للتحقق من صحة طلب السحب، بما في ذلك التحقق مما إذا كان مبلغ السحب صالحًا، وما إذا كان رصيد المستخدم كافياً، وما إذا كان الاحتياطي نشطًا، وما إلى ذلك. يتم استخدام GenericLogic.balanceDecreaseAllowed للتحقق من عامل صحة المستخدم وما إذا كان السحب يؤثر على الضمان، وهو ما يشبه وظيفة getHypotheticalAccountLiquidityInternal في Compound. في وظيفة balanceDecreaseAllowed، تحسب الوظيفتان calculateUserAccountData وcalculateHealthFactorFromBalances عتبة التصفية بعد سحب الأموال والتحقق من إجمالي الضمانات الخاصة بالمستخدم، ومبلغ القرض الإجمالي، وعامل الصحة الحالي للمستخدم لتحديد ما إذا كان عامل صحة المستخدم في حالة آمنة ضمن عتبة السيولة.

صيغة حساب HF هي كما يلي:

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

بالمقارنة مع Compound، فإن عملية السحب في AAVE V2 تتميز بالميزات الرئيسية التالية:

يتم استخدام aToken لتمثيل إيداع المستخدم في البروتوكول، والسحب في الواقع يدمر aToken.

يسمح للمستخدمين بالانسحاب إلى عنوان محدد (عبر معلمة to)، مما يزيد من المرونة.

يتم توفير خيارات السحب الجزئي والسحب الكامل. في التحقق من عمليات السحب، يستخدم AAVE وظيفة balanceDecreaseAllowed الأكثر تعقيدًا للتحقق من تأثير عمليات السحب على الحالة الإجمالية للضمانات الخاصة بالمستخدم.

تعمل عملية السحب في AAVE على تحديث سعر الفائدة بشكل مباشر بدلاً من تحديثه من خلال وظيفة accrueInterest مثل Compound.

الاقتراض

يقوم المستخدمون بالاقتراض من خلال وظيفة الاقتراض. عند تنفيذ قرض، سيتم الحصول على السعر الحالي للأصل من أوراكل الأسعار، وسيتم تحويل مبلغ القرض إلى ما يعادله من ETH. بعد ذلك، يتم التحقق من ValidationLogic.validateBorrow ويتم استخدام GenericLogic.calculateUserAccountData للتحقق مما إذا كان اقتراض المستخدم قانونيًا. يتم حساب إجمالي الأصول الضمانية، وإجمالي الدين، ونسبة القرض إلى القيمة الحالية (LTV)، وعتبة التصفية وعامل الصحة، واستقرار السوق لعنوان onBehalfOf (على غرار getHypotheticalAccountLiquidityInternal في Compound)، لمعرفة ما إذا كان هناك أصول ضمانية كافية للاقتراض. يقوم reserve.updateState بتحديث حالة الاحتياطي، مثل سعر الفائدة ومؤشر الاقتراض (هذه الخطوة مشابهة لـ accrueInterest في Compound)، والذي يستخدم لحساب وتحديث الفائدة.

ثم يتم إنشاء الدين على أساس interestRateMode (معدل فائدة ثابت أو معدل فائدة عائم) الذي حدده المستخدم، ويتم تحديد عقود الرمز مع نماذج أسعار الفائدة المختلفة لسك الرموز. في نفس الوقت، سيتم إجراء فحص عند سك الرموز. إذا لم يكن عنوان onBehalfOf هو المتصل، فسيتم خصم تفويض الإقراض للمستخدم المتصل من عقد الرمز. إذا كان هذا هو القرض الأول للمستخدم، فسيتم تكوينه كمقترض نشط. بعد إصدار DebtToken للمستخدم، سيقوم البروتوكول بتحديث سعر الفائدة على الاقتراض من خلال updateInterestRates ليعكس سعر الفائدة الجديد بعد الاقتراض والتغييرات في مجموعة الاحتياطي. إذا طلب المستخدم تحرير الأصول الأساسية للقرض، فسوف يقوم البروتوكول بنقل الأصول مباشرة إلى المستخدم.

مقارنةً بـ Compound، فإن عملية الإقراض في AAVE V2 تتميز بالميزات الرئيسية التالية:

يدعم كل من أوضاع أسعار الفائدة المستقرة والمتغيرة.

استخدم عقد منطق التحقق المنفصل للتحقق من القرض.

استخدم DebtToken لتمثيل اقتراض المستخدم.

يدعم تفويض الائتمان، مما يسمح للمستخدمين بالاقتراض نيابة عن عناوين أخرى.

السداد

يقوم المستخدمون بالسداد من خلال وظيفة السداد، حيث يحصلون أولاً على دين المستخدم الحالي (بما في ذلك الدين المستقر stableDebt والديون العائمة variableDebt). بناءً على وضع سعر الفائدة (مستقر أو عائم) الذي حدده المستخدم، يتحقق ValidationLogic.validateRepay من شرعية عملية سداد المستخدم، بما في ذلك ما إذا كان رصيد دين المستخدم كافياً للسداد. يتم تحديد نوع الدين المحدد الذي يجب سداده من خلال نموذج سعر الفائدة الذي يختاره المستخدم (معدل ثابت أو معدل متغير). إذا كان المبلغ الذي يريد المستخدم سداده أقل من رصيد الدين الحالي، فسيستخدم النظام مبلغ السداد الذي قدمه المستخدم لإجراء سداد جزئي؛ وإلا، فسيتم سداد الدين بالكامل. تحديث حالة الاحتياطي updateState، الذي يستخدم لحساب وتحديث الفائدة ومبلغ القرض ومؤشر القرض في البروتوكول. يتم بعد ذلك حرق رموز الديون المستقرة المقابلة ويتم تحديث سعر الفائدة على الاقتراض عبر updateInterestRates. في هذه المرحلة، إذا كانت جميع ديون المستخدم (بما في ذلك الديون المستقرة والمتغيرة) صفرًا بعد السداد، فسيتم وضع علامة على حالة اقتراض المستخدم على أنها خاطئة، مما يشير إلى أن المستخدم لم يعد يقترض. وأخيرًا، يقوم المستخدم بتحويل مبلغ السداد من حسابه إلى عنوان عقد aToken الخاص بالبروتوكول.

مقارنةً بـ Compound، تتميز عملية سداد AAVE V2 بالميزات الرئيسية التالية:

يدعم السداد في وضعي أسعار الفائدة المستقرة والمتغيرة. استخدم DebtToken لتمثيل الديون وإدارتها، ثم أحرق رمز الدين المقابل عند السداد.

يدعم السداد الجزئي والسداد الكامل، ويتعامل مع الديون المستقرة والديون العائمة بشكل منفصل.

دعم المستخدمين لسداد العناوين الأخرى من خلال تفويض الائتمان.

التصفية

يقوم المستخدمون بالتصفية من خلال وظيفة liquidationCall في lendingpool. تستدعي الوظيفة وظيفة liquidationCall في LendingPoolCollateralManager في وضع الوكيل لضمان التنفيذ الناجح للوظيفة. أولاً، يحصل GenericLogic.calculateUserAccountData على بيانات الاحتياطي للأصول الضمانية وأصول الدين ومعلومات تكوين المستخدم، ويحسب عامل صحة المستخدم، ويحصل على الالتزامات الحالية المستقرة والمتغيرة للمستخدم من خلال getUserCurrentDebt. تتحقق وظيفة ValidationLogic.validateLiquidationCall من شرعية استدعاء التصفية، بما في ذلك التحقق من عامل صحة المستخدم وحالة الدين وتكوين الضمان. إذا كان عامل الصحة أقل من الحد الأدنى، وتم استخدامه كضمان، وكلا الديون ليست 0، يتم اجتياز التحقق. بعد ذلك، يتم حساب الحد الأقصى للديون القابلة للتصفية للمستخدم وتحديد المبلغ الفعلي للديون التي تحتاج إلى تصفية. إذا تجاوز الدين المُصفى الضمانات المتاحة للمستخدم، فسيتم تعديل مبلغ التصفية.

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

مقارنةً بـ Compound، تتميز عملية تصفية AAVE V2 بالميزات الرئيسية التالية:

تدعم التصفية المشتركة للأصول المتعددة الضمانية والديون.

يُسمح للمصفيين باختيار تلقي الرموز المميزة أو الأصول الأساسية.

إن عملية التصفية أكثر تكاملاً، حيث يتم فصل منطق التحقق، ومنطق الحساب، وما إلى ذلك إلى وظائف مختلفة.

يدعم تصفية نوعين من الديون: الديون ذات معدل الفائدة المستقر والديون ذات معدل الفائدة المتغير.

القرض السريع

يمكن للمستخدمين الحصول على قروض سريعة من خلال وظيفة القرض السريع في موقع lendingpool. كقرض سريع في بروتوكول الإقراض، يمكنك السماح بسداد القرض السريع الحالي على الفور أو كدين للسداد اللاحق، والذي يتم تحديده من خلال معلمات الأوضاع المختلفة التي تم تمريرها. 0 يعني السداد الفوري، و1 يعني الدين المستقر، و2 يعني الدين المتغير.

تتحقق الوظيفة أولاً من مطابقة معلمات الإدخال من خلال ValidationLogic.validateFlashloan، وتحسب تكلفة القسط المطلوبة للقرض السريع، وتنقل aToken المطلوب مباشرة إلى عنوان المستلم. قم باستدعاء عملية executeOperation الخاصة بالمستقبل لتنفيذ قرض الفلاش المحدد مسبقًا. تتضمن عمليات القروض السريعة التي تنفذها AAVE بالفعل عمليات التبادل وتصفية التبادل وسداد التبادل. بعد أن يقوم executeOperation بإكمال العمليات المذكورة أعلاه، فإنه يسجل مبلغ القرض الفوري الذي يجب سداده والرسوم المقابلة. إذا اختار المستخدم إعادة الأموال في وضع غير مدين: يقوم النظام بتحديث حالة الاحتياطي، ويجمع السيولة الاحتياطية، ويقوم بتحديث مؤشر السيولة. وأخيرًا، يتم تحويل الأموال والرسوم من مقدم الطلب إلى صندوق الاحتياطي. إذا اختار المستخدم المعالجة في وضع الدين، فسيتم استدعاء _executeBorrow لفتح موقف الدين المقابل.

تبديل وضع الديون

في AAVE V2، يمكن للمستخدمين التبديل بين وضع السعر المستقر ووضع السعر العائم من خلال وظيفة swapBorrowRateMode. أولاً، احصل على ديون المستخدم الحالية ذات معدل الفائدة المستقر والديون ذات معدل الفائدة المتغير على الأصول المستهدفة من خلال وظيفة getUserCurrentDebt لتحديد حالة ديون المستخدم. ثم قم باستدعاء الدالة ValidationLogic.validateSwapRateMode للتحقق مما إذا كانت عملية التبديل قانونية أم لا. يتم التحقق مما إذا كان لدى المستخدم ديون مستقرة أو متغيرة كافية لدعم تبديل الوضع، مما يضمن أن يكون الوضع المستهدف متوافقًا مع تكوين الأصول وحالة ديون المستخدم. اتصل بـ reserve.updateState لتحديث حالة احتياطي الأصول للتأكد من أن بيانات الاحتياطي محدثة. الخطوة التالية هي تحويل رمزي الدين إلى بعضهما البعض، عن طريق حرق رموز الدين المستقرة لإنتاج رموز الدين العائمة أو حرق رموز الدين العائمة لإنتاج رموز الدين المستقرة. بعد اكتمال التحويل، يقوم reserve.updateInterestRates بتحديث سعر الفائدة للأصول المستهدفة للتأكد من أنه يعكس الحالة الحالية للسوق والتغييرات في ديون المستخدم.

قائمة التحقق من الثغرات الأمنية

تقريب الثغرات الأمنية الناجمة عن الأسواق الفارغة

في كل من AAVE وCompound، توجد ثغرات أمنية ناجمة عن فقدان الدقة في الأسواق الفارغة. إذا كان هناك سوق فارغ (أي لا يوجد مستخدمون يقترضون أو يقرضون في السوق)، نظرًا لأن قيمة liquidityIndex في دالة cumulateToLiquidityIndex تعتمد على عدد رموز الأصول الأساسية المقابلة للعقد، يمكن للمهاجم التلاعب بسعر aToken عن طريق إيداع كمية كبيرة من رموز الأصول الأساسية في العقد من خلال القروض السريعة.

على غرار الاختراق الأول لمشروع شوكة Compound Hundred Finance، في حادثة HopeLend، قام المهاجم أولاً بالتلاعب بـ liquidityIndex للتحكم في قيمة hETHWBTC إلى WBTC إلى 1:1، ثم زاد من قيمة liquidityIndex عن طريق تبادل الأصول الأساسية والاقتراض. يتم بعد ذلك استدعاء الدالة _handleFlashLoanRepayment بشكل مستمر من خلال حلقة من القروض السريعة. في وظيفة cumulateToLiquidityIndex، سيؤدي فقدان دقة rayDiv إلى تضخيم قيمة reserve.liquidityIndex بشكل أكبر، وفي النهاية تضخيم كمية WBTC التي يمكن استردادها. (معاملة الهجوم: https://etherscan.io/tx/0x1a7ee0a7efc70ed7429edef069a1dd001fbff378748d91f17ab1876dc6d10392) نقاط التدقيق: أثناء التدقيق، من الضروري الانتباه إلى ما إذا كانت طريقة حساب سعر الصرف سهلة التلاعب وما إذا كانت طريقة التقريب مناسبة. في الوقت نفسه، يمكن اقتراح أن يقوم فريق المشروع بسك العملة الرمزية فور إنشاء السوق الجديد لمنع إفراغ السوق والتلاعب بها.

ثغرة إعادة الدخول الناجمة عن رموز ERC677 / ERC777

على غرار الاختراق الثاني لمشروع فرع Compound الذي يحمل اسم Hundred Finance، في هجوم Agave، استدعى المهاجم وظيفة liquidateCall لتصفية نفسه دون أي التزامات. الرمز الذي تم تصفيته هو الرمز القياسي ERC-677 المستخدم في سلسلة Gnosis. عند نقل هذا النوع من الرموز، سيتم استدعاء وظيفة عنوان الاستلام خارجيًا، لذلك يستدعي عقد التصفية عقد الهجوم. أثناء هذه العملية، أودع عقد الهجوم 2728 WETH تم الحصول عليها من خلال قروض سريعة، وسك 2728 aWETH، واستخدم هذا كضمان لاقتراض جميع الأصول المتاحة في مشروع Agave. بعد انتهاء المكالمة الخارجية، قامت وظيفة liquidationCall بتصفية مبلغ 2728 aWETH الذي تم إيداعه مسبقًا بواسطة المهاجم ونقله إلى المُصفي.

خطر التلاعب بالأسعار الناجم عن آلية أوراكل غير مناسبة

في عملية اختراق مشروع Blizz Finance، وبسبب الانخفاض المستمر في سعر LUNA في ذلك الوقت، أصبحت معلومات سعر Chainlink التي يستخدمها البروتوكول غير دقيقة، مما أدى إلى القدرة على اقتراض الأموال بضمانات LUNA باهظة الثمن. وفي الوقت نفسه، لم يكن المشروع يحتوي على آليات أمان قائمة، ورغم أنه يبدو أن التحذيرات صدرت مسبقًا، إلا أنه لم يتم وضع أي تدابير وقائية في الوقت المناسب لمنع الخسائر. عندما انخفض السعر إلى ما دون هذا المستوى، سمح ذلك لأي شخص بشراء كمية كبيرة من LUNA بسعر السوق (أقل بكثير من 0.10 دولار) واستخدامها كضمان (بقيمة 0.10 دولار) لاقتراض الأموال من المنصة.

(مصدر المرجع: https://x.com/BlizzFinance/status/1524911400992243761)

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

مشاكل غير متوقعة تنتج عن المكالمات الخارجية إلى العقود الطرفية

في التفاعل بين بروتوكول AAVE وبروتوكول Para Swap، فإن وظيفة _buyOnParaSwap لعقد Aave Collateral Repay Adapter V3 تنطوي على مخاطر أمنية متعددة. تحدد هذه الوظيفة حد assetToSwapFrom إلى maxAmountToSwap على tokenTransferProxy عن طريق استدعاء طريقة safeApprove، لكنها لا تأخذ في الاعتبار الموقف الذي لا يتم فيه إجراء أي تبادل أو تبادل جزئي، مما يؤدي إلى بقاء المبلغ المتبقي دون تغيير عندما لا يتم استخدام الحد بالكامل. بالإضافة إلى ذلك، تعتمد الوظيفة على استدعاء عقد خارجي (augustus.call(buyCalldata)) لإجراء التبادل، ولا تقوم بالتحقق الكامل من معلمة paraswapData وتقييدها، مما يسمح للمهاجمين بالتلاعب بـ buyCalldata المشفر وعنوان عقد augustus من خلال paraswapData المصممة بشكل ضار، وتجاوز منطق التبادل المقصود أو تجنب التبادل تمامًا. نظرًا لأن الوظيفة لا تقلل أو تتحقق من حد الرمز المميز لـ assetToSwapFrom بعد المبادلة، حتى إذا فشلت المبادلة أو تم تجاوزها، فلا يزال بإمكان المهاجم استخدام الحد الأقصى غير المتغير لسحب الرموز المميزة من العقد، وبالتالي تحقيق تحويل أموال غير مصرح به. إن عدم التحقق من صحة بيانات الإدخال ونتائج التبادل، فضلاً عن الفشل في إدارة حدود الرمز بشكل فعال، أدى إلى استغلال العقد من قبل المهاجمين.

(معاملة الهجوم: https://etherscan.io/tx/0xc27c3ec61c61309c9af35af062a834e0d6914f9352113617400577c0f2b0e9de)

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

مشكلات توافق استراتيجية الرمز ومعدل الفائدة

أثناء نشر AAVE على سلسلة Polygon، تسبب عدم توافق إعدادات InterestRateStrategy في حدوث خلل وظيفي وتم تعيين استراتيجية سعر فائدة غير متوافقة عن طريق الخطأ لـ WETH.

الواجهة في عقد الفائدة غير الصحيح هي كما يلي:

بسبب عدم توافق الواجهة ، لا يمكن استدعاء الاهتمام الجديد بشكل طبيعي عن طريق LendingPool ، مما يؤدي مباشرة إلى AAV تمت مقاطعة وظيفة تجمع WETH ولم يتمكن المستخدمون من إيداع أو سحب ETH. نقاط التدقيق: أثناء التدقيق، من الضروري التأكد من أن واجهات المكونات الرئيسية في الكود (أو الشوكة) متوافقة تمامًا. وفي الوقت نفسه، على الرغم من أن المشكلات المذكورة أعلاه ليست ناجمة عن خصائص السلاسل المتعددة، فمن الضروري الانتباه إلى ما إذا كانت خصائص السلاسل المختلفة ستتسبب في نتائج غير متوقعة أثناء التدقيق.

مشكلة رمز الغبار

يتم تنفيذ عمليات الإيداع والسحب في AAVE من خلال تعيين usingAsCollateral في وظيفة setUsingAsCollateral، وذلك لإدارة استراتيجية الضمان بمرونة. عندما يقوم بروتوكول أو عقد خارجي باقتراض أموال لأول مرة من خلال وظيفة الاقتراض AAVE، تقوم وظيفة الاقتراض بتعيين usingAsCollateral إلى true. عندما يقوم بروتوكول أو عقد خارجي بسحب الأموال بالكامل من AAVE، سيتم تعيين حالة usingAsCollateral لمعالج البروتوكول في AAVE على false. ولكن في الواقع، عندما تحسب AAVE عدد aTokens التي يجب حرقها للسحب، قد يكون هناك عدد قليل جدًا من aTokens المتبقية في معالج البروتوكول بسبب أخطاء الدقة الحسابية. لذلك، في المرة التالية التي يقوم فيها معالج البروتوكول بإيداع AAVE، لن يتغير usingAsCollateral وسيظل مضبوطًا على true. نظرًا لعدم وجود واجهة في عقد معالج البروتوكول لاستدعاء دالة setUserUseReserveAsCollateral، فقد يتسبب هذا في عدم تمكن معالج البروتوكول من إجراء عمليات الاقتراض. نقاط التدقيق: أثناء التدقيق، يجب أن تكون على دراية كاملة بالبروتوكول المطلوب وفهم خصائصه بالكامل لتحديد ما إذا كانت هناك مشكلات توافق معينة في تفاعله مع البروتوكولات الخارجية، مثل توافق الرمز، وتوافق منطق تنفيذ المكالمة، وما إلى ذلك.

أخيرًا

يستكشف هذا الدليل التصميم الأساسي والوظائف الرئيسية ونقاط التدقيق ذات الصلة لبروتوكول AAVE V2 بعمق. نأمل أن يساعد هذا الدليل المطورين والباحثين الأمنيين بشكل أفضل في تحديد المخاطر المحتملة وضمان التشغيل الآمن للبروتوكول. نظرًا لقيود المساحة، تغفل هذه المقالة بعض التعليمات البرمجية والصور. يمكن للقراء النقر على "قراءة النص الأصلي" في نهاية المقالة للانتقال إلى GitHub لقراءة النسخة الكاملة (https://github.com/slowmist/AAVE-V2-Security-Audit-Checklist).