إطلاق Uniswap v4 ووجود مخاطر أمان محتملة في آلية Hook
سيتم إصدار Uniswap v4 قريبًا، وتقدم هذه التحديثات العديد من الميزات الجديدة، بما في ذلك دعم عدد غير محدود من أحواض السيولة لكل زوج تداول، والرسوم الديناميكية، وتصميم أحادي، وتسجيل فوري، وآلية Hook، بالإضافة إلى دعم معيار ERC1155. ومن المتوقع أن يتم إطلاق v4 بعد ترقية إيثريوم كانكون.
في ظل العديد من الابتكارات، فإن آلية Hook تحظى باهتمام كبير بسبب إمكانياتها القوية. فهي تسمح بتنفيذ رمز مخصص في نقاط زمنية محددة خلال دورة حياة مجموعة السيولة، مما يعزز بشكل كبير قابلية توسيع المجموعة ومرونتها.
ومع ذلك، قد تكون آلية Hook أيضًا سلاحًا ذا حدين. على الرغم من أنها قوية ومرنة، إلا أن الاستخدام الآمن لـ Hook يواجه أيضًا تحديات. لا مفر من أن تعقيد Hook يجلب معه نقاط هجوم محتملة جديدة. لذلك، من المهم بشكل خاص تقديم قضايا الأمان والمخاطر المحتملة المرتبطة بآلية Hook بشكل منهجي، حيث سيساعد ذلك في بناء Hook أكثر أمانًا لـ Uniswap v4.
تتناول هذه المقالة مفاهيم آلية Hook في Uniswap v4 وتستعرض المخاطر الأمنية الموجودة فيها.
ميكانيكا Uniswap V4
قبل أن نتعمق في المناقشة، نحتاج إلى فهم أساسي لآلية Uniswap v4. وفقًا للإعلان الرسمي والورقة البيضاء، تعتبر Hook، والهندسة المعمارية الأحادية، والحساب الفوري ثلاث ميزات مهمة لتحقيق برك السيولة المخصصة والتوجيه الفعال عبر عدة برك.
خطاف
يشير Hook إلى العقود التي تعمل في مراحل مختلفة من دورة حياة تجمع السيولة. يأمل فريق Uniswap من خلال إدخال Hook أن يتمكن أي شخص من اتخاذ قرارات متوازنة. يمكن أن تحقق هذه الطريقة دعمًا أصليًا للرسوم الديناميكية، وإضافة أوامر محددة على السلسلة، أو من خلال صانع سوق متوسط مرجح بالوقت (TWAMM) لتوزيع الطلبات الكبيرة.
هناك ثمانية استدعاءات Hook حالياً، مقسمة إلى أربع مجموعات ( تحتوي كل مجموعة على زوج من الاستدعاءات ):
قبل التهيئة/بعد التهيئة
قبل تعديل الموضع/بعد تعديل الموضع
قبل التبادل/بعد التبادل
قبل التبرع/بعد التبرع
! [لماذا يعتبر Hook "سيف ذو حدين" ل Uniswap V4؟] ](https://img-cdn.gateio.im/webp-social/moments-f652bf2a22ca7f28f19b4ce9880d0548.webp)
نمط فردي، محاسبة البرق وآلية القفل
تصميم الهيكل الأحادي ونظام المحاسبة السريعة يهدف إلى تحسين الأداء من خلال خفض التكاليف وضمان الكفاءة. إنه يقدم عقد أحادي جديد، حيث يتم الاحتفاظ بجميع برك السيولة في نفس العقد الذكي. يعتمد هذا التصميم الأحادي على PoolManager لتخزين وإدارة حالة جميع البرك.
تم تقديم النسخة v4 آلية المحاسبة السريعة وآلية القفل. تعمل آلية القفل بالطريقة التالية:
يطلب عقد locker قفل في PoolManager.
يقوم PoolManager بإضافة عنوان عقد الـ locker إلى قائمة lockData، وينادي على رد الاتصال lockAcquired.
يتم تنفيذ منطق عقد الخزانة في رد النداء. قد تؤدي التفاعلات بين عقد الخزانة والمسبح خلال التنفيذ إلى زيادة غير صفرية في العملة. ومع ذلك، يجب تسوية جميع الزيادات لتكون صفرًا عند انتهاء التنفيذ. بالإضافة إلى ذلك، إذا كانت قائمة lockData غير فارغة، يمكن فقط لعقد الخزانة الأخير تنفيذ العمليات.
يقوم PoolManager بالتحقق من حالة صف lockData وزيادة العملة. بعد التحقق، سيقوم PoolManager بحذف عقدة الlocker.
بشكل عام، يمنع آلية القفل الوصول المتزامن ويضمن تسوية جميع المعاملات. تتقدم عقود القفل بطلبات القفل بالترتيب، ثم تنفذ المعاملات من خلال رد الاتصال lockAcquired. قبل وبعد كل عملية في المسبح، سيتم استدعاء رد الاتصال المقابل. أخيرًا، سيتحقق PoolManager من الحالة.
هذه الطريقة تعني أن التعديلات العملية تتعلق بالصافي الداخلي للرصيد ( أي دلتا )، وليس تنفيذ تحويل فوري. ستُسجل أي تعديلات في الرصيد الداخلي للمجمع، بينما يتم تنفيذ التحويل الفعلي عند انتهاء العملية ( أي قفل ). تضمن هذه العملية عدم وجود رموز غير مسددة، مما يحافظ على سلامة الأموال.
نظرًا لوجود آلية القفل، لا يمكن لجميع الحسابات الخارجية (EOA) التفاعل مباشرة مع PoolManager. بدلاً من ذلك، يجب أن يتم أي تفاعل من خلال عقد. يعمل هذا العقد كخزانة وسيطة، ويجب طلب القفل قبل إجراء أي عمليات على البركة.
توجد حالتان رئيسيتان للتفاعل مع العقود:
عقد locker يأتي من مكتبة التعليمات البرمجية الرسمية، أو يتم نشره بواسطة المستخدم. في هذه الحالة، يمكننا اعتبار التفاعل كأنه يتم عبر جهاز توجيه.
تم دمج عقد locker وHook في نفس العقد، أو يتم التحكم فيهما بواسطة كيان طرف ثالث. في هذه الحالة، يمكننا اعتبار التفاعل يتم من خلال Hook. في هذه الحالة، يلعب Hook دور عقد locker ويتولى أيضًا مسؤولية معالجة الاستدعاءات.
! [لماذا يعتبر Hook "سيف ذو حدين" ل Uniswap V4؟] ](https://img-cdn.gateio.im/webp-social/moments-ba4bfa88e0ac0b6246e82ad879361ff3.webp)
نموذج التهديد
قبل مناقشة القضايا الأمنية ذات الصلة، نحتاج إلى تحديد نموذج التهديد. نركز بشكل أساسي على حالتين رئيسيتين:
نموذج التهديد I: هوك نفسه خبيث، ولكن هناك ثغرات.
نموذج التهديد II: هوك نفسه خبيث.
في الجزء التالي، سنناقش القضايا الأمنية المحتملة بناءً على هذين النموذجين للتهديد.
مشكلات الأمان في نموذج التهديد I
نموذج التهديد I يركز على الثغرات المرتبطة بHook نفسه. يفترض هذا النموذج أن المطور وHook الخاص به ليس لديهم نوايا خبيثة. ومع ذلك، يمكن أن تظهر الثغرات المعروفة الموجودة في العقود الذكية أيضًا في Hook.
نحن نختار التركيز على الثغرات المحتملة الفريدة من نوعها في الإصدار v4. في Uniswap v4، يعتبر Hook عقدًا ذكيًا يمكنه تنفيذ منطق مخصص قبل أو بعد العمليات الأساسية على المسبح (، بما في ذلك التهيئة، تعديل الموضع، التبادل، وجمع ). على الرغم من أن Hook من المتوقع أن يحقق واجهة قياسية، إلا أنه يسمح أيضًا بتضمين منطق مخصص. لذلك، ستقتصر نطاق مناقشتنا على المنطق المتعلق بواجهة Hook القياسية. بعد ذلك، سنحاول تحديد مصادر الثغرات المحتملة، على سبيل المثال، كيف يمكن لـ Hook استغلال هذه الدوال القياسية لـ Hook.
على وجه التحديد، سنركز على نوعين من Hook:
النوع الأول من الـ hook، هو حفظ أموال المستخدمين. في هذه الحالة، قد يقوم المهاجمون باستهداف هذا الـ hook لنقل الأموال، مما يؤدي إلى خسارة الأصول.
النوع الثاني من الهوك، يخزن بيانات الحالة الأساسية التي يعتمد عليها المستخدم أو بروتوكولات أخرى. في هذه الحالة، قد يحاول المهاجم تغيير الحالة الأساسية. عندما يستخدم الآخرون أو البروتوكولات حالة خاطئة، قد يسبب ذلك مخاطر محتملة.
بعد البحث المتعمق في مستودع Awesome Uniswap v4 Hooks، اكتشفنا عدة ثغرات خطيرة. تنبع هذه الثغرات بشكل رئيسي من التفاعل بين hook و PoolManager و الأطراف الخارجية الثالثة، ويمكن تصنيفها بشكل أساسي إلى فئتين: مشاكل التحكم في الوصول ومشاكل التحقق من المدخلات.
بشكل عام، وجدنا 22 مشروعًا ذا صلة ( استبعدنا المشاريع التي لا تتعلق بـ Uniswap v4 ). من بين هذه المشاريع، نعتقد أن هناك 8 مشاريع (36% ) تحتوي على ثغرات. من بين هذه المشاريع الثمانية التي تحتوي على ثغرات، يوجد 6 لديها مشاكل في التحكم في الوصول، و2 عرضة للاستدعاءات الخارجية غير الموثوقة.
مشكلة التحكم في الوصول
في هذا الجزء من المناقشة، نركز بشكل رئيسي على المشكلات التي قد تسببها دوال الاستدعاء في v4، بما في ذلك 8 دوال استدعاء hook ودالة lock. يجب أن يتم استدعاء هذه الدوال فقط من قبل PoolManager، ولا يمكن استدعاؤها من قبل عناوين أخرى ( بما في ذلك EOA والعقد ). على سبيل المثال، في حالة توزيع المكافآت بواسطة مفتاح تجمع الأموال، إذا كان يمكن استدعاء الدالة المقابلة من قبل أي حساب، فقد يتم استلام المكافآت بشكل خاطئ.
لذلك، من الضروري أن يكون لدى hook آلية قوية للتحكم في الوصول، خاصةً لأنها يمكن أن تُستدعى من قبل أطراف أخرى بخلاف المسبح نفسه. من خلال الإدارة الصارمة لحقوق الوصول، يمكن لمسبح السيولة أن يقلل بشكل كبير من المخاطر المرتبطة بالتفاعلات غير المصرح بها أو الخبيثة مع hook.
مشكلة التحقق من الإدخال
في Uniswap v4، نظرًا لوجود آلية القفل، يجب على المستخدمين الحصول على قفل من العقد قبل تنفيذ أي عملية في بركة الأموال. وهذا يضمن أن العقد الحالي الذي يشارك في التفاعل هو أحدث عقد قفل.
على الرغم من ذلك، لا يزال هناك سيناريو هجوم محتمل، وهو الاستدعاءات الخارجية غير الموثوقة الناتجة عن عدم التحقق السليم من المدخلات في بعض تنفيذات الـ Hook القابلة للاختراق:
أولاً، لم تتحقق hook من المسبح المالي الذي ينوي المستخدم التفاعل معه. قد يكون هذا مسبحًا ماليًا خبيثًا يحتوي على رموز مزيفة ويقوم بتنفيذ منطق ضار.
ثانياً، بعض دوال الhook الرئيسية تسمح باستدعاءات خارجية عشوائية.
إن الاستدعاءات الخارجية غير الموثوقة خطيرة للغاية، لأنها قد تؤدي إلى أنواع مختلفة من الهجمات، بما في ذلك هجوم إعادة الدخول المعروف لدينا.
لشن هجمات على هذه الهوكات القابلة للاستغلال، يمكن للمهاجمين تسجيل بركة أموال ضارة لرموزهم المزيفة، ثم استدعاء الهوك لتنفيذ عمليات في بركة الأموال. أثناء التفاعل مع بركة الأموال، تقوم منطق الرموز الضارة باختطاف تدفق التحكم لارتكاب أفعال غير جيدة.
تدابير الحماية ضد نموذج التهديد I
لتجنب مثل هذه المشكلات الأمنية المتعلقة بالـ hook، من الضروري تنفيذ التحكم المناسب في الوصول إلى الوظائف الخارجية/العامة الحساسة والتحقق من صحة معلمات الإدخال، مما يضمن التحقق من التفاعلات. بالإضافة إلى ذلك، قد تساعد حماية إعادة الدخول في ضمان عدم تنفيذ الـ hook بشكل متكرر في سير العمل المنطقي القياسي. من خلال تنفيذ تدابير الأمان المناسبة، يمكن لخزانات الأموال تقليل المخاطر المرتبطة بمثل هذه التهديدات.
مشاكل الأمان في نموذج التهديد II
في نموذج التهديد هذا، نفترض أن المطورين وhook الخاص بهم خبيثون. نظرًا لأن النطاق المعني واسع، فإننا نركز فقط على مسائل الأمان المتعلقة بالإصدار v4. لذلك، المفتاح هو ما إذا كانت hook المقدمة قادرة على التعامل مع الأصول المشفرة الخاصة بتحويلات أو تفويضات المستخدم.
نظرًا لأن طريقة الوصول إلى hook تحدد الأذونات التي يمكن منحها لـ hook، فإننا نقسم hook إلى فئتين:
هوك مدارة (Managed Hooks): الهوك ليس نقطة دخول. يجب على المستخدمين التفاعل مع الهوك عبر جهاز التوجيه ( الذي قد توفره Uniswap ).
خطافات مستقلة ( Standalone Hooks ): hook هو نقطة دخول، يسمح للمستخدمين بالتفاعل مباشرة معها.
نوع الاستضافة Hook
في هذه الحالة، تشمل أصول المستخدم المشفرة ( الرموز الأصلية ورموز أخرى ) التي تم تحويلها أو تفويضها إلى router. نظرًا لأن PoolManager نفذ فحص الرصيد، فإنه من الصعب على الهاكرز الخبيثين سرقة هذه الأصول بشكل مباشر. ومع ذلك، لا يزال هناك مجال محتمل للهجمات. على سبيل المثال، قد يتمكن المهاجمون من التلاعب بآلية إدارة الرسوم في الإصدار v4 من خلال hook.
نوع مستقل من الخطاف
عندما يُستخدم Hook كنقطة دخول، تصبح الأمور أكثر تعقيدًا. في هذه الحالة، نظرًا لأن المستخدمين يمكنهم التفاعل مباشرةً مع hook، يحصل hook على مزيد من السلطة. من الناحية النظرية، يمكن أن ينفذ hook أي عملية يريدها من خلال هذا التفاعل.
في الإصدار v4، تعتبر عملية التحقق من منطق الكود أمرًا بالغ الأهمية. تكمن المشكلة الرئيسية في إمكانية التلاعب بمنطق الكود. إذا كان الـ hook قابلاً للتحديث، فهذا يعني أن hook يبدو آمنًا قد يصبح خبيثًا بعد التحديث، مما يشكل خطرًا كبيرًا. تشمل هذه المخاطر:
يمكن مهاجمة الوكيل القابل للتحديث ( مباشرة )؛
يحتوي على منطق تدمير ذاتي. قد يتعرض للاختراق في حالة الاستدعاء المشترك لـ selfdestruct و create2.
تدابير الوقاية ضد نموذج التهديد II
النقطة الأساسية هي تقييم ما إذا كانت الهوك خبيثة. بشكل أكثر تحديدًا، بالنسبة للهوك المدارة، يجب أن نركز على سلوك إدارة الرسوم؛ بينما بالنسبة للهوك المستقل، تكون النقطة الرئيسية هي ما إذا كانت قابلة للتحديث.
! [لماذا يعتبر Hook "سيف ذو حدين" ل Uniswap V4؟] ](https://img-cdn.gateio.im/webp-social/moments-97c1e5846e4f09953053f0fb97876f16.webp)
الاستنتاج
تقدم هذه المقالة نظرة عامة موجزة عن الآليات الأساسية المتعلقة بمسألة أمان Hook في Uniswap v4، وتطرح نموذجين للتهديدات وتستعرض المخاطر الأمنية ذات الصلة.
في المقالات القادمة، سنقوم بتحليل عميق لمشكلات الأمان تحت كل نموذج من نماذج التهديد.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
آلية Hook في Uniswap v4 تحتوي على مخاطر أمنية، الخبراء يحذرون من استخدامها بحذر
إطلاق Uniswap v4 ووجود مخاطر أمان محتملة في آلية Hook
سيتم إصدار Uniswap v4 قريبًا، وتقدم هذه التحديثات العديد من الميزات الجديدة، بما في ذلك دعم عدد غير محدود من أحواض السيولة لكل زوج تداول، والرسوم الديناميكية، وتصميم أحادي، وتسجيل فوري، وآلية Hook، بالإضافة إلى دعم معيار ERC1155. ومن المتوقع أن يتم إطلاق v4 بعد ترقية إيثريوم كانكون.
في ظل العديد من الابتكارات، فإن آلية Hook تحظى باهتمام كبير بسبب إمكانياتها القوية. فهي تسمح بتنفيذ رمز مخصص في نقاط زمنية محددة خلال دورة حياة مجموعة السيولة، مما يعزز بشكل كبير قابلية توسيع المجموعة ومرونتها.
ومع ذلك، قد تكون آلية Hook أيضًا سلاحًا ذا حدين. على الرغم من أنها قوية ومرنة، إلا أن الاستخدام الآمن لـ Hook يواجه أيضًا تحديات. لا مفر من أن تعقيد Hook يجلب معه نقاط هجوم محتملة جديدة. لذلك، من المهم بشكل خاص تقديم قضايا الأمان والمخاطر المحتملة المرتبطة بآلية Hook بشكل منهجي، حيث سيساعد ذلك في بناء Hook أكثر أمانًا لـ Uniswap v4.
تتناول هذه المقالة مفاهيم آلية Hook في Uniswap v4 وتستعرض المخاطر الأمنية الموجودة فيها.
ميكانيكا Uniswap V4
قبل أن نتعمق في المناقشة، نحتاج إلى فهم أساسي لآلية Uniswap v4. وفقًا للإعلان الرسمي والورقة البيضاء، تعتبر Hook، والهندسة المعمارية الأحادية، والحساب الفوري ثلاث ميزات مهمة لتحقيق برك السيولة المخصصة والتوجيه الفعال عبر عدة برك.
خطاف
يشير Hook إلى العقود التي تعمل في مراحل مختلفة من دورة حياة تجمع السيولة. يأمل فريق Uniswap من خلال إدخال Hook أن يتمكن أي شخص من اتخاذ قرارات متوازنة. يمكن أن تحقق هذه الطريقة دعمًا أصليًا للرسوم الديناميكية، وإضافة أوامر محددة على السلسلة، أو من خلال صانع سوق متوسط مرجح بالوقت (TWAMM) لتوزيع الطلبات الكبيرة.
هناك ثمانية استدعاءات Hook حالياً، مقسمة إلى أربع مجموعات ( تحتوي كل مجموعة على زوج من الاستدعاءات ):
! [لماذا يعتبر Hook "سيف ذو حدين" ل Uniswap V4؟] ](https://img-cdn.gateio.im/webp-social/moments-f652bf2a22ca7f28f19b4ce9880d0548.webp)
نمط فردي، محاسبة البرق وآلية القفل
تصميم الهيكل الأحادي ونظام المحاسبة السريعة يهدف إلى تحسين الأداء من خلال خفض التكاليف وضمان الكفاءة. إنه يقدم عقد أحادي جديد، حيث يتم الاحتفاظ بجميع برك السيولة في نفس العقد الذكي. يعتمد هذا التصميم الأحادي على PoolManager لتخزين وإدارة حالة جميع البرك.
تم تقديم النسخة v4 آلية المحاسبة السريعة وآلية القفل. تعمل آلية القفل بالطريقة التالية:
يطلب عقد locker قفل في PoolManager.
يقوم PoolManager بإضافة عنوان عقد الـ locker إلى قائمة lockData، وينادي على رد الاتصال lockAcquired.
يتم تنفيذ منطق عقد الخزانة في رد النداء. قد تؤدي التفاعلات بين عقد الخزانة والمسبح خلال التنفيذ إلى زيادة غير صفرية في العملة. ومع ذلك، يجب تسوية جميع الزيادات لتكون صفرًا عند انتهاء التنفيذ. بالإضافة إلى ذلك، إذا كانت قائمة lockData غير فارغة، يمكن فقط لعقد الخزانة الأخير تنفيذ العمليات.
يقوم PoolManager بالتحقق من حالة صف lockData وزيادة العملة. بعد التحقق، سيقوم PoolManager بحذف عقدة الlocker.
بشكل عام، يمنع آلية القفل الوصول المتزامن ويضمن تسوية جميع المعاملات. تتقدم عقود القفل بطلبات القفل بالترتيب، ثم تنفذ المعاملات من خلال رد الاتصال lockAcquired. قبل وبعد كل عملية في المسبح، سيتم استدعاء رد الاتصال المقابل. أخيرًا، سيتحقق PoolManager من الحالة.
هذه الطريقة تعني أن التعديلات العملية تتعلق بالصافي الداخلي للرصيد ( أي دلتا )، وليس تنفيذ تحويل فوري. ستُسجل أي تعديلات في الرصيد الداخلي للمجمع، بينما يتم تنفيذ التحويل الفعلي عند انتهاء العملية ( أي قفل ). تضمن هذه العملية عدم وجود رموز غير مسددة، مما يحافظ على سلامة الأموال.
نظرًا لوجود آلية القفل، لا يمكن لجميع الحسابات الخارجية (EOA) التفاعل مباشرة مع PoolManager. بدلاً من ذلك، يجب أن يتم أي تفاعل من خلال عقد. يعمل هذا العقد كخزانة وسيطة، ويجب طلب القفل قبل إجراء أي عمليات على البركة.
توجد حالتان رئيسيتان للتفاعل مع العقود:
عقد locker يأتي من مكتبة التعليمات البرمجية الرسمية، أو يتم نشره بواسطة المستخدم. في هذه الحالة، يمكننا اعتبار التفاعل كأنه يتم عبر جهاز توجيه.
تم دمج عقد locker وHook في نفس العقد، أو يتم التحكم فيهما بواسطة كيان طرف ثالث. في هذه الحالة، يمكننا اعتبار التفاعل يتم من خلال Hook. في هذه الحالة، يلعب Hook دور عقد locker ويتولى أيضًا مسؤولية معالجة الاستدعاءات.
! [لماذا يعتبر Hook "سيف ذو حدين" ل Uniswap V4؟] ](https://img-cdn.gateio.im/webp-social/moments-ba4bfa88e0ac0b6246e82ad879361ff3.webp)
نموذج التهديد
قبل مناقشة القضايا الأمنية ذات الصلة، نحتاج إلى تحديد نموذج التهديد. نركز بشكل أساسي على حالتين رئيسيتين:
نموذج التهديد I: هوك نفسه خبيث، ولكن هناك ثغرات.
نموذج التهديد II: هوك نفسه خبيث.
في الجزء التالي، سنناقش القضايا الأمنية المحتملة بناءً على هذين النموذجين للتهديد.
مشكلات الأمان في نموذج التهديد I
نموذج التهديد I يركز على الثغرات المرتبطة بHook نفسه. يفترض هذا النموذج أن المطور وHook الخاص به ليس لديهم نوايا خبيثة. ومع ذلك، يمكن أن تظهر الثغرات المعروفة الموجودة في العقود الذكية أيضًا في Hook.
نحن نختار التركيز على الثغرات المحتملة الفريدة من نوعها في الإصدار v4. في Uniswap v4، يعتبر Hook عقدًا ذكيًا يمكنه تنفيذ منطق مخصص قبل أو بعد العمليات الأساسية على المسبح (، بما في ذلك التهيئة، تعديل الموضع، التبادل، وجمع ). على الرغم من أن Hook من المتوقع أن يحقق واجهة قياسية، إلا أنه يسمح أيضًا بتضمين منطق مخصص. لذلك، ستقتصر نطاق مناقشتنا على المنطق المتعلق بواجهة Hook القياسية. بعد ذلك، سنحاول تحديد مصادر الثغرات المحتملة، على سبيل المثال، كيف يمكن لـ Hook استغلال هذه الدوال القياسية لـ Hook.
على وجه التحديد، سنركز على نوعين من Hook:
النوع الأول من الـ hook، هو حفظ أموال المستخدمين. في هذه الحالة، قد يقوم المهاجمون باستهداف هذا الـ hook لنقل الأموال، مما يؤدي إلى خسارة الأصول.
النوع الثاني من الهوك، يخزن بيانات الحالة الأساسية التي يعتمد عليها المستخدم أو بروتوكولات أخرى. في هذه الحالة، قد يحاول المهاجم تغيير الحالة الأساسية. عندما يستخدم الآخرون أو البروتوكولات حالة خاطئة، قد يسبب ذلك مخاطر محتملة.
بعد البحث المتعمق في مستودع Awesome Uniswap v4 Hooks، اكتشفنا عدة ثغرات خطيرة. تنبع هذه الثغرات بشكل رئيسي من التفاعل بين hook و PoolManager و الأطراف الخارجية الثالثة، ويمكن تصنيفها بشكل أساسي إلى فئتين: مشاكل التحكم في الوصول ومشاكل التحقق من المدخلات.
بشكل عام، وجدنا 22 مشروعًا ذا صلة ( استبعدنا المشاريع التي لا تتعلق بـ Uniswap v4 ). من بين هذه المشاريع، نعتقد أن هناك 8 مشاريع (36% ) تحتوي على ثغرات. من بين هذه المشاريع الثمانية التي تحتوي على ثغرات، يوجد 6 لديها مشاكل في التحكم في الوصول، و2 عرضة للاستدعاءات الخارجية غير الموثوقة.
مشكلة التحكم في الوصول
في هذا الجزء من المناقشة، نركز بشكل رئيسي على المشكلات التي قد تسببها دوال الاستدعاء في v4، بما في ذلك 8 دوال استدعاء hook ودالة lock. يجب أن يتم استدعاء هذه الدوال فقط من قبل PoolManager، ولا يمكن استدعاؤها من قبل عناوين أخرى ( بما في ذلك EOA والعقد ). على سبيل المثال، في حالة توزيع المكافآت بواسطة مفتاح تجمع الأموال، إذا كان يمكن استدعاء الدالة المقابلة من قبل أي حساب، فقد يتم استلام المكافآت بشكل خاطئ.
لذلك، من الضروري أن يكون لدى hook آلية قوية للتحكم في الوصول، خاصةً لأنها يمكن أن تُستدعى من قبل أطراف أخرى بخلاف المسبح نفسه. من خلال الإدارة الصارمة لحقوق الوصول، يمكن لمسبح السيولة أن يقلل بشكل كبير من المخاطر المرتبطة بالتفاعلات غير المصرح بها أو الخبيثة مع hook.
مشكلة التحقق من الإدخال
في Uniswap v4، نظرًا لوجود آلية القفل، يجب على المستخدمين الحصول على قفل من العقد قبل تنفيذ أي عملية في بركة الأموال. وهذا يضمن أن العقد الحالي الذي يشارك في التفاعل هو أحدث عقد قفل.
على الرغم من ذلك، لا يزال هناك سيناريو هجوم محتمل، وهو الاستدعاءات الخارجية غير الموثوقة الناتجة عن عدم التحقق السليم من المدخلات في بعض تنفيذات الـ Hook القابلة للاختراق:
أولاً، لم تتحقق hook من المسبح المالي الذي ينوي المستخدم التفاعل معه. قد يكون هذا مسبحًا ماليًا خبيثًا يحتوي على رموز مزيفة ويقوم بتنفيذ منطق ضار.
ثانياً، بعض دوال الhook الرئيسية تسمح باستدعاءات خارجية عشوائية.
إن الاستدعاءات الخارجية غير الموثوقة خطيرة للغاية، لأنها قد تؤدي إلى أنواع مختلفة من الهجمات، بما في ذلك هجوم إعادة الدخول المعروف لدينا.
لشن هجمات على هذه الهوكات القابلة للاستغلال، يمكن للمهاجمين تسجيل بركة أموال ضارة لرموزهم المزيفة، ثم استدعاء الهوك لتنفيذ عمليات في بركة الأموال. أثناء التفاعل مع بركة الأموال، تقوم منطق الرموز الضارة باختطاف تدفق التحكم لارتكاب أفعال غير جيدة.
تدابير الحماية ضد نموذج التهديد I
لتجنب مثل هذه المشكلات الأمنية المتعلقة بالـ hook، من الضروري تنفيذ التحكم المناسب في الوصول إلى الوظائف الخارجية/العامة الحساسة والتحقق من صحة معلمات الإدخال، مما يضمن التحقق من التفاعلات. بالإضافة إلى ذلك، قد تساعد حماية إعادة الدخول في ضمان عدم تنفيذ الـ hook بشكل متكرر في سير العمل المنطقي القياسي. من خلال تنفيذ تدابير الأمان المناسبة، يمكن لخزانات الأموال تقليل المخاطر المرتبطة بمثل هذه التهديدات.
مشاكل الأمان في نموذج التهديد II
في نموذج التهديد هذا، نفترض أن المطورين وhook الخاص بهم خبيثون. نظرًا لأن النطاق المعني واسع، فإننا نركز فقط على مسائل الأمان المتعلقة بالإصدار v4. لذلك، المفتاح هو ما إذا كانت hook المقدمة قادرة على التعامل مع الأصول المشفرة الخاصة بتحويلات أو تفويضات المستخدم.
نظرًا لأن طريقة الوصول إلى hook تحدد الأذونات التي يمكن منحها لـ hook، فإننا نقسم hook إلى فئتين:
هوك مدارة (Managed Hooks): الهوك ليس نقطة دخول. يجب على المستخدمين التفاعل مع الهوك عبر جهاز التوجيه ( الذي قد توفره Uniswap ).
خطافات مستقلة ( Standalone Hooks ): hook هو نقطة دخول، يسمح للمستخدمين بالتفاعل مباشرة معها.
نوع الاستضافة Hook
في هذه الحالة، تشمل أصول المستخدم المشفرة ( الرموز الأصلية ورموز أخرى ) التي تم تحويلها أو تفويضها إلى router. نظرًا لأن PoolManager نفذ فحص الرصيد، فإنه من الصعب على الهاكرز الخبيثين سرقة هذه الأصول بشكل مباشر. ومع ذلك، لا يزال هناك مجال محتمل للهجمات. على سبيل المثال، قد يتمكن المهاجمون من التلاعب بآلية إدارة الرسوم في الإصدار v4 من خلال hook.
نوع مستقل من الخطاف
عندما يُستخدم Hook كنقطة دخول، تصبح الأمور أكثر تعقيدًا. في هذه الحالة، نظرًا لأن المستخدمين يمكنهم التفاعل مباشرةً مع hook، يحصل hook على مزيد من السلطة. من الناحية النظرية، يمكن أن ينفذ hook أي عملية يريدها من خلال هذا التفاعل.
في الإصدار v4، تعتبر عملية التحقق من منطق الكود أمرًا بالغ الأهمية. تكمن المشكلة الرئيسية في إمكانية التلاعب بمنطق الكود. إذا كان الـ hook قابلاً للتحديث، فهذا يعني أن hook يبدو آمنًا قد يصبح خبيثًا بعد التحديث، مما يشكل خطرًا كبيرًا. تشمل هذه المخاطر:
يمكن مهاجمة الوكيل القابل للتحديث ( مباشرة )؛
يحتوي على منطق تدمير ذاتي. قد يتعرض للاختراق في حالة الاستدعاء المشترك لـ selfdestruct و create2.
تدابير الوقاية ضد نموذج التهديد II
النقطة الأساسية هي تقييم ما إذا كانت الهوك خبيثة. بشكل أكثر تحديدًا، بالنسبة للهوك المدارة، يجب أن نركز على سلوك إدارة الرسوم؛ بينما بالنسبة للهوك المستقل، تكون النقطة الرئيسية هي ما إذا كانت قابلة للتحديث.
! [لماذا يعتبر Hook "سيف ذو حدين" ل Uniswap V4؟] ](https://img-cdn.gateio.im/webp-social/moments-97c1e5846e4f09953053f0fb97876f16.webp)
الاستنتاج
تقدم هذه المقالة نظرة عامة موجزة عن الآليات الأساسية المتعلقة بمسألة أمان Hook في Uniswap v4، وتطرح نموذجين للتهديدات وتستعرض المخاطر الأمنية ذات الصلة.
في المقالات القادمة، سنقوم بتحليل عميق لمشكلات الأمان تحت كل نموذج من نماذج التهديد.