تحليل احترافي لتقنية حول حادثة هجوم هاكر على بروتوكول سيتوس

نسخة مبسطة: تفسير بسيط "الترجمة" لاحترافي التقنية حول @CetusProtocol

تحليل حادثة اختراق

هذا الهجوم يكشف عن مشكلة كلاسيكية في تجاوز سعة الأعداد الصحيحة، تتجلى بشكل خاص في تقليص البيانات أثناء عملية تحويل النوع.

تفكيك التفاصيل الفنية:

1. تحديد الثغرات: تظهر المشكلة في آلية تحويل النوع في دالة get_amount_by_liquidity، حيث يؤدي التحويل القسري من u256 إلى u64 إلى فقدان بيانات عالية.

2. سير الهجوم:

1، المهاجم يمرر قيمة كبيرة جداً كمعامل لعدد السيولة من خلال دالة add_liquidity؛

2، يقوم النظام باستدعاء دالة get_delta_b لحساب العدد المطلوب من رموز B؛

3، في عملية الحساب، يجب أن يكون ناتج ضرب قيمتين من نوع u128 هو من نوع u256؛

العيب الرئيسي: يتم تحويل نتيجة u256 بشكل قسري إلى u64 عند إرجاع الدالة، مما يؤدي إلى قطع بيانات الـ 128 بت العليا.

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

تشبيه بسيط: مثل استخدام آلة حاسبة يمكنها عرض 8 أرقام فقط لحساب مليار × مليار، فإن النتيجة المكونة من 20 رقمًا يمكنها عرض آخر 8 أرقام فقط، بينما تختفي الأرقام الـ 12 الأولى مباشرة. المهاجمون استغلوا هذه الثغرة المعروفة باسم "فقدان دقة الحساب".

من الضروري أن نوضح نقطة واحدة: هذه الثغرة لا تتعلق بالهيكل الأمني الأساسي لـ @SuiNetwork، وأمان لغة Move لا يزال موثوقًا به مؤقتًا. لماذا؟

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

بشكل أكثر تحديدًا، على الرغم من أن نظام أنواع Move صارم، إلا أنه لا يزال يعتمد على الحكم الصحيح للمطورين في عمليات تحويل الأنواع الصريحة (explicit casting). عندما يقوم البرنامج بتنفيذ تحويل نوع u256 إلى u64، لا يستطيع المترجم تحديد ما إذا كان هذا التصميم مقصودًا أو خطأ منطقيًا.

علاوة على ذلك، فإن هذا الحدث الأمني لا يتعلق على الإطلاق بآلية الإجماع في Sui، أو معالجة المعاملات، أو إدارة الحالة، أو أي من الوظائف الأساسية الأساسية. شبكة Sui نفذت ببساطة تعليمات معاملاتها المقدمة من بروتوكول Cetus، وكانت الثغرة ناتجة عن عيب منطقي في بروتوكول تطبيق المستوى.

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

تصحيح:

تواصلت مع احترافي بشكل أعمق، ووجدت أن التحليل الفني لهجوم القراصنة على @CetusProtocol كان به انحراف في التفاصيل المحددة، لذلك أود تصحيحه.

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

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

يحتاج موقع الثغرات المحددة وآلية التنفيذ الفنية إلى تصحيح ، كما يلي.

تظهر المشكلة الحقيقية في فشل آلية فحص الفائض في دالة get\_delta\_a:

1. وظيفة الدالة: حساب عدد توكن A المطلوب عند إضافة السيولة المحددة;

٢) العيوب الرئيسية: تحتوي دالة checked\_shlw على خطأ في الترميز لفحص الفائض، مما أدى إلى عدم منع قيم السيولة الكبيرة غير الصحيحة؛

3. استغلال الهجوم: يقوم القراصنة بإنشاء قيمة سيولة خاصة، متجاوزين فحص الفشل، وفي النهاية من خلال آلية التقريب لأعلى لـ div\_round، تجعل كمية الرمز المميز A المطلوبة تصبح 14).

أثر الهجوم: استخدم توكن A واحد لصك سيولة ضخمة، ثم استنزاف حوض الأموال.