بعد قراءة تقرير "استعراض" الهجوم السيبراني على @CetusProtocol، ستجد ظاهرة "تستحق التأمل": تفاصيل التقنية تم الكشف عنها بشفافية عالية، والاستجابة الطارئة كانت على مستوى كتب التعليم، ولكن في السؤال الأكثر أهمية "لماذا تم الاختراق"، يبدو أن التقرير يتجنب النقاط الجوهرية.
تقرير يشرح بشكل موسع وظيفة checked\_shlw في مكتبة integer-mate للتحقق من الأخطاء (يجب أن تكون ≤2^192، بينما الفعلية ≤2^256)، ويعتبر هذا خطأً نوعياً "سوء فهم دلالي". على الرغم من أن هذا الوصف صحيح من الناحية الفنية، إلا أنه يوجه التركيز بذكاء نحو المسؤولية الخارجية، كما لو أن Cetus كان أيضاً ضحية غير مذنبة لهذا العيب الفني.
المشكلة هنا، بما أن integer-mate هو مكتبة رياضية مفتوحة المصدر ومستخدمة على نطاق واسع، كيف حدثت هذه الخطأ السخيف الذي يمكن من خلاله الحصول على حصة ضخمة من السيولة مقابل 1 توكن فقط؟
من خلال تحليل مسارات هجمات الهاكر، يمكننا أن نرى أنه يجب على الهاكر تلبية أربعة شروط لتحقيق هجوم مثالي: فحص الفائض الخاطئ، عمليات الإزاحة الكبيرة، قواعد التقريب للأعلى، ونقص التحقق من الجدوى الاقتصادية.
Cetus أهمل تمامًا في كل شرط "التحفيز"، على سبيل المثال: قبول إدخال المستخدم لرقم فلكي مثل 2^200، واستخدام عمليات إزاحة كبيرة خطيرة للغاية، والثقة الكاملة في آلية الفحص الخاصة بالمكتبات الخارجية، والأخطر من ذلك—عندما حسب النظام "1 توكن مقابل حصة باهظة الثمن" مثل هذه النتيجة السخيفة، لم يكن هناك أي فحص للمعرفة الاقتصادية وتم تنفيذ ذلك مباشرة.
لذا، يجب على Cetus أن تفكر بجدية في النقاط التالية:
لماذا لا أقوم بإجراء اختبار الأمان عند استخدام مكتبات خارجية شائعة؟ على الرغم من أن مكتبة "العدد الصحيح" مفتوحة المصدر وشائعة ومستخدمة على نطاق واسع ، إلا أن Cetus تستخدمها لإدارة مئات الملايين من الدولارات من الأصول دون فهم كامل لمكان الحدود الأمنية للمكتبة ، وما إذا كانت هناك بدائل مناسبة إذا فشلت المكتبة ، وما إلى ذلك. من الواضح أن Cetus تفتقر إلى أبسط وعي أمني لسلسلة التوريد.
لماذا يُسمح بإدخال أرقام فلكية دون تحديد حدود؟ على الرغم من أن بروتوكولات DeFi يجب أن تسعى إلى اللامركزية، إلا أن النظام المالي الناضج كلما كان أكثر انفتاحًا كان يحتاج إلى حدود واضحة.
عندما يسمح النظام بإدخال أرقام فلكية تم بناؤها بعناية من قبل المهاجمين، من الواضح أن الفريق لم يفكر في ما إذا كانت هذه الحاجة إلى السيولة معقولة. حتى أكبر صناديق التحوط في العالم لا يمكن أن تحتاج إلى هذه الحصة المبالغ فيها من السيولة. من الواضح أن فريق Cetus يفتقر إلى مواهب إدارة المخاطر التي تتمتع بحدس مالي؛
لماذا لم يتم اكتشاف المشكلة مسبقًا على الرغم من جولات متعددة من التدقيق الأمني؟ هذه الجملة تكشف عن سوء فهم قاتل: يعتقد الفريق المسؤول عن المشروع أنهم قد سلموا مسؤولية الأمان لشركة الأمان، ويعتبرون التدقيق كأنه بطاقة إعفاء من المسؤولية. لكن الواقع قاسٍ: مهندسو التدقيق الأمني بارعون في اكتشاف أخطاء الشيفرة، من سيفكر في اختبار النظام لحساب نسبة التبادل الغريبة التي قد تكون غير صحيحة؟
إن التحقق من الحدود بين الرياضيات، والتشفير، والاقتصاد هو أكبر منطقة عمياء في أمان DeFi الحديث. ستقول شركات التدقيق "هذه عيوب في تصميم النموذج الاقتصادي، وليست مشكلة منطقية في الشيفرة"؛ بينما يشتكي المشروع "لم يكتشف التدقيق أي مشاكل"؛ والمستخدمون فقط يعرفون أن أموالهم قد ضاعت!
ترى، في نهاية المطاف، يكشف ذلك عن نقاط الضعف النظامية في مجال DeFi: الفرق ذات الخلفية التقنية البحتة تفتقر بشدة إلى "حاسة المراقبة المالية" الأساسية.
ومن تقرير Cetus، يتضح أن الفريق لم يعكس الأمور بشكل كافٍ.
بدلاً من التركيز فقط على العيوب التقنية المتعلقة بالهجوم هاكر الأخير، أعتقد أنه يجب على جميع فرق DeFi بدءًا من Cetus أن تتخلى عن حدود التفكير التقني البحت، وأن تنمي حقًا وعي مخاطر الأمان لدى "مهندسي المال".
على سبيل المثال: إدخال خبراء في إدارة المخاطر المالية لسد الفجوات المعرفية في فريق التقنية؛ إجراء آلية مراجعة تدقيق متعددة الأطراف، لا تقتصر فقط على تدقيق الشيفرة، بل يجب أيضًا إضافة تدقيق النماذج الاقتصادية عند الضرورة؛培养「الحس المالي」، محاكاة سيناريوهات الهجوم المختلفة وتدابير الاستجابة المناسبة، والحفاظ على حساسية تجاه العمليات غير الطبيعية في جميع الأوقات.
هذا يذكرني بتجربتي السابقة في شركات الأمان، بما في ذلك توافق كبار الشخصيات في الصناعة مثل @evilcos، @chiachih_wu، @yajinzhou، و@mikelee205 في هذا الأمر:
مع نضوج الصناعة بشكل متزايد، ستقل مشاكل الأخطاء التقنية على مستوى الكود، لكن "أخطاء الوعي" في المنطق التجاري الذي ليس له حدود واضحة أو مسؤوليات غامضة ستظل التحدي الأكبر.
لا يمكن لشركة التدقيق ضمان خلو الشيفرة من الأخطاء، ولكن كيف يمكن تحقيق "حدود المنطق" يتطلب من فريق المشروع فهمًا أعمق لطبيعة العمل وقدرة على التحكم في الحدود. (السبب الجذري للعديد من "حوادث إلقاء اللوم" بعد عمليات التدقيق الأمني التي تعرضت للاختراق لا يزال هنا)
مستقبل DeFi ينتمي إلى الفرق التي تتمتع بمهارات تقنية قوية في البرمجة، وفي نفس الوقت فهم عميق للمنطق التجاري!
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
ما الدروس التي يمكن أن نستخلصها من حادثة Cetus التي أدت إلى سرقة أكثر من 200 مليون دولار؟
بعد قراءة تقرير "استعراض" الهجوم السيبراني على @CetusProtocol، ستجد ظاهرة "تستحق التأمل": تفاصيل التقنية تم الكشف عنها بشفافية عالية، والاستجابة الطارئة كانت على مستوى كتب التعليم، ولكن في السؤال الأكثر أهمية "لماذا تم الاختراق"، يبدو أن التقرير يتجنب النقاط الجوهرية.
تقرير يشرح بشكل موسع وظيفة
checked\_shlw
في مكتبةinteger-mate
للتحقق من الأخطاء (يجب أن تكون ≤2^192، بينما الفعلية ≤2^256)، ويعتبر هذا خطأً نوعياً "سوء فهم دلالي". على الرغم من أن هذا الوصف صحيح من الناحية الفنية، إلا أنه يوجه التركيز بذكاء نحو المسؤولية الخارجية، كما لو أن Cetus كان أيضاً ضحية غير مذنبة لهذا العيب الفني.المشكلة هنا، بما أن
integer-mate
هو مكتبة رياضية مفتوحة المصدر ومستخدمة على نطاق واسع، كيف حدثت هذه الخطأ السخيف الذي يمكن من خلاله الحصول على حصة ضخمة من السيولة مقابل 1 توكن فقط؟من خلال تحليل مسارات هجمات الهاكر، يمكننا أن نرى أنه يجب على الهاكر تلبية أربعة شروط لتحقيق هجوم مثالي: فحص الفائض الخاطئ، عمليات الإزاحة الكبيرة، قواعد التقريب للأعلى، ونقص التحقق من الجدوى الاقتصادية.
Cetus أهمل تمامًا في كل شرط "التحفيز"، على سبيل المثال: قبول إدخال المستخدم لرقم فلكي مثل 2^200، واستخدام عمليات إزاحة كبيرة خطيرة للغاية، والثقة الكاملة في آلية الفحص الخاصة بالمكتبات الخارجية، والأخطر من ذلك—عندما حسب النظام "1 توكن مقابل حصة باهظة الثمن" مثل هذه النتيجة السخيفة، لم يكن هناك أي فحص للمعرفة الاقتصادية وتم تنفيذ ذلك مباشرة.
لذا، يجب على Cetus أن تفكر بجدية في النقاط التالية:
لماذا لا أقوم بإجراء اختبار الأمان عند استخدام مكتبات خارجية شائعة؟ على الرغم من أن مكتبة "العدد الصحيح" مفتوحة المصدر وشائعة ومستخدمة على نطاق واسع ، إلا أن Cetus تستخدمها لإدارة مئات الملايين من الدولارات من الأصول دون فهم كامل لمكان الحدود الأمنية للمكتبة ، وما إذا كانت هناك بدائل مناسبة إذا فشلت المكتبة ، وما إلى ذلك. من الواضح أن Cetus تفتقر إلى أبسط وعي أمني لسلسلة التوريد.
لماذا يُسمح بإدخال أرقام فلكية دون تحديد حدود؟ على الرغم من أن بروتوكولات DeFi يجب أن تسعى إلى اللامركزية، إلا أن النظام المالي الناضج كلما كان أكثر انفتاحًا كان يحتاج إلى حدود واضحة.
عندما يسمح النظام بإدخال أرقام فلكية تم بناؤها بعناية من قبل المهاجمين، من الواضح أن الفريق لم يفكر في ما إذا كانت هذه الحاجة إلى السيولة معقولة. حتى أكبر صناديق التحوط في العالم لا يمكن أن تحتاج إلى هذه الحصة المبالغ فيها من السيولة. من الواضح أن فريق Cetus يفتقر إلى مواهب إدارة المخاطر التي تتمتع بحدس مالي؛
إن التحقق من الحدود بين الرياضيات، والتشفير، والاقتصاد هو أكبر منطقة عمياء في أمان DeFi الحديث. ستقول شركات التدقيق "هذه عيوب في تصميم النموذج الاقتصادي، وليست مشكلة منطقية في الشيفرة"؛ بينما يشتكي المشروع "لم يكتشف التدقيق أي مشاكل"؛ والمستخدمون فقط يعرفون أن أموالهم قد ضاعت!
ترى، في نهاية المطاف، يكشف ذلك عن نقاط الضعف النظامية في مجال DeFi: الفرق ذات الخلفية التقنية البحتة تفتقر بشدة إلى "حاسة المراقبة المالية" الأساسية.
ومن تقرير Cetus، يتضح أن الفريق لم يعكس الأمور بشكل كافٍ.
بدلاً من التركيز فقط على العيوب التقنية المتعلقة بالهجوم هاكر الأخير، أعتقد أنه يجب على جميع فرق DeFi بدءًا من Cetus أن تتخلى عن حدود التفكير التقني البحت، وأن تنمي حقًا وعي مخاطر الأمان لدى "مهندسي المال".
على سبيل المثال: إدخال خبراء في إدارة المخاطر المالية لسد الفجوات المعرفية في فريق التقنية؛ إجراء آلية مراجعة تدقيق متعددة الأطراف، لا تقتصر فقط على تدقيق الشيفرة، بل يجب أيضًا إضافة تدقيق النماذج الاقتصادية عند الضرورة؛培养「الحس المالي」، محاكاة سيناريوهات الهجوم المختلفة وتدابير الاستجابة المناسبة، والحفاظ على حساسية تجاه العمليات غير الطبيعية في جميع الأوقات.
هذا يذكرني بتجربتي السابقة في شركات الأمان، بما في ذلك توافق كبار الشخصيات في الصناعة مثل @evilcos، @chiachih_wu، @yajinzhou، و@mikelee205 في هذا الأمر:
مع نضوج الصناعة بشكل متزايد، ستقل مشاكل الأخطاء التقنية على مستوى الكود، لكن "أخطاء الوعي" في المنطق التجاري الذي ليس له حدود واضحة أو مسؤوليات غامضة ستظل التحدي الأكبر.
لا يمكن لشركة التدقيق ضمان خلو الشيفرة من الأخطاء، ولكن كيف يمكن تحقيق "حدود المنطق" يتطلب من فريق المشروع فهمًا أعمق لطبيعة العمل وقدرة على التحكم في الحدود. (السبب الجذري للعديد من "حوادث إلقاء اللوم" بعد عمليات التدقيق الأمني التي تعرضت للاختراق لا يزال هنا)
مستقبل DeFi ينتمي إلى الفرق التي تتمتع بمهارات تقنية قوية في البرمجة، وفي نفس الوقت فهم عميق للمنطق التجاري!