تأملات ودروس من حادثة هجوم هاكر على بروتوكول Cetus
أصدر بروتوكول معين مؤخرًا تقريرًا عن "إعادة تقييم" الأمان بشأن هاكر الهجمات. يعتبر التقرير شفافًا للغاية في الكشف عن التفاصيل الفنية والاستجابة الطارئة، ويمكن اعتباره على مستوى الكتب المدرسية. ومع ذلك، عندما يتعلق الأمر بالإجابة على السؤال الأساسي "لماذا تم اختراقه"، يبدو أن التقرير يتجنب النقاط الرئيسية بعض الشيء.
تقرير يشرح بشكل موسع الأخطاء في دالة checked_shlw لمكتبة integer-mate (يجب أن تكون ≤2^192، ولكنها في الواقع ≤2^256)، ويصنفها على أنها "سوء فهم دلالي". على الرغم من أن هذا الوصف ليس فيه ما يعيب من الناحية التقنية، إلا أنه يحول بمهارة التركيز إلى المسؤولية الخارجية، كما لو أن البروتوكول نفسه هو أيضًا ضحية بريئة لهذا العيب الفني.
ومع ذلك، من الجدير بالتفكير: بما أن integer-mate هو مكتبة رياضية مفتوحة المصدر تستخدم على نطاق واسع، فلماذا ظهرت مثل هذه الخطأ السخيف في هذا البروتوكول، مما يسمح بالحصول على حصة سيولة باهظة الثمن مقابل عملة واحدة فقط؟
تحليل مسار هجمات هاكر يمكن أن يظهر أنه لتنفيذ الهجوم بنجاح يجب تلبية أربعة شروط في نفس الوقت: فحص تجاوز خاطئ، عمليات إزاحة كبيرة، قواعد التقريب لأعلى، وافتقار إلى تحقق من الجدوى الاقتصادية. ومن المدهش أن البروتوكول قد شهد "إهمالاً" في كل شرط من شروط "التحفيز": قبول مدخلات المستخدم مثل 2^200 وهو رقم فلكي، واستخدام عمليات إزاحة كبيرة خطيرة للغاية، والثقة المطلقة في آلية فحص المكتبات الخارجية. والأكثر فتكًا هو أنه عندما يحسب النظام نتيجة "1 توكن مقابل حصة باهظة" وهي نتيجة غير معقولة بشكل واضح، لم يكن هناك أي فحص للمنطق الاقتصادي وتم تنفيذها مباشرة.
لذلك ، تشمل الأسئلة التي يحتاج هذا البروتوكول حقًا إلى التفكير فيها:
لماذا لم يتم إجراء اختبارات أمان كافية عند استخدام المكتبات الخارجية العامة؟ على الرغم من أن مكتبة integer-mate تتميز بأنها مفتوحة المصدر وشائعة الاستخدام على نطاق واسع، إلا أنه عند إدارة أصول تزيد قيمتها عن مئة مليون دولار، فإن البروتوكول يفتقر بوضوح إلى فهم عميق لحدود أمان هذه المكتبة، بالإضافة إلى وجود خطط بديلة في حالة فشل وظائف المكتبة. وهذا يكشف عن نقص الوعي لدى البروتوكول بشأن أمان سلسلة التوريد.
لماذا يُسمح بإدخال أرقام فلكية دون تحديد حدود معقولة؟ على الرغم من أن بروتوكولات التمويل اللامركزي تسعى إلى الانفتاح، إلا أن النظام المالي الناضج كلما كان أكثر انفتاحًا، كلما كان بحاجة إلى حدود واضحة. السماح بإدخال قيم مبالغ فيها يظهر أن الفريق يفتقر إلى المواهب في إدارة المخاطر التي تتمتع بالحدس المالي.
لماذا لم يتمكنوا من اكتشاف المشكلات مسبقًا بعد عدة جولات من التدقيق الأمني؟ هذا يعكس خطأ إدراكي قاتل: يعتقد فريق المشروع أنهم قاموا بتفويض المسؤولية الأمنية بالكامل إلى شركة الأمان، ويعتبرون التدقيق بمثابة شهادة إعفاء من المسؤولية. ومع ذلك، فإن مهندسي التدقيق الأمني يتمتعون بمهارة كبيرة في اكتشاف ثغرات الشيفرة، وقليلًا ما يأخذون في الاعتبار المشكلات التي قد تنشأ عندما يقوم النظام المختبر بحساب نسب تبادل غير معقولة للغاية.
إن هذا التحقق الذي يتجاوز حدود الرياضيات والتشفير والاقتصاد هو بالضبط أكبر ضعف في مجال أمان التمويل اللامركزي الحديث. قد تعتبر شركات التدقيق أن هذا يتعلق بعيوب تصميم النموذج الاقتصادي وليس بمشكلات منطق الكود؛ بينما قد يشتكي فريق المشروع من أن التدقيق لم يكتشف المشكلة؛ وفي النهاية، يتعرض أصول المستخدمين للضرر.
كشفت هذه الحادثة عن نقاط الضعف الهيكلية في صناعة التمويل اللامركزي: الفرق التي تتمتع بخلفية تقنية بحتة غالبًا ما تفتقر بشدة إلى "حس المخاطر المالية" الأساسي.
من خلال تقرير هذا البروتوكول، يبدو أن الفريق لم يدرك ذلك بشكل كافٍ. بدلاً من التركيز فقط على العيوب الفنية للهجوم هاكر، ينبغي لجميع فرق التمويل اللامركزي تجاوز حدود التفكير الفني البحت، وتنمية الوعي بمخاطر الأمان "مهندسي التمويل" بشكل حقيقي.
يمكن أن تشمل التدابير المحددة: إدخال خبراء في إدارة المخاطر المالية لسد الفجوات المعرفية في الفريق الفني؛ إنشاء آلية مراجعة تدقيق متعددة الأطراف، لا تركز فقط على تدقيق الشفرات، ولكن أيضًا على تدقيق نماذج الاقتصاد؛ تنمية "حاسة المالية"، ومحاكاة سيناريوهات الهجوم المختلفة والإجراءات المقابلة للتعامل معها، والبقاء في حالة تأهب عالية تجاه العمليات غير الطبيعية، وغيرها.
هذا يذكرني بإجماع العاملين في صناعة الأمن: مع نضوج الصناعة بشكل متزايد، ستقل الأخطاء التقنية على مستوى الشيفرة النقية، بينما ستصبح "ثغرات الوعي" في منطق العمل الغامض وغير المحدد هي أكبر تحدٍ.
يمكن لشركات التدقيق التأكد من عدم وجود ثغرات في الشيفرة، لكن كيفية تحقيق "المنطق له حدود" تتطلب من فريق المشروع فهماً أعمق لطبيعة العمل وقدرة على ضبط الحدود. وهذا يفسر أيضاً السبب الجذري وراء تعرض العديد من المشاريع التي خضعت للتدقيق الأمني لهجمات هاكر.
مستقبل التمويل اللامركزي، سيكون بلا شك ملكاً لتلك الفرق التي لا تتمتع فقط بمهارات تقنية قوية في البرمجة، بل وأيضاً بفهم عميق للمنطق التجاري!
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
كشف اختراق بروتوكول Cetus عن نقاط الضعف في أمان التمويل اللامركزي: الفجوة بين التكنولوجيا والمالية تحتاج إلى سدها بسرعة
تأملات ودروس من حادثة هجوم هاكر على بروتوكول Cetus
أصدر بروتوكول معين مؤخرًا تقريرًا عن "إعادة تقييم" الأمان بشأن هاكر الهجمات. يعتبر التقرير شفافًا للغاية في الكشف عن التفاصيل الفنية والاستجابة الطارئة، ويمكن اعتباره على مستوى الكتب المدرسية. ومع ذلك، عندما يتعلق الأمر بالإجابة على السؤال الأساسي "لماذا تم اختراقه"، يبدو أن التقرير يتجنب النقاط الرئيسية بعض الشيء.
تقرير يشرح بشكل موسع الأخطاء في دالة checked_shlw لمكتبة integer-mate (يجب أن تكون ≤2^192، ولكنها في الواقع ≤2^256)، ويصنفها على أنها "سوء فهم دلالي". على الرغم من أن هذا الوصف ليس فيه ما يعيب من الناحية التقنية، إلا أنه يحول بمهارة التركيز إلى المسؤولية الخارجية، كما لو أن البروتوكول نفسه هو أيضًا ضحية بريئة لهذا العيب الفني.
ومع ذلك، من الجدير بالتفكير: بما أن integer-mate هو مكتبة رياضية مفتوحة المصدر تستخدم على نطاق واسع، فلماذا ظهرت مثل هذه الخطأ السخيف في هذا البروتوكول، مما يسمح بالحصول على حصة سيولة باهظة الثمن مقابل عملة واحدة فقط؟
تحليل مسار هجمات هاكر يمكن أن يظهر أنه لتنفيذ الهجوم بنجاح يجب تلبية أربعة شروط في نفس الوقت: فحص تجاوز خاطئ، عمليات إزاحة كبيرة، قواعد التقريب لأعلى، وافتقار إلى تحقق من الجدوى الاقتصادية. ومن المدهش أن البروتوكول قد شهد "إهمالاً" في كل شرط من شروط "التحفيز": قبول مدخلات المستخدم مثل 2^200 وهو رقم فلكي، واستخدام عمليات إزاحة كبيرة خطيرة للغاية، والثقة المطلقة في آلية فحص المكتبات الخارجية. والأكثر فتكًا هو أنه عندما يحسب النظام نتيجة "1 توكن مقابل حصة باهظة" وهي نتيجة غير معقولة بشكل واضح، لم يكن هناك أي فحص للمنطق الاقتصادي وتم تنفيذها مباشرة.
لذلك ، تشمل الأسئلة التي يحتاج هذا البروتوكول حقًا إلى التفكير فيها:
لماذا لم يتم إجراء اختبارات أمان كافية عند استخدام المكتبات الخارجية العامة؟ على الرغم من أن مكتبة integer-mate تتميز بأنها مفتوحة المصدر وشائعة الاستخدام على نطاق واسع، إلا أنه عند إدارة أصول تزيد قيمتها عن مئة مليون دولار، فإن البروتوكول يفتقر بوضوح إلى فهم عميق لحدود أمان هذه المكتبة، بالإضافة إلى وجود خطط بديلة في حالة فشل وظائف المكتبة. وهذا يكشف عن نقص الوعي لدى البروتوكول بشأن أمان سلسلة التوريد.
لماذا يُسمح بإدخال أرقام فلكية دون تحديد حدود معقولة؟ على الرغم من أن بروتوكولات التمويل اللامركزي تسعى إلى الانفتاح، إلا أن النظام المالي الناضج كلما كان أكثر انفتاحًا، كلما كان بحاجة إلى حدود واضحة. السماح بإدخال قيم مبالغ فيها يظهر أن الفريق يفتقر إلى المواهب في إدارة المخاطر التي تتمتع بالحدس المالي.
لماذا لم يتمكنوا من اكتشاف المشكلات مسبقًا بعد عدة جولات من التدقيق الأمني؟ هذا يعكس خطأ إدراكي قاتل: يعتقد فريق المشروع أنهم قاموا بتفويض المسؤولية الأمنية بالكامل إلى شركة الأمان، ويعتبرون التدقيق بمثابة شهادة إعفاء من المسؤولية. ومع ذلك، فإن مهندسي التدقيق الأمني يتمتعون بمهارة كبيرة في اكتشاف ثغرات الشيفرة، وقليلًا ما يأخذون في الاعتبار المشكلات التي قد تنشأ عندما يقوم النظام المختبر بحساب نسب تبادل غير معقولة للغاية.
إن هذا التحقق الذي يتجاوز حدود الرياضيات والتشفير والاقتصاد هو بالضبط أكبر ضعف في مجال أمان التمويل اللامركزي الحديث. قد تعتبر شركات التدقيق أن هذا يتعلق بعيوب تصميم النموذج الاقتصادي وليس بمشكلات منطق الكود؛ بينما قد يشتكي فريق المشروع من أن التدقيق لم يكتشف المشكلة؛ وفي النهاية، يتعرض أصول المستخدمين للضرر.
كشفت هذه الحادثة عن نقاط الضعف الهيكلية في صناعة التمويل اللامركزي: الفرق التي تتمتع بخلفية تقنية بحتة غالبًا ما تفتقر بشدة إلى "حس المخاطر المالية" الأساسي.
من خلال تقرير هذا البروتوكول، يبدو أن الفريق لم يدرك ذلك بشكل كافٍ. بدلاً من التركيز فقط على العيوب الفنية للهجوم هاكر، ينبغي لجميع فرق التمويل اللامركزي تجاوز حدود التفكير الفني البحت، وتنمية الوعي بمخاطر الأمان "مهندسي التمويل" بشكل حقيقي.
يمكن أن تشمل التدابير المحددة: إدخال خبراء في إدارة المخاطر المالية لسد الفجوات المعرفية في الفريق الفني؛ إنشاء آلية مراجعة تدقيق متعددة الأطراف، لا تركز فقط على تدقيق الشفرات، ولكن أيضًا على تدقيق نماذج الاقتصاد؛ تنمية "حاسة المالية"، ومحاكاة سيناريوهات الهجوم المختلفة والإجراءات المقابلة للتعامل معها، والبقاء في حالة تأهب عالية تجاه العمليات غير الطبيعية، وغيرها.
هذا يذكرني بإجماع العاملين في صناعة الأمن: مع نضوج الصناعة بشكل متزايد، ستقل الأخطاء التقنية على مستوى الشيفرة النقية، بينما ستصبح "ثغرات الوعي" في منطق العمل الغامض وغير المحدد هي أكبر تحدٍ.
يمكن لشركات التدقيق التأكد من عدم وجود ثغرات في الشيفرة، لكن كيفية تحقيق "المنطق له حدود" تتطلب من فريق المشروع فهماً أعمق لطبيعة العمل وقدرة على ضبط الحدود. وهذا يفسر أيضاً السبب الجذري وراء تعرض العديد من المشاريع التي خضعت للتدقيق الأمني لهجمات هاكر.
مستقبل التمويل اللامركزي، سيكون بلا شك ملكاً لتلك الفرق التي لا تتمتع فقط بمهارات تقنية قوية في البرمجة، بل وأيضاً بفهم عميق للمنطق التجاري!