في السابق ، اكتشف فريق CertiK سلسلة من الثغرات الأمنية لرفض الخدمة في Sui blockchain. من بين نقاط الضعف هذه ، تبرز ثغرة جديدة وعالية التأثير. يمكن أن تتسبب هذه الثغرة الأمنية في عدم قدرة عقد شبكة Sui على معالجة المعاملات الجديدة ، والتأثير يعادل الإغلاق الكامل للشبكة بأكملها.
يوم الإثنين الماضي فقط ، تلقت CertiK مكافأة خطأ قدرها 500000 دولار من SUI لاكتشافها ثغرة أمنية كبيرة. قامت CoinDesk ، وهي وسيلة إعلام موثوقة في الصناعة الأمريكية ، بالإبلاغ عن الحدث ، ثم أصدرت وسائل الإعلام الرئيسية أيضًا أخبارًا ذات صلة بعد تقريرها.
تسمى هذه الثغرة الأمنية بشكل واضح "عجلة الهامستر": أسلوب الهجوم الفريد الخاص بها يختلف عن الهجمات المعروفة حاليًا. يحتاج المهاجم فقط إلى إرسال حمولة تبلغ حوالي 100 بايت لتشغيل حلقة لا نهائية في عقدة التحقق Sui. ، مما يجعلها غير مستجيبة للمعاملات الجديدة.
بالإضافة إلى ذلك ، يمكن أن يستمر الضرر الناجم عن الهجوم بعد إعادة تشغيل الشبكة ، ويمكن نشره تلقائيًا في شبكة Sui ، مما يجعل جميع العقد غير قادرة على معالجة المعاملات الجديدة مثل الهامستر الذي يعمل بلا نهاية على العجلة. لذلك نشير إلى هذا النوع الفريد من الهجوم على أنه هجوم "عجلة الهامستر".
بعد اكتشاف الخطأ ، قام CertiK بإبلاغه إلى Sui من خلال برنامج مكافأة الأخطاء الخاص بـ Sui. استجابت Sui أيضًا بشكل فعال في المرة الأولى ، وأكدت خطورة الثغرة الأمنية ، واتخذت بنشاط التدابير المقابلة لإصلاح المشكلة قبل إطلاق mainnet. بالإضافة إلى إصلاح هذه الثغرة الأمنية ، قامت Sui أيضًا بتنفيذ إجراءات التخفيف الوقائية لتقليل الضرر المحتمل الذي قد تسببه هذه الثغرة الأمنية.
لشكر فريق CertiK على إفصاحهم المسؤول ، منحت Sui فريق CertiK مكافأة قدرها 500000 دولار.
سيتم الكشف عن تفاصيل هذه الثغرة الخطيرة على المستوى الفني أدناه ، وسيتم توضيح السبب الجذري والتأثير المحتمل للثغرة الأمنية.
** شرح الضعف **
** الدور الرئيسي للمدققين في Sui **
بالنسبة لسلاسل الحظر التي تستند إلى لغة Move مثل Sui و Aptos ، فإن آلية الحماية لمنع هجمات الحمولة الخبيثة هي أساسًا تقنية التحقق الثابت. من خلال تقنية التحقق الثابت ، يمكن لـ Sui التحقق من صحة الحمولة المقدمة من قبل المستخدم قبل إصدار العقد أو ترقيته. يوفر المدقق سلسلة من المدققات للتأكد من صحة البنية والدلالات. فقط بعد اجتياز التحقق من التحقق ، سيدخل العقد إلى جهاز Move الظاهري ليتم تنفيذه.
تهديدات الحمولة الضارة في سلسلة النقل
توفر سلسلة Sui مجموعة جديدة من نماذج وواجهات التخزين أعلى الجهاز الظاهري الأصلي Move ، لذا فإن Sui لديها نسخة مخصصة من جهاز Move الظاهري. من أجل دعم أساسيات التخزين الجديدة ، تقدم Sui كذلك سلسلة من طرق الفحص الإضافية والمخصصة للتحقق الأمني من الحمولات غير الموثوق بها ، مثل أمان الكائن ووظائف الوصول إلى التخزين العالمي. تتناسب هذه الفحوصات المخصصة مع ميزات Sui الفريدة ، لذلك نطلق على هذه الشيكات المخصصة أدوات التحقق Sui.
أمر سوي لفحص الأحمال
كما هو موضح في الشكل أعلاه ، تقوم معظم عمليات التحقق في المدقق بإجراء تحقق أمني هيكلي مقابل الوحدة النمطية المترجمة (التي تمثل تنفيذ حمولة العقد التي يوفرها المستخدم). على سبيل المثال ، استخدم "Duplicate Checker" للتأكد من عدم وجود إدخالات مكررة في حمولة وقت التشغيل ؛ استخدم "Limit Checker" للتأكد من أن طول كل حقل في حمولة وقت التشغيل يقع ضمن الحد الأقصى المسموح به للإدخال.
بالإضافة إلى الفحوصات الهيكلية ، لا تزال الفحوصات الثابتة للمدقق تتطلب طرق تحليل أكثر تعقيدًا لضمان متانة الحمولات غير الموثوق بها على المستوى الدلالي.
** تعرف على مترجم Move المجرد: **
** التحليل الخطي والتكراري **
المفسر المجرد المقدم من Move هو إطار عمل مصمم خصيصًا لإجراء تحليل أمني معقد على الرمز الثانوي من خلال تفسير مجرد. تجعل هذه الآلية عملية التحقق أكثر دقة ودقة ، ويسمح لكل مدقق بتحديد حالته المجردة الفريدة للتحليل.
عند بدء التشغيل ، يقوم المترجم الفوري ببناء رسم بياني للتحكم (CFG) من الوحدات المترجمة. تحتفظ كل كتلة أساسية في CFGs بمجموعة من الحالات ، و "حالة الطلب المسبق" و "حالة ما بعد الطلب". توفر "حالة الطلب المسبق" لقطة لحالة البرنامج قبل تنفيذ الكتلة الأساسية ، بينما توفر "حالة الطلب المسبق" وصفًا لحالة البرنامج بعد تنفيذ الكتلة الأساسية.
عندما لا يواجه المترجم المجرد قفزة (أو حلقة) في الرسم البياني لتدفق التحكم ، فإنه يتبع مبدأ تنفيذ خطي بسيط: يتم تحليل كل كتلة أساسية بدورها ، ويتم حساب التعليمات السابقة وفقًا لدلالات كل تعليمة في حالة متسلسلة وحالة ما بعد التسلسل. والنتيجة هي لقطة دقيقة لحالة كل كتلة أساسية أثناء تنفيذ البرنامج ، مما يساعد على التحقق من خصائص أمان البرنامج.
سير عمل مترجم نقل مجردة
ومع ذلك ، تصبح العملية أكثر تعقيدًا عندما تكون هناك حلقات في تدفق التحكم. يعني ظهور الدورة أن الرسم البياني للتحكم في التدفق يحتوي على حافة قفزة للخلف. يتوافق مصدر الحافة الخلفية للقفز مع الحالة اللاحقة للكتلة الأساسية الحالية والكتلة الأساسية المستهدفة (رأس الحلقة) للقفزة- تم تحليل الحافة الخلفية مسبقًا لذلك ، يحتاج المفسر التجريدي إلى دمج حالات الكتلتين الأساسيتين المرتبطتين بالرجوع إلى الخلف بعناية.
إذا تم العثور على الحالة المدمجة لتكون مختلفة عن حالة الطلب المسبق الحالية للكتلة الأساسية لرأس الحلقة ، يقوم المترجم المجرد بتحديث حالة الكتلة الأساسية لرأس الحلقة ويعيد تشغيل التحليل بدءًا من هذه الكتلة الأساسية. ستستمر عملية التحليل التكراري هذه حتى تستقر الحلقة السابقة للحالة. بمعنى آخر ، تتكرر هذه العملية حتى لا تتغير حالة الطلب المسبق للكتلة الأساسية لرأس الحلقة بين التكرارات. يشير الوصول إلى نقطة ثابتة إلى اكتمال تحليل الدورة.
** مدقق Sui IDLeak: **
** تحليل تفسير مجردة مخصص **
على عكس تصميم Move الأصلي ، تقدم منصة Sui blockchain نموذج تخزين عالمي فريد من نوعه يتمحور حول "الهدف". الميزة البارزة لهذا النموذج هي: أي بنية بيانات ذات سمة رئيسية (مخزنة في السلسلة كفهرس) يجب أن يكون لها نوع المعرف باعتباره الحقل الأول للهيكل. حقل المعرف غير قابل للتغيير ولا يمكن نقله إلى كائنات أخرى ، حيث يجب أن يكون لكل كائن معرف فريد عالميًا. لضمان هذه الخصائص ، قامت Sui ببناء مجموعة من منطق التحليل المخصص أعلى المترجم المجرد.
مدقق IDLeak ، المعروف أيضًا باسم id \ _leak \ _verifier ، يعمل جنبًا إلى جنب مع المفسر المجرد للتحليل. وله نطاق AbstractDomain الفريد الخاص به ، والذي يسمى AbstractState. كل حالة مجردة تتكون من AbstractValue المقابلة لمتغيرات محلية متعددة. تتم مراقبة حالة كل متغير محلي بواسطة AbstractValue لتتبع ما إذا كان متغير المعرف جديدًا أم لا.
في عملية تعبئة الهيكل ، يسمح مدقق IDLeak فقط بتعبئة معرف جديد تمامًا في هيكل. من خلال تحليل تحليل التفسير الملخص ، يمكن لمدققي IDLeak تتبع حالة تدفق البيانات المحلية بشكل شامل لضمان عدم نقل أي معرفات حالية إلى كائنات أخرى ذات بنية.
** مشكلة عدم تناسق صيانة حالة أداة التحقق من صحة Sui IDLeak **
تم دمج مدقق IDLeak مع مترجم Move abstract عن طريق تنفيذ وظيفة AbstractState :: Join. تلعب هذه الوظيفة دورًا أساسيًا في إدارة الدولة ، لا سيما في دمج قيم الحالة وتحديثها.
افحص هذه الوظائف بالتفصيل لفهم عملها:
في AbstractState :: Join ، تأخذ الدالة AbstractState آخر كمدخل وتحاول دمج حالتها المحلية مع الحالة المحلية للكائن الحالي. لكل متغير محلي في حالة الإدخال ، فإنه يقارن قيمة هذا المتغير بقيمته الحالية في الحالة المحلية (افتراضيات إلى AbstractValue :: Other إذا لم يتم العثور عليه). إذا كانت القيمتان غير متساويتين ، فسيتم تعيين علامة "متغيرة" كأساس لما إذا كانت نتيجة دمج الحالة النهائية قد تغيرت ، وتحديث قيمة المتغير المحلي في الحالة المحلية عن طريق استدعاء AbstractValue :: Join.
في AbstractValue :: Join ، تقارن الدالة قيمتها مع قيمة AbstractValue أخرى. إذا كانت متساوية ، فستعيد القيمة التي تم تمريرها. في حالة عدم المساواة ، يتم عرض AbstractValue :: Other.
ومع ذلك ، يحتوي منطق صيانة الحالة هذا على مشكلة عدم تناسق خفية. على الرغم من أن AbstractState :: Join سيعيد نتيجة تشير إلى أن الحالة المدمجة قد تغيرت (JoinResult :: Changed) بناءً على الاختلاف بين القيم الجديدة والقديمة ، قد تظل قيمة الحالة المُحدثة المدمجة بدون تغيير.
سبب مشكلة عدم الاتساق هذه هو ترتيب العمليات: قرار تغيير الحالة في AbstractState :: Join يحدث قبل تحديث الحالة (AbstractValue :: Join) ، وهذا القرار لا يعكس نتيجة تحديث الحالة الحقيقية.
بالإضافة إلى ذلك ، في AbstractValue :: Join ، يلعب AbstractValue :: Other دورًا حاسمًا في نتيجة الدمج. على سبيل المثال ، إذا كانت القيمة القديمة هي AbstractValue :: Other وكانت القيمة الجديدة هي AbstractValue :: Fresh ، فإن قيمة الحالة المحدثة هي AbstractValue :: Other ، حتى لو كانت القيم القديمة والجديدة مختلفة ، تظل الحالة نفسها بدون تغيير بعد التحديث.
مثال: تناقض الاتصالات ذات الحالة
يؤدي هذا إلى عدم الاتساق: يتم الحكم على نتيجة دمج حالة الكتلة الأساسية على أنها "متغيرة" ، لكن قيمة الحالة المدمجة نفسها لم تتغير. في عملية تحليل التفسير المجرد ، قد يكون لمثل هذه التناقضات عواقب وخيمة. نقوم بمراجعة سلوك المترجم الفوري عندما تحدث دورة في رسم بياني للتحكم (CFG):
عند مواجهة حلقة ، يستخدم المترجم المجرد طريقة تحليل تكرارية لدمج حالة الكتلة الأساسية المستهدفة للرجوع للخلف والكتلة الأساسية الحالية. إذا تغيرت الحالة المدمجة ، فسيعيد المترجم المجرد التحليل بدءًا من هدف الانتقال.
ومع ذلك ، إذا كانت عملية الدمج لتحليل التفسير المجرد تشير خطأً إلى نتيجة دمج الحالة على أنها "تغيير" ، بينما في الواقع لم تتغير قيمة المتغير الداخلي للحالة ، سيؤدي ذلك إلى إعادة تحليل لا نهاية لها ، مما يؤدي إلى حلقة لا نهائية.
** مزيد من استغلال التناقضات **
** تفعّل حلقة لا نهائية في أداة التحقق Sui IDLeak **
باستغلال هذا التناقض ، يمكن للمهاجم إنشاء رسم بياني للتحكم الضار يخدع مدققي IDLeak في حلقة لا نهائية. يتكون مخطط تدفق التحكم هذا الذي تم إنشاؤه بعناية من ثلاث كتل أساسية: BB1 و BB2 و BB3. تجدر الإشارة إلى أننا قدمنا عمدًا حافة قفزة خلفية من BB3 إلى BB2 لإنشاء حلقة.
يمكن أن تؤدي حالة CFG + الضارة إلى حلقة داخلية لا نهائية في مدقق IDLeak
تبدأ العملية بـ BB2 ، حيث يتم تعيين AbstractValue لمتغير محلي معين على :: Other. بعد تنفيذ BB2 ، ينتقل التدفق إلى BB3 حيث يتم تعيين نفس المتغير على :: Fresh. في نهاية BB3 ، توجد حافة قفزة خلفية ، تقفز إلى BB2.
تلعب التناقضات المذكورة أعلاه دورًا رئيسيًا في التفسير المجرد لهذا المثال. عند معالجة حافة الانتقال الخلفي ، يحاول المترجم المجرد توصيل حالة الطلب البريدي BB3 (مع المتغير ":: Fresh") بحالة الطلب المسبق لـ BB2 (مع المتغير ":: Other"). تلاحظ دالة AbstractState :: Join الفرق بين القيم القديمة والجديدة وتعين علامة "change" للإشارة إلى أن BB2 بحاجة إلى إعادة تحليل.
ومع ذلك ، فإن السلوك السائد لـ ":: Other" في AbstractValue :: Join يعني أنه بعد دمج AbstractValue ، تظل القيمة الفعلية لمتغير الحالة BB2 ":: Other" ، ولم تتغير نتيجة دمج الحالة .
لذلك بمجرد أن تبدأ هذه العملية الدورية ، أي مع استمرار المدققين في إعادة تحليل BB2 وجميع عقد الكتلة الأساسية اللاحقة (BB3 في هذه الحالة) ، فإنها تستمر إلى أجل غير مسمى. تستهلك الحلقة اللانهائية جميع دورات وحدة المعالجة المركزية المتاحة ، مما يجعلها غير قادرة على معالجة المعاملات الجديدة والاستجابة لها ، والتي تستمر عبر عمليات إعادة تشغيل المدقق.
من خلال استغلال هذه الثغرة الأمنية ، تعمل عقد التحقق إلى ما لا نهاية مثل الهامستر على عجلة في حلقة لا نهائية ، غير قادرة على معالجة المعاملات الجديدة. لذلك نشير إلى هذا النوع الفريد من الهجوم على أنه هجوم "عجلة الهامستر".
يمكن أن يؤدي هجوم "عجلة الهامستر" بشكل فعال إلى توقف المدققين Sui ، والذي بدوره يمكن أن يؤدي إلى انهيار شبكة Sui بأكملها.
بعد فهم سبب الثغرة الأمنية وعملية التشغيل ، قمنا ببناء مثال ملموس باستخدام محاكاة Move bytecode التالية وأطلقنا بنجاح الثغرة الأمنية في المحاكاة في البيئة الحقيقية:
يوضح هذا المثال كيفية تشغيل الثغرة الأمنية في بيئة حقيقية من خلال رمز ثنائي تم إنشاؤه بعناية. على وجه التحديد ، يمكن للمهاجم تشغيل حلقة لا نهائية في مدقق IDLeak ، مما يؤدي إلى استهلاك جميع دورات وحدة المعالجة المركزية لعقدة Sui بحمولة تبلغ حوالي 100 بايت فقط ، مما يمنع بشكل فعال معالجة المعاملات الجديدة ويتسبب في رفض الخدمة على شبكة Sui.
يحتوي برنامج مكافأة الأخطاء في سوي على لوائح صارمة بشأن تقييم مستويات الضعف ، تعتمد بشكل أساسي على درجة الضرر الذي يلحق بالشبكة بأكملها. يجب أن تغلق نقاط الضعف التي تلبي التصنيف "الحرج" الشبكة بالكامل وتمنع بشكل فعال تأكيدات المعاملات الجديدة ، وتتطلب شوكة صلبة لإصلاح المشكلة ؛ (متوسطة) "أو نقاط ضعف" عالية الخطورة (عالية) ".
يمكن لثغرة "عجلة الهامستر" التي اكتشفها فريق CertiK Skyfall أن تغلق شبكة Sui بأكملها ، وتتطلب إصدارًا رسميًا من إصدار جديد للترقية والإصلاح. صنفت Sui في النهاية الثغرة بأنها "حرجة" بناءً على أهميتها. من أجل فهم التأثير الخطير الناجم عن هجوم "عجلة الهامستر" ، من الضروري بالنسبة لنا أن نفهم البنية المعقدة لنظام الواجهة الخلفية لـ Sui ، وخاصة العملية الكاملة لنشر أو ترقية المعاملات على السلسلة.
نظرة عامة على التفاعلات لإرسال المعاملات في Sui
في البداية ، يتم إرسال معاملات المستخدم عبر RPC للواجهة الأمامية وتمريرها إلى الخدمات الخلفية بعد التحقق الأساسي. خدمة Sui الخلفية مسؤولة عن التحقق من صحة حمولات المعاملات الواردة. بعد التحقق من توقيع المستخدم بنجاح ، يتم تحويل المعاملة إلى شهادة معاملة (تحتوي على معلومات المعاملة وتوقيع Sui).
تعتبر شهادات المعاملات هذه جزءًا أساسيًا من تشغيل شبكة Sui ويمكن نشرها بين مختلف عقد التحقق في الشبكة. بالنسبة لمعاملات إنشاء / ترقية العقد ، قبل أن يتم تحميلها إلى السلسلة ، ستتصل عقدة التحقق بمدقق Sui للتحقق والتحقق من صحة بنية العقد / دلالات هذه الشهادات. خلال مرحلة التحقق الحرجة هذه يمكن تشغيل واستغلال ثغرة "الحلقة اللانهائية".
عندما تم تشغيل الثغرة الأمنية ، تسببت في مقاطعة عملية التحقق إلى أجل غير مسمى ، مما أعاق بشكل فعال قدرة النظام على معالجة المعاملات الجديدة وتسبب في إغلاق الشبكة بالكامل. لزيادة الطين بلة ، استمر الوضع بعد إعادة تشغيل العقدة ، مما يعني أن وسائل التخفيف التقليدية كانت بعيدة عن أن تكون كافية. بمجرد تشغيل الثغرة الأمنية ، سيكون هناك "ضرر مستمر" وترك تأثير دائم على شبكة Sui بأكملها.
** حل سوي **
بعد ردود الفعل من CertiK ، أكدت Sui الثغرة الأمنية في الوقت المناسب وأصدرت إصلاحًا لمعالجة الخلل الخطير. يضمن الإصلاح الاتساق بين تغييرات الحالة وأعلام ما بعد التغيير ، مما يزيل التأثير الحرج لهجوم "عجلة الهامستر".
لإزالة التضارب المذكور أعلاه ، يتضمن إصلاح Sui تعديلًا صغيرًا ولكنه حاسم في وظيفة AbstractState :: Join. يزيل هذا التصحيح منطق تحديد نتيجة دمج الحالة قبل تنفيذ AbstractValue :: Join. بدلاً من ذلك ، قم بتنفيذ دالة AbstractValue :: Join لدمج الحالة أولاً ، وقم بتعيين الدمج عن طريق مقارنة نتيجة التحديث النهائية مع قيمة الحالة الأصلية (القديمة \ _value) علامة للتغييرات.
بهذه الطريقة ، ستكون نتيجة دمج الحالة متسقة مع نتيجة التحديث الحقيقي ، ولن تحدث حلقة لا نهائية أثناء عملية التحليل.
بالإضافة إلى إصلاح هذه الثغرة الأمنية المحددة ، قامت Sui أيضًا بنشر عوامل التخفيف لتقليل تأثير الثغرات الأمنية في أداة التحقق المستقبلية. وفقًا لاستجابة Sui في تقرير الخطأ ، يتضمن التخفيف ميزة تسمى Denylist.
"ومع ذلك ، لدى المدققين ملف تكوين عقدة يسمح لهم برفض فئات معينة من المعاملات مؤقتًا. يمكن استخدام هذا التكوين لتعطيل معالجة الإصدارات وترقيات الحزمة مؤقتًا. نظرًا لهذا الخطأ ، يتم تشغيل Sui قبل التوقيع على إصدار أو ترقية حزمة tx المدققين ، في حين أن denylist سيوقف المدقق من التشغيل وإسقاط tx الضار ، فإن رفض هذه الأنواع tx مؤقتًا هو تخفيف فعال بنسبة 100٪ (على الرغم من أنه سيعطل الخدمة مؤقتًا للأشخاص الذين يحاولون إصدار أو ترقية التعليمات البرمجية).
بالمناسبة ، لدينا ملف تكوين قائمة رفض TX هذا لفترة من الوقت الآن ، ولكننا أضفنا أيضًا آلية مماثلة للشهادات كتخفيف متابعة لثغرة "حلقة التحقق من الصحة" التي تم الإبلاغ عنها مسبقًا. باستخدام هذه الآلية ، سيكون لدينا المزيد من المرونة ضد هذا الهجوم: سنستخدم تكوين قائمة رفض الشهادات لجعل المدققين ينسون الشهادات السيئة (كسر الحلقة اللانهائية) ، وتكوين قائمة رفض TX لحظر النشر / الترقيات ، وبالتالي منع إنشاء عمليات هجوم ضار جديدة. شكرا لجعلنا نفكر في هذا!
لدى المدقق عدد محدود من "العلامات" (تختلف عن الغاز) للتحقق من الرمز الثانوي قبل توقيع المعاملة ، وإذا تعذر التحقق من جميع الرموز الثانوية الصادرة في المعاملة في هذه العلامات العديدة ، سيرفض المدقق التوقيع على المعاملة ، مما يمنع من التنفيذ على الشبكة. في السابق ، تم تطبيق القياس فقط على مجموعة محددة من ممرات المدقق المعقدة. لمكافحة هذا ، نمد القياس إلى كل مدقق لضمان وجود قيد على العمل الذي يؤديه المدقق أثناء عملية التحقق من كل علامة. لقد أصلحنا أيضًا خطأ حلقة لانهائية محتملة في أداة التحقق من تسرب المعرف. "
*** - شرح من مطوري Sui حول إصلاحات الأخطاء ***
بشكل عام ، يمكّن Denylist المدققين من تجنب استغلال نقاط الضعف في أدوات التحقق مؤقتًا ومنع الضرر المحتمل الناجم عن بعض المعاملات الضارة بشكل فعال عن طريق تعطيل عملية الإصدار أو الترقية. عندما تدخل تدابير التخفيف الخاصة بـ Denylist حيز التنفيذ ، تضمن العقد قدرتها على الاستمرار في العمل من خلال التضحية بوظائف النشر / التحديث الخاصة بها.
لخص
في هذه المقالة ، نشارك التفاصيل الفنية لهجوم "Hamster Wheel" الذي اكتشفه فريق CertiK Skyfall ، وشرح كيف يستغل هذا النوع الجديد من الهجوم نقاط الضعف الرئيسية للتسبب في إغلاق كامل لشبكة Sui. بالإضافة إلى ذلك ، قمنا أيضًا بدراسة استجابة Sui في الوقت المناسب لإصلاح هذه المشكلة الحرجة ، وشاركنا إصلاح الثغرات الأمنية وأساليب التخفيف اللاحقة لنقاط الضعف المماثلة.
شاهد النسخة الأصلية
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
أحدث ثغرة في سوي "عجلة الهامستر" التفاصيل الفنية والتحليل المتعمق
في السابق ، اكتشف فريق CertiK سلسلة من الثغرات الأمنية لرفض الخدمة في Sui blockchain. من بين نقاط الضعف هذه ، تبرز ثغرة جديدة وعالية التأثير. يمكن أن تتسبب هذه الثغرة الأمنية في عدم قدرة عقد شبكة Sui على معالجة المعاملات الجديدة ، والتأثير يعادل الإغلاق الكامل للشبكة بأكملها.
يوم الإثنين الماضي فقط ، تلقت CertiK مكافأة خطأ قدرها 500000 دولار من SUI لاكتشافها ثغرة أمنية كبيرة. قامت CoinDesk ، وهي وسيلة إعلام موثوقة في الصناعة الأمريكية ، بالإبلاغ عن الحدث ، ثم أصدرت وسائل الإعلام الرئيسية أيضًا أخبارًا ذات صلة بعد تقريرها.
تسمى هذه الثغرة الأمنية بشكل واضح "عجلة الهامستر": أسلوب الهجوم الفريد الخاص بها يختلف عن الهجمات المعروفة حاليًا. يحتاج المهاجم فقط إلى إرسال حمولة تبلغ حوالي 100 بايت لتشغيل حلقة لا نهائية في عقدة التحقق Sui. ، مما يجعلها غير مستجيبة للمعاملات الجديدة.
بالإضافة إلى ذلك ، يمكن أن يستمر الضرر الناجم عن الهجوم بعد إعادة تشغيل الشبكة ، ويمكن نشره تلقائيًا في شبكة Sui ، مما يجعل جميع العقد غير قادرة على معالجة المعاملات الجديدة مثل الهامستر الذي يعمل بلا نهاية على العجلة. لذلك نشير إلى هذا النوع الفريد من الهجوم على أنه هجوم "عجلة الهامستر".
بعد اكتشاف الخطأ ، قام CertiK بإبلاغه إلى Sui من خلال برنامج مكافأة الأخطاء الخاص بـ Sui. استجابت Sui أيضًا بشكل فعال في المرة الأولى ، وأكدت خطورة الثغرة الأمنية ، واتخذت بنشاط التدابير المقابلة لإصلاح المشكلة قبل إطلاق mainnet. بالإضافة إلى إصلاح هذه الثغرة الأمنية ، قامت Sui أيضًا بتنفيذ إجراءات التخفيف الوقائية لتقليل الضرر المحتمل الذي قد تسببه هذه الثغرة الأمنية.
لشكر فريق CertiK على إفصاحهم المسؤول ، منحت Sui فريق CertiK مكافأة قدرها 500000 دولار.
سيتم الكشف عن تفاصيل هذه الثغرة الخطيرة على المستوى الفني أدناه ، وسيتم توضيح السبب الجذري والتأثير المحتمل للثغرة الأمنية.
** شرح الضعف **
** الدور الرئيسي للمدققين في Sui **
بالنسبة لسلاسل الحظر التي تستند إلى لغة Move مثل Sui و Aptos ، فإن آلية الحماية لمنع هجمات الحمولة الخبيثة هي أساسًا تقنية التحقق الثابت. من خلال تقنية التحقق الثابت ، يمكن لـ Sui التحقق من صحة الحمولة المقدمة من قبل المستخدم قبل إصدار العقد أو ترقيته. يوفر المدقق سلسلة من المدققات للتأكد من صحة البنية والدلالات. فقط بعد اجتياز التحقق من التحقق ، سيدخل العقد إلى جهاز Move الظاهري ليتم تنفيذه.
تهديدات الحمولة الضارة في سلسلة النقل
توفر سلسلة Sui مجموعة جديدة من نماذج وواجهات التخزين أعلى الجهاز الظاهري الأصلي Move ، لذا فإن Sui لديها نسخة مخصصة من جهاز Move الظاهري. من أجل دعم أساسيات التخزين الجديدة ، تقدم Sui كذلك سلسلة من طرق الفحص الإضافية والمخصصة للتحقق الأمني من الحمولات غير الموثوق بها ، مثل أمان الكائن ووظائف الوصول إلى التخزين العالمي. تتناسب هذه الفحوصات المخصصة مع ميزات Sui الفريدة ، لذلك نطلق على هذه الشيكات المخصصة أدوات التحقق Sui.
أمر سوي لفحص الأحمال
كما هو موضح في الشكل أعلاه ، تقوم معظم عمليات التحقق في المدقق بإجراء تحقق أمني هيكلي مقابل الوحدة النمطية المترجمة (التي تمثل تنفيذ حمولة العقد التي يوفرها المستخدم). على سبيل المثال ، استخدم "Duplicate Checker" للتأكد من عدم وجود إدخالات مكررة في حمولة وقت التشغيل ؛ استخدم "Limit Checker" للتأكد من أن طول كل حقل في حمولة وقت التشغيل يقع ضمن الحد الأقصى المسموح به للإدخال.
بالإضافة إلى الفحوصات الهيكلية ، لا تزال الفحوصات الثابتة للمدقق تتطلب طرق تحليل أكثر تعقيدًا لضمان متانة الحمولات غير الموثوق بها على المستوى الدلالي.
** تعرف على مترجم Move المجرد: **
** التحليل الخطي والتكراري **
المفسر المجرد المقدم من Move هو إطار عمل مصمم خصيصًا لإجراء تحليل أمني معقد على الرمز الثانوي من خلال تفسير مجرد. تجعل هذه الآلية عملية التحقق أكثر دقة ودقة ، ويسمح لكل مدقق بتحديد حالته المجردة الفريدة للتحليل.
عند بدء التشغيل ، يقوم المترجم الفوري ببناء رسم بياني للتحكم (CFG) من الوحدات المترجمة. تحتفظ كل كتلة أساسية في CFGs بمجموعة من الحالات ، و "حالة الطلب المسبق" و "حالة ما بعد الطلب". توفر "حالة الطلب المسبق" لقطة لحالة البرنامج قبل تنفيذ الكتلة الأساسية ، بينما توفر "حالة الطلب المسبق" وصفًا لحالة البرنامج بعد تنفيذ الكتلة الأساسية.
عندما لا يواجه المترجم المجرد قفزة (أو حلقة) في الرسم البياني لتدفق التحكم ، فإنه يتبع مبدأ تنفيذ خطي بسيط: يتم تحليل كل كتلة أساسية بدورها ، ويتم حساب التعليمات السابقة وفقًا لدلالات كل تعليمة في حالة متسلسلة وحالة ما بعد التسلسل. والنتيجة هي لقطة دقيقة لحالة كل كتلة أساسية أثناء تنفيذ البرنامج ، مما يساعد على التحقق من خصائص أمان البرنامج.
سير عمل مترجم نقل مجردة
ومع ذلك ، تصبح العملية أكثر تعقيدًا عندما تكون هناك حلقات في تدفق التحكم. يعني ظهور الدورة أن الرسم البياني للتحكم في التدفق يحتوي على حافة قفزة للخلف. يتوافق مصدر الحافة الخلفية للقفز مع الحالة اللاحقة للكتلة الأساسية الحالية والكتلة الأساسية المستهدفة (رأس الحلقة) للقفزة- تم تحليل الحافة الخلفية مسبقًا لذلك ، يحتاج المفسر التجريدي إلى دمج حالات الكتلتين الأساسيتين المرتبطتين بالرجوع إلى الخلف بعناية.
إذا تم العثور على الحالة المدمجة لتكون مختلفة عن حالة الطلب المسبق الحالية للكتلة الأساسية لرأس الحلقة ، يقوم المترجم المجرد بتحديث حالة الكتلة الأساسية لرأس الحلقة ويعيد تشغيل التحليل بدءًا من هذه الكتلة الأساسية. ستستمر عملية التحليل التكراري هذه حتى تستقر الحلقة السابقة للحالة. بمعنى آخر ، تتكرر هذه العملية حتى لا تتغير حالة الطلب المسبق للكتلة الأساسية لرأس الحلقة بين التكرارات. يشير الوصول إلى نقطة ثابتة إلى اكتمال تحليل الدورة.
** مدقق Sui IDLeak: **
** تحليل تفسير مجردة مخصص **
على عكس تصميم Move الأصلي ، تقدم منصة Sui blockchain نموذج تخزين عالمي فريد من نوعه يتمحور حول "الهدف". الميزة البارزة لهذا النموذج هي: أي بنية بيانات ذات سمة رئيسية (مخزنة في السلسلة كفهرس) يجب أن يكون لها نوع المعرف باعتباره الحقل الأول للهيكل. حقل المعرف غير قابل للتغيير ولا يمكن نقله إلى كائنات أخرى ، حيث يجب أن يكون لكل كائن معرف فريد عالميًا. لضمان هذه الخصائص ، قامت Sui ببناء مجموعة من منطق التحليل المخصص أعلى المترجم المجرد.
مدقق IDLeak ، المعروف أيضًا باسم id \ _leak \ _verifier ، يعمل جنبًا إلى جنب مع المفسر المجرد للتحليل. وله نطاق AbstractDomain الفريد الخاص به ، والذي يسمى AbstractState. كل حالة مجردة تتكون من AbstractValue المقابلة لمتغيرات محلية متعددة. تتم مراقبة حالة كل متغير محلي بواسطة AbstractValue لتتبع ما إذا كان متغير المعرف جديدًا أم لا.
في عملية تعبئة الهيكل ، يسمح مدقق IDLeak فقط بتعبئة معرف جديد تمامًا في هيكل. من خلال تحليل تحليل التفسير الملخص ، يمكن لمدققي IDLeak تتبع حالة تدفق البيانات المحلية بشكل شامل لضمان عدم نقل أي معرفات حالية إلى كائنات أخرى ذات بنية.
** مشكلة عدم تناسق صيانة حالة أداة التحقق من صحة Sui IDLeak **
تم دمج مدقق IDLeak مع مترجم Move abstract عن طريق تنفيذ وظيفة AbstractState :: Join. تلعب هذه الوظيفة دورًا أساسيًا في إدارة الدولة ، لا سيما في دمج قيم الحالة وتحديثها.
افحص هذه الوظائف بالتفصيل لفهم عملها:
في AbstractState :: Join ، تأخذ الدالة AbstractState آخر كمدخل وتحاول دمج حالتها المحلية مع الحالة المحلية للكائن الحالي. لكل متغير محلي في حالة الإدخال ، فإنه يقارن قيمة هذا المتغير بقيمته الحالية في الحالة المحلية (افتراضيات إلى AbstractValue :: Other إذا لم يتم العثور عليه). إذا كانت القيمتان غير متساويتين ، فسيتم تعيين علامة "متغيرة" كأساس لما إذا كانت نتيجة دمج الحالة النهائية قد تغيرت ، وتحديث قيمة المتغير المحلي في الحالة المحلية عن طريق استدعاء AbstractValue :: Join.
في AbstractValue :: Join ، تقارن الدالة قيمتها مع قيمة AbstractValue أخرى. إذا كانت متساوية ، فستعيد القيمة التي تم تمريرها. في حالة عدم المساواة ، يتم عرض AbstractValue :: Other.
ومع ذلك ، يحتوي منطق صيانة الحالة هذا على مشكلة عدم تناسق خفية. على الرغم من أن AbstractState :: Join سيعيد نتيجة تشير إلى أن الحالة المدمجة قد تغيرت (JoinResult :: Changed) بناءً على الاختلاف بين القيم الجديدة والقديمة ، قد تظل قيمة الحالة المُحدثة المدمجة بدون تغيير.
سبب مشكلة عدم الاتساق هذه هو ترتيب العمليات: قرار تغيير الحالة في AbstractState :: Join يحدث قبل تحديث الحالة (AbstractValue :: Join) ، وهذا القرار لا يعكس نتيجة تحديث الحالة الحقيقية.
بالإضافة إلى ذلك ، في AbstractValue :: Join ، يلعب AbstractValue :: Other دورًا حاسمًا في نتيجة الدمج. على سبيل المثال ، إذا كانت القيمة القديمة هي AbstractValue :: Other وكانت القيمة الجديدة هي AbstractValue :: Fresh ، فإن قيمة الحالة المحدثة هي AbstractValue :: Other ، حتى لو كانت القيم القديمة والجديدة مختلفة ، تظل الحالة نفسها بدون تغيير بعد التحديث.
مثال: تناقض الاتصالات ذات الحالة
يؤدي هذا إلى عدم الاتساق: يتم الحكم على نتيجة دمج حالة الكتلة الأساسية على أنها "متغيرة" ، لكن قيمة الحالة المدمجة نفسها لم تتغير. في عملية تحليل التفسير المجرد ، قد يكون لمثل هذه التناقضات عواقب وخيمة. نقوم بمراجعة سلوك المترجم الفوري عندما تحدث دورة في رسم بياني للتحكم (CFG):
عند مواجهة حلقة ، يستخدم المترجم المجرد طريقة تحليل تكرارية لدمج حالة الكتلة الأساسية المستهدفة للرجوع للخلف والكتلة الأساسية الحالية. إذا تغيرت الحالة المدمجة ، فسيعيد المترجم المجرد التحليل بدءًا من هدف الانتقال.
ومع ذلك ، إذا كانت عملية الدمج لتحليل التفسير المجرد تشير خطأً إلى نتيجة دمج الحالة على أنها "تغيير" ، بينما في الواقع لم تتغير قيمة المتغير الداخلي للحالة ، سيؤدي ذلك إلى إعادة تحليل لا نهاية لها ، مما يؤدي إلى حلقة لا نهائية.
** مزيد من استغلال التناقضات **
** تفعّل حلقة لا نهائية في أداة التحقق Sui IDLeak **
باستغلال هذا التناقض ، يمكن للمهاجم إنشاء رسم بياني للتحكم الضار يخدع مدققي IDLeak في حلقة لا نهائية. يتكون مخطط تدفق التحكم هذا الذي تم إنشاؤه بعناية من ثلاث كتل أساسية: BB1 و BB2 و BB3. تجدر الإشارة إلى أننا قدمنا عمدًا حافة قفزة خلفية من BB3 إلى BB2 لإنشاء حلقة.
يمكن أن تؤدي حالة CFG + الضارة إلى حلقة داخلية لا نهائية في مدقق IDLeak
تبدأ العملية بـ BB2 ، حيث يتم تعيين AbstractValue لمتغير محلي معين على :: Other. بعد تنفيذ BB2 ، ينتقل التدفق إلى BB3 حيث يتم تعيين نفس المتغير على :: Fresh. في نهاية BB3 ، توجد حافة قفزة خلفية ، تقفز إلى BB2.
تلعب التناقضات المذكورة أعلاه دورًا رئيسيًا في التفسير المجرد لهذا المثال. عند معالجة حافة الانتقال الخلفي ، يحاول المترجم المجرد توصيل حالة الطلب البريدي BB3 (مع المتغير ":: Fresh") بحالة الطلب المسبق لـ BB2 (مع المتغير ":: Other"). تلاحظ دالة AbstractState :: Join الفرق بين القيم القديمة والجديدة وتعين علامة "change" للإشارة إلى أن BB2 بحاجة إلى إعادة تحليل.
ومع ذلك ، فإن السلوك السائد لـ ":: Other" في AbstractValue :: Join يعني أنه بعد دمج AbstractValue ، تظل القيمة الفعلية لمتغير الحالة BB2 ":: Other" ، ولم تتغير نتيجة دمج الحالة .
لذلك بمجرد أن تبدأ هذه العملية الدورية ، أي مع استمرار المدققين في إعادة تحليل BB2 وجميع عقد الكتلة الأساسية اللاحقة (BB3 في هذه الحالة) ، فإنها تستمر إلى أجل غير مسمى. تستهلك الحلقة اللانهائية جميع دورات وحدة المعالجة المركزية المتاحة ، مما يجعلها غير قادرة على معالجة المعاملات الجديدة والاستجابة لها ، والتي تستمر عبر عمليات إعادة تشغيل المدقق.
من خلال استغلال هذه الثغرة الأمنية ، تعمل عقد التحقق إلى ما لا نهاية مثل الهامستر على عجلة في حلقة لا نهائية ، غير قادرة على معالجة المعاملات الجديدة. لذلك نشير إلى هذا النوع الفريد من الهجوم على أنه هجوم "عجلة الهامستر".
يمكن أن يؤدي هجوم "عجلة الهامستر" بشكل فعال إلى توقف المدققين Sui ، والذي بدوره يمكن أن يؤدي إلى انهيار شبكة Sui بأكملها.
بعد فهم سبب الثغرة الأمنية وعملية التشغيل ، قمنا ببناء مثال ملموس باستخدام محاكاة Move bytecode التالية وأطلقنا بنجاح الثغرة الأمنية في المحاكاة في البيئة الحقيقية:
يوضح هذا المثال كيفية تشغيل الثغرة الأمنية في بيئة حقيقية من خلال رمز ثنائي تم إنشاؤه بعناية. على وجه التحديد ، يمكن للمهاجم تشغيل حلقة لا نهائية في مدقق IDLeak ، مما يؤدي إلى استهلاك جميع دورات وحدة المعالجة المركزية لعقدة Sui بحمولة تبلغ حوالي 100 بايت فقط ، مما يمنع بشكل فعال معالجة المعاملات الجديدة ويتسبب في رفض الخدمة على شبكة Sui.
** هجوم "عجلة الهامستر" يواصل الإضرار بشبكة سوي **
يحتوي برنامج مكافأة الأخطاء في سوي على لوائح صارمة بشأن تقييم مستويات الضعف ، تعتمد بشكل أساسي على درجة الضرر الذي يلحق بالشبكة بأكملها. يجب أن تغلق نقاط الضعف التي تلبي التصنيف "الحرج" الشبكة بالكامل وتمنع بشكل فعال تأكيدات المعاملات الجديدة ، وتتطلب شوكة صلبة لإصلاح المشكلة ؛ (متوسطة) "أو نقاط ضعف" عالية الخطورة (عالية) ".
يمكن لثغرة "عجلة الهامستر" التي اكتشفها فريق CertiK Skyfall أن تغلق شبكة Sui بأكملها ، وتتطلب إصدارًا رسميًا من إصدار جديد للترقية والإصلاح. صنفت Sui في النهاية الثغرة بأنها "حرجة" بناءً على أهميتها. من أجل فهم التأثير الخطير الناجم عن هجوم "عجلة الهامستر" ، من الضروري بالنسبة لنا أن نفهم البنية المعقدة لنظام الواجهة الخلفية لـ Sui ، وخاصة العملية الكاملة لنشر أو ترقية المعاملات على السلسلة.
نظرة عامة على التفاعلات لإرسال المعاملات في Sui
في البداية ، يتم إرسال معاملات المستخدم عبر RPC للواجهة الأمامية وتمريرها إلى الخدمات الخلفية بعد التحقق الأساسي. خدمة Sui الخلفية مسؤولة عن التحقق من صحة حمولات المعاملات الواردة. بعد التحقق من توقيع المستخدم بنجاح ، يتم تحويل المعاملة إلى شهادة معاملة (تحتوي على معلومات المعاملة وتوقيع Sui).
تعتبر شهادات المعاملات هذه جزءًا أساسيًا من تشغيل شبكة Sui ويمكن نشرها بين مختلف عقد التحقق في الشبكة. بالنسبة لمعاملات إنشاء / ترقية العقد ، قبل أن يتم تحميلها إلى السلسلة ، ستتصل عقدة التحقق بمدقق Sui للتحقق والتحقق من صحة بنية العقد / دلالات هذه الشهادات. خلال مرحلة التحقق الحرجة هذه يمكن تشغيل واستغلال ثغرة "الحلقة اللانهائية".
عندما تم تشغيل الثغرة الأمنية ، تسببت في مقاطعة عملية التحقق إلى أجل غير مسمى ، مما أعاق بشكل فعال قدرة النظام على معالجة المعاملات الجديدة وتسبب في إغلاق الشبكة بالكامل. لزيادة الطين بلة ، استمر الوضع بعد إعادة تشغيل العقدة ، مما يعني أن وسائل التخفيف التقليدية كانت بعيدة عن أن تكون كافية. بمجرد تشغيل الثغرة الأمنية ، سيكون هناك "ضرر مستمر" وترك تأثير دائم على شبكة Sui بأكملها.
** حل سوي **
بعد ردود الفعل من CertiK ، أكدت Sui الثغرة الأمنية في الوقت المناسب وأصدرت إصلاحًا لمعالجة الخلل الخطير. يضمن الإصلاح الاتساق بين تغييرات الحالة وأعلام ما بعد التغيير ، مما يزيل التأثير الحرج لهجوم "عجلة الهامستر".
لإزالة التضارب المذكور أعلاه ، يتضمن إصلاح Sui تعديلًا صغيرًا ولكنه حاسم في وظيفة AbstractState :: Join. يزيل هذا التصحيح منطق تحديد نتيجة دمج الحالة قبل تنفيذ AbstractValue :: Join. بدلاً من ذلك ، قم بتنفيذ دالة AbstractValue :: Join لدمج الحالة أولاً ، وقم بتعيين الدمج عن طريق مقارنة نتيجة التحديث النهائية مع قيمة الحالة الأصلية (القديمة \ _value) علامة للتغييرات.
بهذه الطريقة ، ستكون نتيجة دمج الحالة متسقة مع نتيجة التحديث الحقيقي ، ولن تحدث حلقة لا نهائية أثناء عملية التحليل.
بالإضافة إلى إصلاح هذه الثغرة الأمنية المحددة ، قامت Sui أيضًا بنشر عوامل التخفيف لتقليل تأثير الثغرات الأمنية في أداة التحقق المستقبلية. وفقًا لاستجابة Sui في تقرير الخطأ ، يتضمن التخفيف ميزة تسمى Denylist.
"ومع ذلك ، لدى المدققين ملف تكوين عقدة يسمح لهم برفض فئات معينة من المعاملات مؤقتًا. يمكن استخدام هذا التكوين لتعطيل معالجة الإصدارات وترقيات الحزمة مؤقتًا. نظرًا لهذا الخطأ ، يتم تشغيل Sui قبل التوقيع على إصدار أو ترقية حزمة tx المدققين ، في حين أن denylist سيوقف المدقق من التشغيل وإسقاط tx الضار ، فإن رفض هذه الأنواع tx مؤقتًا هو تخفيف فعال بنسبة 100٪ (على الرغم من أنه سيعطل الخدمة مؤقتًا للأشخاص الذين يحاولون إصدار أو ترقية التعليمات البرمجية).
بالمناسبة ، لدينا ملف تكوين قائمة رفض TX هذا لفترة من الوقت الآن ، ولكننا أضفنا أيضًا آلية مماثلة للشهادات كتخفيف متابعة لثغرة "حلقة التحقق من الصحة" التي تم الإبلاغ عنها مسبقًا. باستخدام هذه الآلية ، سيكون لدينا المزيد من المرونة ضد هذا الهجوم: سنستخدم تكوين قائمة رفض الشهادات لجعل المدققين ينسون الشهادات السيئة (كسر الحلقة اللانهائية) ، وتكوين قائمة رفض TX لحظر النشر / الترقيات ، وبالتالي منع إنشاء عمليات هجوم ضار جديدة. شكرا لجعلنا نفكر في هذا!
لدى المدقق عدد محدود من "العلامات" (تختلف عن الغاز) للتحقق من الرمز الثانوي قبل توقيع المعاملة ، وإذا تعذر التحقق من جميع الرموز الثانوية الصادرة في المعاملة في هذه العلامات العديدة ، سيرفض المدقق التوقيع على المعاملة ، مما يمنع من التنفيذ على الشبكة. في السابق ، تم تطبيق القياس فقط على مجموعة محددة من ممرات المدقق المعقدة. لمكافحة هذا ، نمد القياس إلى كل مدقق لضمان وجود قيد على العمل الذي يؤديه المدقق أثناء عملية التحقق من كل علامة. لقد أصلحنا أيضًا خطأ حلقة لانهائية محتملة في أداة التحقق من تسرب المعرف. "
*** - شرح من مطوري Sui حول إصلاحات الأخطاء ***
بشكل عام ، يمكّن Denylist المدققين من تجنب استغلال نقاط الضعف في أدوات التحقق مؤقتًا ومنع الضرر المحتمل الناجم عن بعض المعاملات الضارة بشكل فعال عن طريق تعطيل عملية الإصدار أو الترقية. عندما تدخل تدابير التخفيف الخاصة بـ Denylist حيز التنفيذ ، تضمن العقد قدرتها على الاستمرار في العمل من خلال التضحية بوظائف النشر / التحديث الخاصة بها.
لخص
في هذه المقالة ، نشارك التفاصيل الفنية لهجوم "Hamster Wheel" الذي اكتشفه فريق CertiK Skyfall ، وشرح كيف يستغل هذا النوع الجديد من الهجوم نقاط الضعف الرئيسية للتسبب في إغلاق كامل لشبكة Sui. بالإضافة إلى ذلك ، قمنا أيضًا بدراسة استجابة Sui في الوقت المناسب لإصلاح هذه المشكلة الحرجة ، وشاركنا إصلاح الثغرات الأمنية وأساليب التخفيف اللاحقة لنقاط الضعف المماثلة.