الفريق ذو الخلفية التقنية البحتة يفتقر بشدة إلى «حس المخاطر المالية» الأساسي.
كتبه: هاوتيان
بعد قراءة تقرير "تحليل" هجوم القرصنة الخاص بـ @CetusProtocol، ستكتشف ظاهرة "تستحق التأمل": تفاصيل التقنية تم الكشف عنها بشفافية كبيرة، والاستجابة الطارئة تعتبر بمثابة مستوى تعليمي، لكن في السؤال الأكثر أهمية "لماذا تعرضنا للاختراق"، يبدو أنهم يتجنبون النقطة الرئيسية:
التقرير يشرح بشكل موسع وظيفة checked\_shlw لمكتبة integer-mate لفحص الأخطاء (يجب أن تكون ≤2^192، والواقع ≤2^256)، ويصنف هذا على أنه "سوء فهم دلالي". على الرغم من أن هذا الوصف صحيح من الناحية التقنية، إلا أنه يوجه التركيز بذكاء نحو المسؤولية الخارجية، كما لو أن Cetus هو أيضًا ضحية غير مذنبة لهذه العيب الفني.
المشكلة هنا هي أنه بما أن integer-mate هو مكتبة رياضية مفتوحة المصدر ومستخدمة على نطاق واسع، لماذا حدث خطأ سخيف حيث يمكنك الحصول على حصة ضخمة من السيولة مقابل 1 توكن فقط؟
عند تحليل مسار الهجمات الإلكترونية، يتبين أن الهكر يجب أن يستوفي أربعة شروط لتحقيق هجوم مثالي: فحص تجاوز خاطئ، عمليات إزاحة كبيرة، قواعد التقريب لأعلى، ونقص في التحقق من الجدوى الاقتصادية.
لقد كانت Cetus متساهلة في كل شرط من شروط "التفعيل"، على سبيل المثال: قبول إدخال المستخدم لرقم فلكي مثل 2^200، واستخدام عمليات إزاحة كبيرة للغاية بطريقة خطيرة للغاية، والثقة الكاملة في آلية الفحص للمكتبات الخارجية، والأخطر من ذلك - عندما يحسب النظام "1 توكن مقابل حصة باهظة الثمن" وهو نتيجة سخيفة، لم يكن هناك أي فحص للمعرفة الاقتصادية وتم التنفيذ مباشرة.
لذلك، النقاط التي يجب أن تعيد Cetus التفكير فيها هي كما يلي:
لماذا لم يتم إجراء اختبارات أمان كافية لاستخدام المكتبات الخارجية العامة؟ على الرغم من أن مكتبة integer-mate تتمتع بخصائص مثل المصدر المفتوح، والشعبية، والاستخدام الواسع، إلا أن Cetus تستخدمها لإدارة أصول تزيد عن مئات الملايين من الدولارات دون أن تفهم تمامًا حدود أمان هذه المكتبة، وما إذا كان هناك بديل مناسب في حالة فشل وظيفة المكتبة، وما إلى ذلك. من الواضح أن Cetus تفتقر إلى الوعي الأساسي بحماية سلسلة الإمداد.
لماذا يُسمح بإدخال أرقام فلكية دون وضع حدود؟ على الرغم من أن بروتوكولات DeFi يجب أن تسعى إلى اللامركزية، إلا أن النظام المالي الناضج كلما كان أكثر انفتاحًا كلما كان يحتاج إلى حدود واضحة.
عندما تسمح النظام بإدخال أرقام فلكية تم تصميمها بعناية من قبل المهاجمين، من الواضح أن الفريق لم يفكر في ما إذا كانت حاجة السيولة هذه معقولة؟ حتى أكبر صناديق التحوط في العالم لا يمكن أن تحتاج إلى حصة سيولة مبالغ فيها بهذا الشكل. من الواضح أن فريق Cetus يفتقر إلى المواهب في إدارة المخاطر التي تمتلك حدسًا ماليًا؛
لماذا لا توجد مشكلة حتى الآن مقدما بعد جولات متعددة من عمليات التدقيق الأمنية؟ تكشف هذه الجملة عن غير قصد سوء فهم معرفي قاتل: يقوم فريق المشروع بالاستعانة بمصادر خارجية للمسؤولية الأمنية لشركة الأمن ، ويعتبر التدقيق ميدالية ذهبية للإعفاء. لكن الحقيقة قاسية: مهندسو التدقيق الأمني جيدون في العثور على أخطاء التعليمات البرمجية ، ومن كان يظن أنه قد يكون من الخطأ اختبار النظام لحساب نسبة التبادل الخيالية؟
إن التحقق عبر الحدود بين الرياضيات وعلم التشفير والاقتصاد هو أكبر منطقة عمياء في أمان DeFi الحديث. ستقول شركات التدقيق "هذه عيوب في تصميم النموذج الاقتصادي، وليست مشكلة في منطق الكود"؛ بينما تشتكي الفرق المشروع "لم تكتشف التدقيق أي مشاكل"؛ بينما يعرف المستخدمون فقط أن أموالهم قد اختفت!
انظر، في النهاية، يكشف هذا عن الثغرات النظامية في صناعة DeFi: الفرق ذات الخلفية التقنية البحتة تفتقر بشدة إلى "حاسة المخاطر المالية" الأساسية.
ومن خلال تقرير Cetus، من الواضح أن الفريق لم يقم بالتفكير الكافي.
بدلاً من التركيز فقط على عيوب التقنية في الهجوم الإلكتروني الحالي، أشعر أنه يجب على جميع فرق DeFi بدءًا من Cetus أن تتجاوز قيود التفكير الفني البحت، وأن تنمي بالفعل الوعي بمخاطر الأمان لدى "مهندسي المالية".
على سبيل المثال ، إدخال خبراء في مراقبة المخاطر المالية للتعويض عن النقاط العمياء المعرفية للفريق الفني ؛ تنفيذ آلية مراجعة متعددة الأطراف ، ليس فقط للنظر في تدقيق المدونة ، ولكن أيضا لتشكيل مراجعة النموذج الاقتصادي اللازم. تنمية "الحس المالي" ، ومحاكاة سيناريوهات الهجوم المختلفة والإجراءات المضادة المقابلة ، وكن حساسا للعمليات غير الطبيعية في جميع الأوقات.
هذا يذكرني بتجربتي السابقة في الشركات الأمنية، بما في ذلك النقاشات مع عمالقة الأمن في الصناعة مثل @evilcos، @chiachih_wu، @yajinzhou، و@mikelee205 الذين كان لديهم هذا الإجماع:
مع نضوج الصناعة بشكل متزايد، ستقل مشاكل الأخطاء التقنية على مستوى الكود، لكن "أخطاء الوعي" في منطق العمل الذي يفتقر إلى الحدود الواضحة والمسؤوليات الغامضة ستكون التحدي الأكبر.
يمكن لشركات التدقيق التأكد من أن الكود خالي من الأخطاء، ولكن كيفية تحقيق "حدود المنطق" تتطلب من فريق المشروع فهمًا أعمق لطبيعة العمل وقدرة على التحكم في الحدود. (السبب الجذري للعديد من حوادث "إلقاء اللوم" بعد تدقيقات الأمان السابقة التي لا تزال تتعرض للاختراق من قبل القراصنة هو هذا)
مستقبل DeFi ينتمي إلى الفرق التي تتمتع بمهارات تقنية قوية في البرمجة، وفي نفس الوقت فهم عميق لمنطق الأعمال!
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
مشكلة أمان Cetus: ماذا يجب على فريق التمويل اللامركزي الانتباه إليه؟
كتبه: هاوتيان
بعد قراءة تقرير "تحليل" هجوم القرصنة الخاص بـ @CetusProtocol، ستكتشف ظاهرة "تستحق التأمل": تفاصيل التقنية تم الكشف عنها بشفافية كبيرة، والاستجابة الطارئة تعتبر بمثابة مستوى تعليمي، لكن في السؤال الأكثر أهمية "لماذا تعرضنا للاختراق"، يبدو أنهم يتجنبون النقطة الرئيسية:
التقرير يشرح بشكل موسع وظيفة
checked\_shlwلمكتبةinteger-mateلفحص الأخطاء (يجب أن تكون ≤2^192، والواقع ≤2^256)، ويصنف هذا على أنه "سوء فهم دلالي". على الرغم من أن هذا الوصف صحيح من الناحية التقنية، إلا أنه يوجه التركيز بذكاء نحو المسؤولية الخارجية، كما لو أن Cetus هو أيضًا ضحية غير مذنبة لهذه العيب الفني.المشكلة هنا هي أنه بما أن
integer-mateهو مكتبة رياضية مفتوحة المصدر ومستخدمة على نطاق واسع، لماذا حدث خطأ سخيف حيث يمكنك الحصول على حصة ضخمة من السيولة مقابل 1 توكن فقط؟عند تحليل مسار الهجمات الإلكترونية، يتبين أن الهكر يجب أن يستوفي أربعة شروط لتحقيق هجوم مثالي: فحص تجاوز خاطئ، عمليات إزاحة كبيرة، قواعد التقريب لأعلى، ونقص في التحقق من الجدوى الاقتصادية.
لقد كانت Cetus متساهلة في كل شرط من شروط "التفعيل"، على سبيل المثال: قبول إدخال المستخدم لرقم فلكي مثل 2^200، واستخدام عمليات إزاحة كبيرة للغاية بطريقة خطيرة للغاية، والثقة الكاملة في آلية الفحص للمكتبات الخارجية، والأخطر من ذلك - عندما يحسب النظام "1 توكن مقابل حصة باهظة الثمن" وهو نتيجة سخيفة، لم يكن هناك أي فحص للمعرفة الاقتصادية وتم التنفيذ مباشرة.
لذلك، النقاط التي يجب أن تعيد Cetus التفكير فيها هي كما يلي:
لماذا لم يتم إجراء اختبارات أمان كافية لاستخدام المكتبات الخارجية العامة؟ على الرغم من أن مكتبة
integer-mateتتمتع بخصائص مثل المصدر المفتوح، والشعبية، والاستخدام الواسع، إلا أن Cetus تستخدمها لإدارة أصول تزيد عن مئات الملايين من الدولارات دون أن تفهم تمامًا حدود أمان هذه المكتبة، وما إذا كان هناك بديل مناسب في حالة فشل وظيفة المكتبة، وما إلى ذلك. من الواضح أن Cetus تفتقر إلى الوعي الأساسي بحماية سلسلة الإمداد.لماذا يُسمح بإدخال أرقام فلكية دون وضع حدود؟ على الرغم من أن بروتوكولات DeFi يجب أن تسعى إلى اللامركزية، إلا أن النظام المالي الناضج كلما كان أكثر انفتاحًا كلما كان يحتاج إلى حدود واضحة.
عندما تسمح النظام بإدخال أرقام فلكية تم تصميمها بعناية من قبل المهاجمين، من الواضح أن الفريق لم يفكر في ما إذا كانت حاجة السيولة هذه معقولة؟ حتى أكبر صناديق التحوط في العالم لا يمكن أن تحتاج إلى حصة سيولة مبالغ فيها بهذا الشكل. من الواضح أن فريق Cetus يفتقر إلى المواهب في إدارة المخاطر التي تمتلك حدسًا ماليًا؛
إن التحقق عبر الحدود بين الرياضيات وعلم التشفير والاقتصاد هو أكبر منطقة عمياء في أمان DeFi الحديث. ستقول شركات التدقيق "هذه عيوب في تصميم النموذج الاقتصادي، وليست مشكلة في منطق الكود"؛ بينما تشتكي الفرق المشروع "لم تكتشف التدقيق أي مشاكل"؛ بينما يعرف المستخدمون فقط أن أموالهم قد اختفت!
انظر، في النهاية، يكشف هذا عن الثغرات النظامية في صناعة DeFi: الفرق ذات الخلفية التقنية البحتة تفتقر بشدة إلى "حاسة المخاطر المالية" الأساسية.
ومن خلال تقرير Cetus، من الواضح أن الفريق لم يقم بالتفكير الكافي.
بدلاً من التركيز فقط على عيوب التقنية في الهجوم الإلكتروني الحالي، أشعر أنه يجب على جميع فرق DeFi بدءًا من Cetus أن تتجاوز قيود التفكير الفني البحت، وأن تنمي بالفعل الوعي بمخاطر الأمان لدى "مهندسي المالية".
على سبيل المثال ، إدخال خبراء في مراقبة المخاطر المالية للتعويض عن النقاط العمياء المعرفية للفريق الفني ؛ تنفيذ آلية مراجعة متعددة الأطراف ، ليس فقط للنظر في تدقيق المدونة ، ولكن أيضا لتشكيل مراجعة النموذج الاقتصادي اللازم. تنمية "الحس المالي" ، ومحاكاة سيناريوهات الهجوم المختلفة والإجراءات المضادة المقابلة ، وكن حساسا للعمليات غير الطبيعية في جميع الأوقات.
هذا يذكرني بتجربتي السابقة في الشركات الأمنية، بما في ذلك النقاشات مع عمالقة الأمن في الصناعة مثل @evilcos، @chiachih_wu، @yajinzhou، و@mikelee205 الذين كان لديهم هذا الإجماع:
مع نضوج الصناعة بشكل متزايد، ستقل مشاكل الأخطاء التقنية على مستوى الكود، لكن "أخطاء الوعي" في منطق العمل الذي يفتقر إلى الحدود الواضحة والمسؤوليات الغامضة ستكون التحدي الأكبر.
يمكن لشركات التدقيق التأكد من أن الكود خالي من الأخطاء، ولكن كيفية تحقيق "حدود المنطق" تتطلب من فريق المشروع فهمًا أعمق لطبيعة العمل وقدرة على التحكم في الحدود. (السبب الجذري للعديد من حوادث "إلقاء اللوم" بعد تدقيقات الأمان السابقة التي لا تزال تتعرض للاختراق من قبل القراصنة هو هذا)
مستقبل DeFi ينتمي إلى الفرق التي تتمتع بمهارات تقنية قوية في البرمجة، وفي نفس الوقت فهم عميق لمنطق الأعمال!